An Agile Story: Progress versus Success

November 19, 2010

Mitch Lacey has an interesting presentation from Tech-Ed Europe, Working Software is Not Enough! that is long (about 60 minutes), but well-worth your time.

One of the twelve Agile principles is that working software is the primary measure of progress, but Mitch asserts that he and his team were wrong in believing this. After viewing the presentation and listening to Mitch, my take is slightly different.

Yes, the project went south. But Mitch and his team weren’t wrong in believing that delivering working software is a true measure of progress. Nor were they wrong in embracing and supporting other key Agile principles, including:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

(Quoted directly from the Principles behind the Agile Manifesto.)

The main problem was that the customer didn’t really understand (or care to understand) and agree to the Agile values and principles. The customer wanted what they wanted, including one million dollars’ worth of software for half that price.

Some highlights about the project that are included in the presentation:
  • The project involved a lot of change, and it was evident from the beginning that the customer anticipated change. This is why Scrum/XP was adopted for the project.

  • Early on, everyone was happy. (Aren’t all projects like this?)

  • As the project progressed, danger signals began to surface. Like the customer asking, “When are you going to be done?” – Despite regular involvement in sprint reviews and backlog grooming.

  • The product backlog was changing – daily – with everything being an equal priority.

  • The customer, who had agreed to perform the testing to save costs, started making comments about how they couldn’t test because the software wasn’t complete, despite regular delivery of working software every couple of weeks.

  • With two months left on the original project schedule, the project exploded. Major communication breakdowns became evident, including the customer claiming that their understanding was that anything and everything on the product backlog would be something that they would ultimately receive. They didn’t understand the “water line” (feature cutoff point); they thought it was a discussion point and not a real line involving real functionality.
I’ll let you view the presentation for all the details and to see how the story ended. It's an excellent, real-world example of what can go wrong.

Get Microsoft Silverlight

As they say, hindsight is 20/20, and it’s certainly easy being the arm-chair quarterback after the fact. But it is worth reflecting on this experience and asking a couple of questions.

Was the choice of Agile development wrong?

How could this project have used Agile successfully?

Here's are a couple of thoughts I had on how the project could have been approached as I watched the presentation:
  1. Mitch and his team could have used Agile development internally to respond to the inevitable change that the customer was going to throw at them, but from a customer-facing perspective they could have used more traditional, plan-driven techniques that included things like rigorous change control. Given the amount of change anticipated, I would have been comfortable using an incremental Agile approach even if the customer wanted a “big bang” delivery at the end.

  2. I don’t know what the statement of work (SOW) looked like for this project, but given the amount of anticipated change and the agreement by the customer to perform some of the work to keep the cost of the project down, the SOW could have been crafted as a working agreement that clearly spelled out the roles and responsibilities (in an Agile context) of both parties. This would have included the backlog prioritization and the purpose of the water line, testing and acceptance of software delivered in increments, etc.
Mitch does a great job at the end in covering lessons learned and what he would do differently.

Mitch and his team weren't wrong. Working software is a true measure of progress, but it isn’t a full measure of success.