Welcome Changing Requirements - "Agile and the Triangle"

If there were a vote to choose the “Most Controversial Agile Principle,” this would have to be the odds-on favorite:

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

At first blush it appears to fly in the face of logic. How do you hit a shifting target, or get more done with the same resources?

Changing Requirements are Natural

First of all, let’s dispel the notion that any change to requirements reflects a lack of discipline. There are a number of legitimate reasons for changing requirements; 1) The market doesn’t freeze in time once a software development project begins, but continues to evolve over the course of the project; 2) Given more time and thought, the business thinks of a better approach for a given feature; 3) During development, a team member notices a gap in the requirements; 4) An external dependency (e.g. an integration point is replaced) changes; 5) Despite best efforts with business analysis, a few missing stories come to light.

All of these scenarios can lead to the addition of stories to your story backlog.

Changing Requirements Present Challenges

OK, so we should be flexible and understand there are good reasons for many new requirements. However, experience with dozens of customers tells me that changing requirements can present some major challenges:

• 
  Increased Project Scope – Most projects have plans with expected delivery dates. As the need for additional functionality is identified, new stories are created. Example:

Client: Our plan looks good going into development, but so much gets added during development that needs to be done on top of what we already agreed to.
Me: What is the result?
Client: What had looked doable is now highly in doubt. We’re missing deadlines and morale is down.

• 
  Refactors – If the business changes their minds frequently during and/or after development is complete, you could have a number of refactor stories added to the story backlog. Example:

Client: Changing requirements are driving my team crazy.
Me: How so?
Client: Right in the middle of development, the business will change their minds about what they want and we have to scrap what we’ve done and start over.
Me: What is the result?
Client: Scheduled work gets pushed out, the overall deadline shifts out, and the team morale goes down because the business can’t seem to make up their minds.

• 
  Mid-iteration plan changes – Sometimes critical needs arise and the business asks you to add new functionality to the current iteration. Example:

Me: Any other issues?
Client: Actually, productivity suffers when priorities change mid-iteration. The business wants us to drop what we’re working on, do the rush job, then still get the rest of the work done within the iteration.
Me: Are you able to get everything done?
Client: Sometimes, but it means longer hours and lower quality work. Of course, the developers get blamed for the poorer quality. I’m afraid my team members might look elsewhere if our environment doesn’t improve.

Changing Requirements = Evolving Plan

Disciplined projects and teams have a high level plan such as a product roadmap. They also have iteration plans. These plans are sometimes frustrated by the steady trickle of new and changing requirements that pop up over the course of a project.

So how do you reconcile a plan in a changing world? Well, you consider the software development triangle, sometimes called the "iron triangle":

In other words, there are three variables that you can alter, but by altering one you must make a corresponding alteration in one or both of the other variables. For example, any change to Scope would require a corresponding change to Resources and/or Time. The main point here is that the triangle still applies to Agile projects. This shouldn’t discourage change. Alter the plan to do what makes business sense rather than sticking doggedly to a plan that is no longer optimal.

I have read some thoughts on “tricking” the software development triangle, such as this article by Alistair Cockburn. I like his thoughts on how the Agile process can increase the efficiency on a previously non-Agile project by up to 30%, thereby increasing your capacity without touching the triangle’s variables. This can be true when you enter a project that has already been planned but where Agile practices have not been applied, or have not been applied properly. If you have a project that was planned with the assumption that you would be using Agile practices then you have already accounted for the expected increased efficiency. The constraints of the triangle still apply, and you’ll need to work closely with the customer to balance the plan with any changing requirements.

Agile is Not a Crutch for Sloppy Business Practices

Although Agile is meant to be flexible enough to adjust the plan based on a changing market, Agile does not accommodate sloppy business practices, bad requirements, constant refactors due to lack of thought, etc. The point is to support common sense tweaks to an already well thought out plan.

If you are crippled by critical last-minute requests and requirements that change every few days, take a look at the following:

• Business analysis quality – Is the business doing a good job of thinking through the requirements before the story hits development?
• Technical review quality – Is the team (dev, QA) adequately reviewing functionality before it hits development to confirm that it’s ready for prime-time?
• Accountability – If the same people are causing chaos by poor planning, are they held accountable, i.e. does management realize the side effects?

Flexible Project Plans, Firm Iteration Plans

All of this leads to my opinion that, while welcoming changing requirements is more important than the plan, an iteration plan should rarely need to be changed. If you have disciplined business analysis and business practices, you should be able to plan at least 2 weeks out. This creates an “eye in the hurricane” which helps development efforts maintain focus, thus optimizing productivity and resulting in frequent, quality releases and return on investment for the customer. Here is a link to a related post called The Cone of Sanity.