Agile methodologies have been all the rage for the last few years and they are the new normal for most companies, including corporate IT and other homes of “traditional” development. But, just using Agile terminology and iterative development doesn’t mean that a company has embraced the full impact of the change. Most are still recalibrating their expectations and clinging to Waterfall ways of seeing the world.

On a challenging assignment a few years ago, I was working with a client that was excited about moving from a Waterfall methodology to an Agile methodology. They had an Agile Roadmap. But, they didn’t fully understand the trade-offs and, while I tried, I didn’t do a great job of explaining those trade-offs or managing their expectations in this new world. I’ve thought a great deal about how I would handle that situation again if it came up on a future engagement.

The client said something to the effect of, “At least with Waterfall, we get a firm commitment on what is going to be delivered and when.” There are a number of problems with that assertion, but the biggest was that it set the stage for a related misunderstanding: that the upfront Analysis time (sometimes called “Sprint 0”) of an Agile project is comparable to the Requirements and Design phase of a Waterfall project. That leads me to the picture below:

There is a lot of over-simplification in this picture, but the diagonal dashed line represents the misunderstanding. The client wanted a commitment for what would be delivered after development was “complete” and they wanted that commitment before we started writing code. They understood that our Sprint 0 was shorter than the Requirements and Design phase of a Waterfall project, but they had the same expectation of commitment and estimation.

So, let’s break down the issues here:

1. Apples to Oranges – At the most basic level, the two milestones are completely unrelated. Yes, going from Sprint 0 to Sprint 1 is when development begins, just like when you go from Design to Development in Waterfall. But, Sprints 1 to N are mini, full-lifecycles: they have Requirements, Design, Development, Testing, etc. all baked in. The goal of Sprint 0 isn’t to understand everything: it’s to lay enough of a foundation to get down to writing working code as part of building the solution.

1. Agile Isn’t Magic – Most importantly, there is no magic to Agile that can get you comparable answers in a dramatically shorter period of time. That’s where the solid vertical line comes in; for true apples-to-apples comparisons of when the team would be able to make reasonable commitments, we should have insisted on waiting until a few sprints were complete (in the illustration, that point is after Sprint 2). If the client were willing to wait until the longer Requirements and Design phase of comparable Waterfall projects, why shouldn’t they wait for the same amount of time in an Agile project?

1. It’s Safe to Write Code Early – But wait, how can the team start writing code before commitments are made? Because writing code (and potentially rolling it back) is much easier now than it was in the past. We have better source code control, regression testing, and other tools that take away any risk of the effort related to unwinding changes.

1. It’s Really Powerful to Write Code Early – We learn much, much more about requirements and what works / doesn’t work by writing code than by writing Word documents. So, think of Sprint 0, 1, and 2 as an extremely practical and powerful analysis period. Which, oh by the way, if things go even reasonably well, produces working code. Compare that to the zero code produced in the comparable Waterfall timeline for the same duration.

1. More Analysis Doesn’t Prevent Scope Issues – Even with all of the analysis (and even with writing working code), new requirements and revisions to existing requirements always emerge. In this case, we were making enhancements to an existing system and the client had done their own analysis of the problem, so they were absolutely convinced that they knew exactly what they wanted and that it was a discreet set of functionality. But, that didn’t stop the team from discovering related functionality that became critical. Here’s the real kicker though: Waterfall would not have fixed that problem. In fact, it would have probably delayed the discovery of the related functionality.

Waterfall doesn’t really add certainty, it just makes people feel better that it has. Agile methodologies embrace uncertainty, are more honest about it, and reduce that uncertainty faster by building stuff sooner.