Ending Right


Jeff Patton has been building software using the agile approach for a while now. His observations of how others are implementing agile development fall short of complete, but he has noticed is that the adoption breaks down during the evaluation phase. In this column, Jeff goes through the agile development process and offers guidance on the correct way of conducting an agile evaluation during this phase in the software development lifecycle.

For many, "agile" means "We've stopped writing documents," which doesn't actually mean you are practicing agile. It means you're good at justifying bad behavior. One of the tenets of agile development is the idea of a healthy development cycle. In XP it's called an "iteration;" in Scrum, a "sprint." But the basic idea of a complete cycle is the same across these methodologies. And, sadly, many agile teams have broken cycles. This column is about diagnosing and fixing busted cycles—in particular, at the ending of the cycle where I see most teams get a bit sloppy.

Figure 1: The three parts of a healthy development cycle.

A good cycle has three parts: planning, performing, and evaluating.

In the planning part we decide what we're going to do. Usually, that means the amount of work we're going to take on. To do this, we'll talk about the pieces of software to build and, ideally, write down acceptance criteria for each piece so we're sure we know what "done" means for this piece. Many teams even define a working agreement, referred to as the "definition of done" (DoD). The DoD usually determines that done means it has to be coded and tested—which is a big advance for testers for whom "done" used to mean only "coded."

Building software and all the collaboration it takes to do this is the performing part. An important part of performing well is transparency, which is another way of saying it's easy to tell how far along we are. Agile folks often show progress on task boards or using burn-down charts.

Evaluating is the most important part of a healthy cycle. It is where we look at what we've done and make corrections to the product, the schedule, and the process we're following. This responding part is what makes agile development agile and the part where I see most teams start to fall down.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.