Losing the Battle One Hill at a Time: Scope Creep in an Agile World
When I was in the Army, I learned lots of helpful phrases to describe novel contexts. One that was particularly useful (and might be shared in polite company) came up when there was a disagreement with your point of view, you knew you were right - but escalation of the conflict had potential negative consequences beyond the question at hand:
“Is that the hill you want to die on?”
The question here was whether attempting to win the battle was worth the potential sacrifice.
This isn’t the same as, “don’t sweat the small stuff”. Some issues/hills are important and worth going all in – but most probably aren’t.
This pithy phrase came to mind as I was reviewing progress on a troubled Agile project. Like many poorly conceived public sector Agile projects, this one began with a fixed price and fixed schedule to replace an existing production legacy system. Here’s the thing, when cost and schedule are fixed, the only element that can flex is scope. Because a production legacy system used by thousands of people was being replaced, there wasn’t much functionality that could be deferred.
An unambiguous definition of done and clearly specified requirements are vital If you are going to do a fixed price, fixed schedule project. Unfortunately for this situation, the only definition of scope was a years-old document of high-level requirements and the current, poorly documented, production system.
While contracting with this level of specificity is risky, this isn’t necessarily a recipe for disaster – a contractor normally bids a fixed-price that includes an insurance policy/risk buffer to avoid going bankrupt at the first requirements controversy – normally ten to thirty percent of the bid amount depending on the size and complexity of the project. The goal of project management is to effectively manage scope so that most of that ten to thirty percent is kept as profit, rather than spent to put whipped cream, sprinkles, and a cherry on top of the system the client wanted.
The problem in this case was the “Agile hype”. When selling the project to the client, the delivery vendor convinced the client that agile practices were a panacea. The client would see each screen and report as they were built, enabling fine tuning, and avoiding the tragedy of waiting until the end of the project only to learn they didn’t like the result.
The client took the vendor at their word. Each screen and report were scrutinized and polished and tweaked to give the demanding client what they wanted. This took time. Some of the things the client asked for were not present in the existing legacy system and were arguably outside the scope of the high-level requirements – but they were small things. I can imagine the project manager wondering,
“Is this the hill I want to die on? Do I want to push back on this little request? It will only take a couple of hours to add this column to the report, and a couple of hours to test it, and a little more time to document it, and then a few minutes to cover it in the training. We want to keep the customer happy. This is customer-centric development. This request will only take eight hours – max. It’s not worth the hassle to push back.”
“Scope creep” is the slow expansion of the scope of a project through little decisions that accumulate until it is a struggle to deliver the project within the time and resources available. It’s related to another pithy phrase:
“Dying the death of a thousand paper cuts.”
If each change is “only a few hours”, but there are hundreds (or thousands) of them – they add up fast. Furthermore, when a project manager or product manager who has silently accepted each prior change finally attempts to rein in a customer and remind them about “Minimum Viable Product”, they can seem like jerks, and it can sour the customer relationship.
To everyone’s dismay (but not to my surprise) the cost and schedule of the project have increased significantly. Trust issues have emerged between the vendor and the client. Is the client trying to constantly “expand scope”? Is the vendor failing to deliver all that was promised?
Scope discipline is essential on all projects. Having a requirements baseline that is clear and unambiguous establishes necessary guard rails for the project. Requirements are going to evolve and change – but we need a baseline so that we can discuss whether a proposed change is within our agreed upon scope or requires a renegotiation of our agreements and resetting of expectations. Scope management may be harder on Agile projects when overzealous marketing hype sets unrealistic expectations about unbounded flexibility with customers.
Managing scope is challenging and project managers and product owners must be constantly vigilant. Set the tone early with your clients. Build a “Version 2” parking lot for functionality not essential to MVP and enlist your customer to help you defer anything that can be deferred. Being overly accommodating early in the project can sow the seeds for future disaster. Choose your battles wisely - but retreat every time and you will lose the war.
