We do what we’re told to do. Every day. Every iteration. Every release cycle. We finish our software features, and our customers are happy about what they get. And at every iteration, we do better at making code, because we’re continuing to improve our software, our infrastructure, and our tests. In the spirit of the Scrum process, we’re also improving our process. We can call this continuous improvement.

If we are closely following the rules of Scrum, we’ve instituted a retrospective regularly scheduled into our process. Our goal during a retrospective is to make our process better. We typically have one for every sprint, we invite all the team members to the retrospective, we look at both the good things that happened in that sprint, the things that need improvement, the ways in which we can improve, and we make specific goals to improve our process.

It’s easy to fall into a routine each day at work. Retrospective might actually become routine. The more routine sets into our mentality at work, the less likely we are able to innovate. This is highly true also for our retrospective and the goals coming out of it.

A critical element of a retrospective is voting. As a member of a scrum team, we can vote about what is important to how we work. Managers don’t vote. Product owners don’t vote. C-level people don’t vote. Neither customers nor users vote. We vote as members of our scrum team, and with each vote, we own the process of what we’re doing.

Consider with me some ways to make the best of our retrospective process.

Mental preparation

We make complex software! Doing what we do, it is too easy to forget about all the things that happened in a sprint iteration! Just like we spend time thinking about software architecture before we start building software, we ought to spend time thinking about the successes and the opportunities we had to improve during the sprint. It’s best, even, to jot those things down as notes as they happen. We then would return to those notes during the retrospective.

As we make our notes, we would both celebrate things that went well and opportunities to improve. Consider, that some events might both have gone well and have been an opportunity to improve.

Dot voting, private voting

As stated above, voting is the real substance of ownership of our work. Let’s do voting right!

Each item on our lists is likely very different from the others. In a retrospective, we have lots of items to consider! It’s not realistic to vote just for one item. If we can use many votes, we can spread our concern across many items and prioritize what we need to.

I once worked in a team where we each had 10 votes. In the process, we had one member who waited until everyone else voted, and then placed all ten of his votes on a single item. One time, that item didn’t receive anyone else vote for it. In effect, this one member canceled every other person’s vote and controlled the direction of the retrospective. That was not team ownership, but ownership by one guy. Let’s try something else: private voting.

Our democratic process in the United States (and most places) means that we vote privately. We don’t know how others are voting until the very end when all the votes are cast. Were we to know how voting is going before we vote, that process would probably look very different. We might need the help of some software-tool to do private voting: it’s important to ensure team-ownership.

Following up on goals

Lest we fall into routine, it helps to follow up on what our goals from the previous retrospectives. We need to apply those goals to the work at our desks. This is more difficult than it seems!

In some cases, we can create work-items that have specific objectives to improve. Those work-items need to come into our sprint cycle (and be estimated and prioritized with other work). This can ensure the completion of those goals, but it could require competition with other goals from the product point of view.

In many cases, retrospective goals aren’t clearly about repeatable events, but about patterns in our process. It helps to have a Scrummaster come alongside what we are doing in the sprint (or possibly many sprints later), to help us ensure the best practices we agreed on as a team.

How we use the retrospective is an entirely good use of time within a retrospective. This sounds paradoxical, but it can be a very good discussion for a team to discuss how they ensure goals get best executed.

Software tools for retrospective

I’ve worked with a few different tools for retrospectives, and I can’t say that it’s important to use a tool, unless you have members of the team working remotely. As long as the process ensures the dignity of each vote and each member’s desire to improve the team, using a tool isn’t important.

Putting that aside, I’ve used these tools. FunRetro and Retrium are tools aren’t that different from my point of view. They make both make use of a GUI that looks like post-it-notes.

My favorite is a tool from Team O’Clock, where the interface is very deliberate to walk a team through the specific parts of a retrospective, helping a team stay timely with the meeting. It appears this software also helps move through daily-standup meetings and planning-poker, too, but I’ve not used this implementation.

In summary, doing a retrospective is a critical step in making a team own their process. It can help ensure each member is fully owning what they are doing, and they are more fully engaged in what they are doing. Each member can be proud of the continuous improvement process that they are a part of.