Does it work at all? Let’s dig into Agile’s origins.
Fixed scope clashes violently with the flexibility so fundamental to Agile approaches.
Agile needs a different mindset than methodically working through the lines of a requirements list. The ‘delivery what we agreed’ of fixed scope, against the ‘respond to change’ of Agile.
For a moment, let’s imagine we’re a project manager. A bloody good one. One who prides themselves on our ability to solve challenging puzzles. To make complex things appear simple.
We’re face to face with a new client. This client has insisted on a fixed scope and fixed price project. They won’t budge on the expectatio. Both sided has signed the contract (or SOW) which includes this fixed scope clause.
We’ve had zero involvement up to this point. Which means we couldn’t have done anything different. So we need to work out how to pull something brilliant out of the bag.
Turning to the client, we call a short meeting break. We head to a quiet breakout room and scream into a cushion for several seconds.
Once we’ve recovered our composure, we start to wonder; Can Agile still deliver success with a fixed scope?
Agile will need to be agile
Waterfall and similar are fixed-scope phased delivery methods. But Agile is about responding to change. Prioritising the delivery of value early and often.
Let’s consider whether vanilla Agile is capable of handling this fixed-scope situation. Our goal is flexible delivery of a fixed scope and price project.
Will Agile work? How we define Agile will be critical. Let’s avoid the complexity of Frameworks and add-ons. Here we’ll only consider core Agile.
———
I considered the rules set out in Agile’s 12 principles in my Agile without a framework article. Are they enough to implement Agile as a realistic delivery approach?
Spoiler: Yes, they probably are with a few tweaks.
I’ll take a similar approach to the question posed on this occasion;
“How does Agile work for a project where the client expects fixed scope and price?”
Let’s take another deep dive into Agile’s 4 values and 12 principles. Considering if anything forbids us from delivering a fixed scope and price project.
The Four Values of The Agile Manifesto
As you likely already know, four pairs make up the principles of Agile. Each pair has two disparate priorities.
But we don’t need to choose between the two sides. The Agile Manifesto is very clear:
while there is value in the items on the right, we value the items on the left more.
Let’s review the values and consider our fixed scope and price work.
Individuals and interactions over processes and tools
We should be more focused on people than processes. On discussions rather than tools.
Our client must take part in regular discussions. Where relevant, we should ask them for feedback and clarifications.
Nothing about that stops us using Agile for our fixed scope.
Working software over comprehensive documentation
Fixed scope likely comes with a specification document. Working software would follow that.
This value actually focuses on documentation created specific to the project outputs. Documentation created during our project. Not anything from before our work. In any case, a specification is unlikely to contain enough to rate as comprehensive.
Nothing stopping us using Agile for our fixed scope there. Let’s continue!
Customer collaboration over contract negotiation
We likely have a some form of specification or requirements document. It defines What we’re creating in detail. In such a situation, client stakeholders will often stand back. They’ll instead refer to the documents and wait for delivery of the thing.
We’ll need close collaboration. More than average Waterfall levels to align with this value. Classic waterfall won’t work.
If we deliver value early and often, and ask for feedback* and regular testing, that might work. Even getting approval of parts of the project as we go.
Assuming we do that, there are no issues with this value either.
*Let’s come back to the challenge of asking for feedback when we have fixed scope. It’s not easy to combine these things, but there are options.
Responding to change over following a plan
We’re definitely in trouble here. A classic Waterfall approach would mean following a specification. No responding to changes.
What’s needed is something clever to allow responding to change. When the scope’s fixed, we’re supposed to be following a plan.
Again, there are options. Let’s come back to this one too.
The Twelve Principles of The Agile Manifesto
Now let’s run through the Agile Manifesto’s principles. Any of the twelve might be enough to stop us applying Agile to a fixed scope or price project.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This will impact how we deliver the work. We cannot create everything and then delivery it in one go. You would only handle it that way for Waterfall project.
But this principle doesn’t stop us working through an agreed scope. Let’s continue.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
As you may know, change requests happen on most fixed scope projects. I’m against accepting them. At least not regularly or easily if the price is fixed.
There are two types of change that do work.
The first is adding a new requirement, when a similar sized item is being removed. Where a mountain of discovery is not needed for the new item, and the work required is similar, that can succeed.
The second is to change more detailed choices inside a single requirement. If the documentation isn’t detailed enough, and things aren’t hard to change, do it.
So some changes are acceptable even in Waterfall.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
As above, we can deliver fixed scope work in increments without an issue. We should. It’s a good habit to get into.
Business people and developers must work together daily throughout the project.
This is possible with fixed scope. But if we have detailed requirements, and change isn’t an option, it might not be a good use of time.
It will depend on the level of detail the documentation goes into. That and the availability of our stakeholders.
This can happen with fixed scope though.
Working software is the primary measure of progress.
Again, incremental releases are key to success here. We’ll have to put quality ahead of checkboxes though to satisfy this one.
For some agencies, we may not be talking about software. The principle works anyway. Exchange ‘Working software is’ for ‘Finished outputs are’ or similar.
Simplicity — the art of maximizing the amount of work not done — is essential.
Here, we don’t have control at the requirements level. But we can consider it when we drill down inside a requirement.
We should focus on delivering visible things. Aspects of a project that either users or the client will experience. Limit doing bespoke work on hidden parts of the project.
Don’t make a habit of working on things which won’t be required immediately. Don’t lay broad foundations for potential future update. Don’t apply layers of design work to mostly hidden parts of the outputs.
Avoid over-delivering. No scope seep — where the team add things without a client or broader discussion.
So it’s just as important with fixed scope as Agile. Do less where it’s not adding obvious value.
How well does fixed scope work align with Agile Manifesto values and principles?
We must still contend with two sticky Manifesto Values
Customer collaboration over contract negotiation
and
Responding to change over following a plan
I suggested options are available for both, so what are they? If you’re reading this article, there’s a high chance you have experienced Agile and are looking to use it more (not less). In which case this might be useful.
Customer collaboration means asking for feedback and accepting it. We desire transitioning our rigid clients and rigid projects over to Agile. So feedback and requests are actually a great opportunity to have that conversation.
“You asked that a fixed scope clause be added to the contract. But we’re delighted you agree we should focus on delivering current needs. What we thought was needed when the specification was created is less important. Let’s get an updated contract signed and move forward with our eyes open to opportunities”
The language needs work, but the central message is valid. Allow change, but only where change is seen as value, not risk.
Responding to change might mean passing regular suggestions to the client. If they agree to them, then we progress to the option to change delivery approach and update the contract.
Agile delivery of fixed scope
So the answer to the fundamental question, is yes. We’d have to be selective about feedback requests and responding to change. But we could arguably sneak under the core Agile banner even with a fixed scope.
How does Agile work for a project where the client expects fixed scope and price?
Realistically though, let’s face it, it doesn’t. For the purposes of avoiding risk and delivering what the client is expecting, we’re best to:
- Consider early if the client would consider some protected requirements. With the remaining project being value-driven. This can sometimes be the sweet spot for a client
- Stick firm to the initial scope
- Reject change requests, or update the fixed scope and price if they’re critical to success
- Turn down the work, unless there’s a key reason for taking on the project. Such as a big new client, or high likelihood of Agile delivery in the future
Opportunities to transition
Where fixed scope doesn’t align to the values and principles of Agile, we often find a lever. We can apply them to help encourage transition from fixed scope to flexible.
Being savy can allow us to convert even the most risk-averse fixed-scope fan. They may come to love value-driven delivery.
Over delivering can be successful, but it must be within the bounds of the fixed contract. This method allows showcasing the benefits of your preferred approach without risk. Anything bigger could derail the project plan the client is measuring success against.
If you can relate to these challenges at your agency, I offer a free foundations workshop that helps agencies like yours make fast progress in these areas.
If you’d like to discuss implementing better processes, or the agency delivery approach workshop, get in touch via LinkedIn or via this site. If you’re outside Manchester then travel costs apply. It lasts about 3 hours.