In-Depth

Continuous Improvement and the Agile Retrospective

Doing better takes time and is an incremental process.

• By Mark J. Balbes, Ph.D.
• 06/10/2013

Agile development isn't just a better way to build software. It's also an effective strategy to make the entire enterprise more flexible, durable and responsive to change. One vital method to help achieve this broader objective is to focus on continuous improvement.

Organizations begin using agile as a set of prescriptive practices that structures how development teams perform their work. They transition to agile development through the use of important technical practices such as test-driven development (TDD), pair programming, and continuous integration (CI), as well as project-management practices like sprints or continuous flow. While those are good starting points, they're not enough. At some point an organization will notice that the unique requirements of its culture, business domain or a particular project aren't adequately addressed by the boilerplate versions of these practices. At that point, if the company sticks to its guns and continues to go by the book, it misses out on an important opportunity to improve its team, its processes and its product.

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

Here's my list:

• The solution must be sustainable, regular and continuous.
• The whole team must buy into it.
• All team members can participate.
• You should be able to engage outside help as needed.
• The solution itself should be adaptable and allow for change.

A solution that meets these qualities is the team retrospective.

The Importance of Team Retrospectives
A retrospective is an all-hands team meeting that happens on a regular basis -- preferably weekly -- where the team comes together to ask the question, "How are we doing?" (Or, in some cases, "What the heck is going wrong?")

Let me tell you a story.

One of my teams is incredibly agile. We've got a mature code base, a large suite of automated tests, and we practice TDD and pair programming religiously. It's very easy to make changes to the software to accommodate new functionality. The team works together effectively -- or at least they did. Suddenly, they found themselves constantly bickering over the appropriate solutions to problems, and generally making our war room a rather unpleasant place to work. No one knew why this was happening until we had our next retrospective.

Then the answer came out. We had inherited a large code base from one of our development partners. They didn't practice TDD or even use automated testing. Their code was a hairball mess of stuff that was hard to work with and extremely buggy. We were trying to put some discipline around the code and get it under control. And this was why our team cohesion started to fall apart -- we were in extremely uncomfortable territory, working on unknown code without the benefit of tests. It made us ill at ease, irritable, and a bit scared, and this led to the higher tension we were experiencing. I'd like to be able to tell you that everything snapped back to normal after that, but of course it couldn't. However, knowing the source of our tension did help us keep things calmer. Even better, it focused us on discussing the real source of our problems: how to get this code base under control.

Retrospectives are nothing new. Companies have been doing them or something similar for decades.

For retrospectives to be helpful, they must be effective. Without a focus, they can easily turn into non-productive gripe sessions. An outside facilitator provides that focus -- someone who's 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're not leading the discussion.

Games and exercises are an important part of a retrospective. Some teams will balk at these, and would rather opt for discussion. Open discussion is easy but isn't always the right choice. Often a team will have one or more members who aren't comfortable stating their opinion publicly. Open discussion tends to focus on the obvious or comfortable issues, but avoids the hard conversations. A good game or exercise will draw out everyone's opinions and unspoken issues by either creating a safer environment for speaking publicly or by providing anonymity.

As a facilitator, I have to read the room to determine what to do next. For example, if I sense that there's a lot of uncertainty among the team, I'll have them play "Circle of Questions." Each team member asks a question of the person next to him, which gives everyone a voice both in what question they ask and how they respond. If I sense someone is afraid to speak up, I'll use one of the many exercises that collects information using sticky notes. This gives everyone a chance to write down his thoughts, turn them in anonymously, and have the team respond based on the idea rather than the author. A great source for games and exercises is the book "Agile Retrospectives: Making Good Teams Great" (Pragmatic Bookshelf, 2006) by Esther Derby and Diana Larsen.

Once you've created your safe environment, played your games and identified issues, what do you do to address these issues? Here are several suggestions.

The 'Try It for Two Weeks' Approach
One of the approaches I've found to be successful is the "let's try it for two weeks and then reevaluate" approach. This works when the team has an idea for how to address an issue but isn't sure if it's the correct approach. By trying their idea for a limited time, the team isn't locking itself 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. This is my team's favorite approach.

The Metrics-Driven Approach
This approach is harder. It assumes the team has metrics that are driving a decision to make changes in how it does its work. If the right metrics don't exist, the team will need to collect metrics on its current process before making changes; otherwise, there's no basis for comparison. Most of my projects at Asynchrony Solutions collect metrics such as cycle time, work in progress and velocity -- all metrics associated with how fast the team is going. This allows a team to see when a change works and how it impacts speed.

I was involved with a project that was extremely metrics-driven. We were helping a customer transform its business to agile. Some of its developers were very reluctant to pair program or practice TDD. At one point in the project, these developers 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 weren't 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, I suggest using 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 CI
• Risk management

Where I work, every project has a charter. We review charters on a regular basis in our retrospectives, typically when new people join the team or when something significant happens, such as starting a new release. Reviewing a 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 download accompanying this article includes a sample charter template developed and used by Asynchrony Solutions. This template is regularly reviewed and updated to meet the changing needs of our business and teams.

The Facilitator
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. An experienced facilitator knows how to ask probing questions without leading the team to a solution. And when the retrospective is breaking down into a gripe session, as such meetings can easily do, the facilitator brings the discussion back on track.

Continuous Improvement My team has come a long way in four years. It's been a slow, steady process that we'll never finish. Our early improvements were pretty basic, focusing on doing better with our software-development disciplines like pairing and TDD. 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 it was a big one. We reworked our entire Kanban process to focus on minimal marketable features (MMFs) rather than individual stories. An MMF is a collection of stories that makes up an actual shippable unit. While each story is required to deliver value to the end user, a single story may not provide enough value to be releasable by itself. By focusing our development on MMFs, we're hoping to improve the cohesiveness of the UX in our releases. We continue to improve this new process incrementally as we learn from it. Our weekly retrospective plays an important role in identifying how MMFs are helping us, and where we still need to improve.

• Get Code Download