CHAPTER ELEVEN

Improvement

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Manifesto for Agile Software Development

Feedback and adaptation are central to Agile, and that applies to the team’s approach to Agile itself. Although you might start with an off-the-shelf Agile method, every team is expected to customize its method for itself.

As with everything else in Agile, this customization happens through iteration, reflection, and feedback. Emphasize the things that work; improve the things that don’t. These practices will help you do so:

“Retrospectives” helps your team continually improve.
“Team Dynamics” improves your team’s ability to work together.
“Impediment Removal” focuses your team’s improvement efforts where they’ll make the most difference.

IMPROVEMENT SOURCES

Although retrospectives are a common Agile practice now, the original XP and Scrum books 1 didn’t include them—or, for that matter, any explicit practices for improvement. Continuous improvement was clearly on the minds of early Agilists, given its inclusion in the Agile Manifesto, but retrospectives weren’t formalized as a practice until later. The first Agile method that I’m aware of to incorporate retrospectives was Joshua Kerievsky’s Industrial XP (IXP) in the early 2000s.

The retrospectives in IXP were based on Norm Kerth’s Project Retrospectives. [Kerth2001] Later, Diana Larsen—who had worked closely with Norm Kerth—published her highly influential book with Esther Derby, Agile Retrospectives: Making Good Teams Great. [Derby2006] From there, retrospectives made their way into Scrum and spread throughout the Agile community.

My approach to Retrospectives has been filtered through a few decades of experiments and experiences. My initial experiments with continuous improvement were inspired by project postmortems, a technique that predates Agile. Later, I adopted the ideas in [Kerth2001], then worked with Joshua Kerievsky on an IXP team, and later stil, read and incorporated [Derby2006]. The final result is compatible with Larsen’s approach to retrospectives, but a bit different, too.

Speaking of Diana Larsen, she’s not only a retrospectives guru, she’s also an expert in organizational and team dynamics. We’re fortunate to have her as a guest author in this chapter. She writes Team Dynamics and Impediment Removal. Both of these practices are based on her extensive experience with organizational and team dynamics, both of which predate Agile.

¹ Specifically, I’m referring to Extreme Programming Explained, 1st ed. [Beck2000a] and Agile Software Development with Scrum [Schwaber2002].