Ending Right

[article]
Summary:

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.

Planning
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."

Performing
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
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

Jeff Patton's picture Jeff Patton

Jeff Patton leads Agile Product Design, a small consultancy that focuses on creating healthy processes that result in products that customers love. Articles, essays, and blog can be found at www.AgileProductDesign.com. Information about public classes, including Certified Scrum Training, can be found at www.AgileProductDesign.com/training.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Aug 25
Aug 26
Sep 22
Oct 12