I was reading the latest post on Johanna Rothman’s Managing Product Development blog.  In it she says,

Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction that’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by”“the first possible, optimistic date.

I like that characterization of the predicted date.  Another characterization, usually true of serial lifeycles, is that the predicted delivery date is the first day of schedule slip.  I’ve seen many serial projects get almost to that date before they first admit that they’re in trouble.

There was a comment from Pawel Brodzinski to Johanna’s post saying,

About predictability I’d say it doesn’t have to be false. Waterfall project which was properly planned and is properly managed should end around deadline and should deliver functionalities specified in requirements.

He’s right.  It doesn’t have to be false.  It usually is, however, because a serial lifecycle doesn’t give you any tools to manage schedule risk.  It only gives a prediction.  Experienced managers will guess the amount of padding to add to the schedule to give themselves a chance of meeting it.  Cautious but less-experienced managers will add a lot of padding, to increase their chances.  Of course, a development team working to meet a highly padded schedule may be so over-confident that they slow down to match, and then still miss the schedule if something unexpected happens.

In Pawel’s own blog post, he quotes Steve McConnell who describes an XP software development project that failed to produce a salable product because Customer (a.k.a. Product Owner, in Scrum terms) didn’t have a vision for a salable product.  For some reason, probably ignorance about Agile Software Development methods, Steve lays this failure on the development team creating one iteration at a time.  He apparently missed the practice of release planning.  When he says they “did it by the book,” they obviously didn’t use the book Planning Extreme Programming, which was published only a year after the first edition of Extreme Programming Explained: Embrace Change. Surely in two years the team could have read a second book.

Back to the point about Agility and Predictability, Steve says,

True agility–which means adopting a posture that allows you to respond rapidly to changing market conditions and customer demands–conflicts with predictability. Some businesses value agility, but many businesses value predictability more than they value the ability to change direction quickly. For those businesses, becoming more Agile is a second level consideration; the first level consideration is how to become more predictable.

Here, Steve seems to make the common mistake of using the dictionary definition of “agility” instead of checking the values and principles of the Agile Manifesto.  The “Agile” of the manifesto is a brand name, of sorts, to replace the wimpy “light-weight methodology” term that was starting to be commonly used at the time.  It’s a good brand because Agile does allow you to change directions more easily.  But Agile doesn’t require you to change directions and it certainly does expect you to have a direction.

How does Agile give you a predictable schedule? By giving you early, frequent, and fine-grained feedback and allowing you to steer the project to that schedule.

Let’s take a look at the release plan created at the start of the project.  First, write story cards for all of the features you want in your product.  These cards will generally be big stories, a.k.a. epics, and you’ll want to break them into smaller stories for development.  The big stories will work just fine for release planning, though.  Estimate the size of these cards.  I prefer estimating in story points, a fictional, unitless measure.  Some people like to start with ideal engineering days.  Either way, you have to guess how many of these your devlopment team can accomplish in a short iteration.  (I recommend one or two week iteration lengths.)  Count up the story points, divide by this guess, and you’ve got the number of iterations it will take to create the software.  This plan is exactly the same as the plan created by a serial lifecycle.  It’s just a guess–one made as carefully as our experience will allow–but still a guess.

Now develop software for one iteration.  How many story points did you accomplish?  Was this different than your guess?  If so, you may want to adjust your prediction to use this value instead of the guess.  Sometimes people may want to wait for three iterations before doing so, to let the team get up to speed, but they’re put on notice at the end of the very first iteration.  That makes a pretty good prediction, don’t you think?  And you can refine your prediction at the end of each iteration.  With a serial lifecycle, you’re either stuck with your original guess, or you get nervous enough that you make a new guess.

If wishes were horses, even beggars would ride. My mother used to tell me that when I wanted something that was clearly out of reach.  Sometimes a software development team just can’t accomplish all of our wishes by the desired date.  We’ll see this as we replan our schedule at the end of each iteration.  And, unless the desires and capabilities are completely out of whack, Agile Software Development gives us the tools to meet the desired date anyway.

How can we meet the date when there’s too much to do?  We do the most important things first.  And we do things at a fine-grained level.  Instead of leaving whole features to the end, we leave “nice to have” refinements of features to the end.  And we then trim scope to fit the date.

We can do this if we’re getting each little story done-done as we go.  This includes testing, so we know it works the way we want.  And it includes automated regression tests, so we know it continues to work without getting buried by re-testing.  A serial lifecycle leaves this important feedback to the very end, when there’s little time to remedy problems that are discovered.  That late discovery leads to the lack of predictability produced by a serial lifecycle.  Agile Software Development gives you more predictability than those carefully planned-up-front project plans can provide.

Oh, and yes, it can provide the dictionary definition of agility, too, should your goals change.