It’s tempting to imagine a world in which all projects are started without deadlines and continue until stakeholders decide enough value has been delivered.
In some organizations this is reality. But in other organizations, teams must often grapple with:
- Fixed-date projects in which a new or improved product must be delivered by a defined deadline.
- Fixed-scope projects in which a set of features are all required before the product can be delivered.
- Fixed-everything or fixed-price projects, which lock down both the delivery date and the features that will be delivered by that date.
Agile Is Context-Dependent
Is it possible to be agile when crucial elements are out of your hands? In my opinion, it is: teams can be agile when date, scope, or both are fixed.
Being agile is context-dependent. A team of three people working on a mobile app in their garage has the opportunity to be more agile than a large, distributed team building medically regulated hardware.
This is due to their contexts. The latter project will undoubtedly be required to produce more documentation; to more rigorously control, or at least document, change; and to do other things that reduce the agility of that team.
And that’s fine.
Being agile covers a broad range of activities, just like being healthy does. A team can be more or less agile in the same way you can be more or less healthy.
As an example, I had my annual physical exam recently. My doctor told me my total cholesterol is fine. It’s good, in fact. Except for one element of my cholesterol—the number of triglycerides in my blood is higher than it should be. I asked my doctor what I could do to improve that value. One of his top suggestions was to change my parents.
Since I can’t do that, my goal is to be as healthy as I can be given the context in which I find myself. An agile team should strive to be as agile as it can be given its context.
Context Can Be Defined by Those Outside the Team
The context for some teams is that they are told by bosses, clients, or customers that a certain amount of functionality is needed by a given date, possibly even for a fixed price.
These projects are not as agile as they could be. But they can still be agile within that context.
Would the teams working on these projects be more successful and more able to exceed customer expectations without contracts guaranteeing a delivery date, scope, or both? Very possibly. But that isn’t their context. We can’t just wish reality away.
Fixed-Price Projects and the Agile Manifesto
Let’s see how fixed-price projects align with the values of the Agile Manifesto.
Individuals and Interactions over Process and Tools
First up: individuals and interactions over processes and tools. Nothing about locking down the scope, delivery date, or both of a project means de-emphasizing the importance agile places on individuals and interactions.
Great products will still be built by great teams who communicate well. Some of that communication may be prescribed by a contract. But there’s nothing to say a team can’t communicate more effectively or more frequently than is required by contract.
Working Software over Comprehensive Documentation
Working software over comprehensive documentation is the second value of the Agile Manifesto. Contract development projects will almost certainly have more documentation than their non-contract counterparts.
However, a common trait among well-run fixed-scope and fixed-date projects is that the team will frequently demonstrate and deliver working software to stakeholders.
Customer Collaboration over Contract Negotiation
Customer collaboration over contract negotiation could be the agile value that sounds most at odds with fixed-date and fixed-scope projects. But it doesn’t need to be. Even with a contract defining the relationship with client and vendor, a team can still collaborate with its customer.
In even the most detailed written contract, there will be gaps—gaps in what’s written, gaps in what’s actually needed, and gaps in how the contract is interpreted. Seek to fill these gaps with a collaborative mindset.
Responding to Change over Following a Plan
The last value of the Manifesto, responding to change over following a plan, describes one place where collaboration is vital.
How a team and its stakeholders handle discovering change—or what wasn’t known at the start—is often a big factor in whether a project is viewed as successful or as a failure. We want to build and follow a change management process; it is as critical to agile as it is to success with fixed-date and fixed-scope projects.
Principles of the Agile Manifesto
The Agile Manifesto also comprises a dozen principles that underlie the four values. I contend that each of the twelve principles complements fixed-date and -scope projects. And a couple are worth singling out.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” is the first principle of the Manifesto, and for good reason. While working on a fixed-date or fixed-scope project, look for opportunities to deliver enough value that the customer may not need everything they initially anticipated.
One of my first jobs out of university was working at one of the very large computer consultancies. After being there a few months, I remember having lunch with my boss, a partner in the firm, who told me my job was to find ways to expand the scope of the projects I was placed on. That was to always be my first concern, he said, even over successfully completing a project.
Needless to say, I left that firm a few months later as soon as I could find a company more interested in partnering with its clients.
Instead of looking for ways to expand the scope of a project, keep an eye open to finishing early by creating a product with enough functionality that the rest isn’t needed.
Welcome Changing Requirements
I think one of the most important principles of the Manifesto is, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Change happens. We know it. We may need to convince our bosses, clients, and customers of its inevitability, but that can be done.
The other ten principles of the Manifesto, including emphasizing simplicity, motivated individuals, face-to-face communication, sustainable pace, self-organization, reflection, working together, and delivering frequently, all also support projects with fixed dates and scopes.
Are Fixed-Price, -Scope, and -Date Projects Agile?
So, are these types of projects agile?
Yes, they can be.
A team’s goal should be to be as agile as possible given the context in which the team works. All projects have constraints. A project for which the team has seven people and the team cannot be expanded needs to be agile within that context. A team that is told it must deliver by a certain date needs to be agile within that context.
Think of constraints as defining the solution space within which a team operates. There is of course a point where if you put too many constraints on a team, not even agile will help team members find a solution.
But a more manageable set of constraints still leaves room for a team to be agile. They won’t be as agile as a team without those constraints, but they can still be agile within that context.
What Do You Think?
What is your opinion? Can fixed-price, -date, and -scope projects be agile? Have you worked as part of an agile team to deliver these types of projects? Please share your thoughts in the comments section below.
