Blackwater Falls

A waterfall precedes and follows rapids

I recently participated in a panel discussion that was presented with the question: 

“We have been presented with a project with a fixed budget, fixed scope, and fixed date — can we use agile to deliver this project?” 

A bit of context, the work was not a simple request that had been done many times and the software team had not had access to the ultimate customers that requested the work before the scope, date, and budget were set. Unfortunately, this is not the first time I have heard this question this year. The simple answer is that the team can’t be agile in this scenario although they may use specific agile techniques. Just using techniques doesn’t make you agile. One of the reasons the ‘you can’t be agile’ answer is so easy in this scenario is that this type of project explicitly clashes with two of the values in the Agile Manifesto. They are: 

Customer collaboration over contract negotiation

Fixed everything projects represent a contract whether formally enshrined and countersigned or assigned by a manager. Participating on a fixed budget, fixed scope, and fixed date projects with unknowns is an extremely risky proposition. This type of project just doesn’t make sense to developers but is seemingly easier to sell or make sense to those who view knowledge work projects as if they are buying a retail product. As a point of order, these types of projects generated some of the most horrific death marches and quality failures I have seen during my career, whether waterfall, spiral, iterative, or agile (and they really can’t be agile) they are really bad ideas.

Responding to change over following a plan

Fixed scope implies that everything that needs to be done is known before the project starts. Because we know that it is not possible given the context of the scenario someone will have had pre-decide on an approach, which flies in the face of delaying decisions until the last responsible moment and using the freshest knowledge to inform decisions.

With a little mental flexibility, you can make a case that fixed everything projects violate the other two agile values, but overkill is not necessary. Fixed budget, fixed scope, and fixed date projects are not agile. That said, while being agile is out of the question, doing at least some agile techniques is possible. Why would you eschew sprints or a continuous flow Kanban approach? Would you stop doing stand-ups/daily Scrums to replan or swarm to work if someone was in trouble? Using agile techniques is a separate discussion which is the genesis of the Being Agile versus Doing Agile debate. In a fully fixed scenario, some techniques might be useful but generate frustration. For example, Sprint Reviews/Demos are tools to get fast feedback. However, you will have to decide how to deal with feedback if it broaches any of the fixed constraints — this will generate a discussion about whether to do interim reviews or not which will take you further away from being agile. 

The question that needs to be addressed is not whether you can be agile and still do projects with everything fixed but rather, how can we change the behavior that makes this type of project possible. We will spend time on this topic next.