The is the second in a series of articles from the ALM-COE. The first article provided an introduction to Agile planning and how it’s different that traditional project planning. This article builds on the first discussion, although it is still likely to be basic information for senior readers.

“Everyone” agrees that you should be a generous person, control your diet, and use Agile processes for software development. You may have already noticed, however, that in the heat of daily choices it’s pretty easy to compromise a rigorous adherence to these principles.

 In my last article, I explained what Agile is and why it is generally better suited for managing software projects. Traditional project management — which Agile is intended to replace — is often called “Waterfall”, after the cascading bars of a Gantt chart. Because of the uncertainties inherent in building software, this approach can be described as essentially: lying to your customers, then working really hard to make the lies become true.

 There are, of course, occasions when Waterfall methodologies work quite well. No process is optimal for every team. For example, waterfall planning might make sense where delivery requirements are captured in a detailed contract that cannot be changed.

Many teams adopt what is called “Scrum-fall” or “Fragile” methodologies, which simply marry the rigid Big Plan structure to sprint-based time-boundaries. (Of course, due to the stigma of Waterfall planning, I advise you to keep your “Scrum-fall” opinions to yourself).

Core Question:
If most teams are convinced that an Agile approch will be more effective, why are so few teams able to fully practice it?

If so many smart and experienced teams have adopted what is a sub-optimal development strategy, there must be reasons behind it. Here are some of the reasons waterfall practices persist, even on nominally “Agile” teams:

  • The transition to Agile is either “soft sold” or misunderstood, so that people think it still includes detailed planning and hard commitments.
  • The teams are used to traditional project management. When transitioning to “Agile” processes the team made as few changes as possible.
  • The dependencies that other teams or customers have taken on their work require them to commit to deliver specific functionality on a particular date.
  • The teams have 3rd party contractual commitments, with defined milestone and delivery dates.

Some of these reasons are perfectly legitimate. If your customer is expecting a Waterfall-style delivery, then it makes sense to use robust project plans to meet this obligation. This illuminates my experience of the principal reason that team for following Waterfall practices:

The principal reason teams give for Waterfall practices:
Our partners and customers demand it!

If you are making commitments to the business that you will deliver specific functionality on a specific date at a specific cost, you might need to adopt waterfall-style planning. The only way to confidently know scope, cost, and delivery date in advance is to do an enormous amount of (wasted) effort prior to making that commitment.

In Agile conversations, the business should set priorities but not dates. Well, actually, there might be good reasons for setting a date — but then a business can’t set scope. If the scope of the delivery is well-defined, then applications can only be ready when testing says they are ready, not when the calendar says they are due.

HealthcareGov.jpg

Moving to Agile reduces the business’ perceived sense of control over the project. Although it’s principally in the business’ interest to move to Agile planning, businesses often resist. (For teams that may already be not delivering very well due to waterfall planning waste, this can be a difficult sell). Let’s focus on why our customers and partners are demanding Waterfall-type planning, especially when it’s not even in their interest to do so. 

What does the Customer Need?

Let’s start by understanding the problem from the perspective of your customer. Returning to the garage-cleaning illustration in the previous article: suppose that the owner does not see the first 4' by 4' section get cleaned. In fact, the owner doesn’t see any subsequent progress — until the completely clean garage is deployed into Production about six months later.

 This circumstance would cause a reasonable owner — one who needs to both manage the budget and make plans regarding when they can use the functionality — to:

  • Require a schedule with milestones and a completion date
  • Pile-on requirements to try to reduce any misunderstandings of business needs
  • “Scope-creep”, knowing that any follow-on features may be a year or more away (given six month releases)
  • Over-plan. Without the ability to assess the value of a feature by using even a limited version of it, our customers have to guess at prioritizing the full feature set

It should be clear from our Agile discussion that these completely rational responses are ultimately self-defeating. It is critical to change the conversation so that the project sponsor can understand how get what they need from within an Agile process context.

In short, many — possibly most — teams know that they should be having a very different conversation with their customers. But they can’t do that because their perfectly reasonable customers have a legitimate need for Waterfall-style planning.

Next

We need to change the conversation, but we can only do this by changing how the team delivers. In my next article, I’ll discuss steps you can take to credibly change the customer conversation.