The Agile Architect

Continuous Improvement: The Importance of the Team Retrospective

Even good agile teams can get better. Mark J. Balbes walks you through how retrospectives have impacted his team and shows you options for yours.

• By Mark J. Balbes, Ph.D.
• January 4, 2012

You've finally got the job of your dreams. You joined a company that lives and breathes agile software development. You were assigned to a team that follows all eXtreme Programming practices, but something's not quite right.

While the developers talk about pairing, they don't seem to be doing it much. Of course, the team is writing automated unit tests, at least most of the time. But despite mutterings about writing automated acceptance tests, it never seems to be the right time. And there's a problem with your two-week iterations: The stories just never seem to fit. There's either too much work or not enough, causing the team to either skimp on quality to get the work done or waste time because they don't want to start new work right before the iteration ends. And retrospectives? Well, those just don't happen much. After all, what's there to talk about that we can't discuss in the war room?

Sound familiar? This was the situation I found myself in four years ago. It wasn't that the team wasn't agile. It was. In fact, it was more agile than any team I'd ever worked with. It just felt like we could still do better.

Doing better takes time. And you have to have faith that the time invested is more than compensated for by what you get back. Often when solving a technical problem with my team, I ask that we first determine the qualities that the solution must have before we work on an actual solution. So, let's do that here: What are some qualities to the solution for the problem stated above, namely "How do we do better?"

Here's my list:

• The solution must be sustainable; i.e., it happens regularly and/or continuously.
• The whole team must buy into it.
• All team members can participate.
• We should be able to engage outside help as needed.
• The solution itself should be adaptable and allow for change.

One solution that meets these qualities is the team retrospective.

The "how" is simple. We had a team retrospective.

Our retrospective happens every Friday at 1:15 p.m. for 30 minutes. We also have the option to extend the time by another 30 minutes if we need it. This allows us to have short retrospectives when we are extremely busy but still always take the time to ask each week "Can we do better?" It was during our retrospective, when we took a step back from the chaos we were engulfed in, that we recognized what was happening.

Retrospectives are nothing new. Companies have been doing them or something similar for decades. There are many good books and Web sites on how to run a retrospective. (When I facilitate, I often turn to "Agile Retrospectives: Making Good Teams Great" for ideas). For retrospectives to be helpful, they have to be effective. Without a focus, they can easily turn into non-productive gripe sessions. An outside facilitator provides that focus; someone who is not a member of the team but is there to elicit discussion.

I participate in retrospectives with my team and I act as a facilitator for other teams. This allows me to see both sides of the process. There are several factors that I think are important in a good retrospective:

• The retrospective should take place outside the war room.
• Each team member must feel safe to contribute ideas.
• The facilitator should have a plan for the retrospective but be quick to put it aside if the team wants to attack other issues.
• The facilitator can ask questions and make suggestions but they are not leading the discussion.

Games and exercises are an important part of a retrospective. Often teams will balk at these, wanting to stick to open discussion. Open discussion is easy but is not always the right choice. Often a team will have one or more members that are not comfortable speaking their opinion publicly. Open discussion tends to focus on the obvious or comfortable issues but avoid the hard conversations. After all, how many meetings have you had where afterwards a select few of you linger to talk about what you really think? A good game or exercise will draw out people's opinions and unspoken issues by either creating a safer environment for them to speak publicly or by providing anonymity.

Once you've created your safe environment, you played your games and identified issues, what do you do to address these issues? Here's a couple of suggestions:

The 'Just-Try-It For-2-Weeks' Approach
One of the approaches that I've found to be successful is the "Let's try it for two weeks and then re-evaluate" approach. This works when the team has an idea for how to address their issue but isn't sure if it's the right approach. By trying it for a limited time, the team isn't locking themselves into anything. It's easier to get buy-in from the team for a limited experiment than a permanent change. Two weeks is usually long enough to determine if something is working. For my team, this is our favorite approach.

The Metrics-Driven Approach
This approach is harder. It assumes that the team has metrics that are driving a decision to make changes in how they do their work. If the right metrics don't exist, the team will need to collect them on their current process before making changes. Otherwise, there is no basis for comparison. Most of our projects at Asynchrony Solutions collect metrics like cycle time, work in progress and velocity; metrics associated with how fast the team is going. This let's us see when a change in how we do our work speeds us up or slows us down.

I was involved with a project that was extremely metrics-driven. We were helping a customer transform their business to agile. Some of their developers were very reluctant to pair program or practice test-driven development. At one point in the project, they convinced their managers to let them drop these practices. Because we already had a significant baseline history of metrics on cycle time, velocity and defects created, we could show how the team velocity dropped and code quality suffered dramatically when these practices were not followed.

The Project Charter
The project charter is a document written by the team that describes how that team will work together. Rather than start from scratch, we use a charter template that is itself a living document. The template asks questions about the following areas:

• Project Purpose and Timeline
• Team Members and Workspace
• Planning and Estimation
• Monitoring and Measurement
• Configuration Management
• Development, Testing and Continuous Integration
• Risk Management

Where I work, every project has a charter and we review them on a regular basis in our retrospectives, typically when new people join the team or when something significant happens like starting a new release. Reviewing the charter spurs conversations about how the team currently works, how it has changed since the charter was last updated, and how the team can do better.

The Facilitator Is The Key
The facilitator is the key to an effective retrospective. A good facilitator knows when to let open discussion continue or when to move to a game or exercise to draw out the team members. The experienced facilitator knows how to ask probing questions without leading the team to their solution. And when the retrospective is breaking down into a gripe session, as they can easily do, the facilitator brings the discussion back on track.

Continuous Improvement Never Ends
My team has come a long way in four years. It has been a slow, steady process that we will never finish.

Our early improvements were pretty basic, focusing on doing better with our software development disciplines like pairing and test-driven development. Then we started looking at our iterations. We went from two-week iterations to one-week iterations (which made things worse) to no iterations using Kanban (which made things much, much better).

Our last process change was as recent as two months ago, and boy was it a doozy. We reworked our entire Kanban process to focus on business value units (a.k.a. minimal marketable features) rather than individual stories. But that's a tale for another column...

Get More 'The Agile Architect' Columns by Mark J. Balbes, Ph. D.:

• Dealing with Technical Debt: An Agile Horror Story

• Project Management Is Not Enough: 4 Crucial Agile Techniques

• You Can't Do Agile If You Haven't Seen Agile

• All Agile Architect Columns on ADTmag.com