Agile Contracts: Creating and Managing Successful Projects With Scrum

Agile at ArcBees

Agile is embedded in the ArcBees way of life. It drives our culture and productivity. However, many new clients have no prior experience with Agile. It is usually easy to explain how Agile leads to better software, but sometimes they struggle with the business implications. How can they sign a contract to build a product when they don’t know exactly what they will get?

The book Agile Contracts Creating and Managing Successful Projects With Scrum by Opelt et al., highlights four contractual mechanisms that give business owners the predictability they need. It offers a model of project governance that meshes perfectly with the realities of Scrum project management. For Agile teams, Agile Contracts are crucial Agile software development tools, as important as Scrum boards or Kanban boards. This article summarizes this Agile development tool, emphasizing the way we apply these concepts in our work

What Is Agile?

If Agile is new for you, here’s the big idea behind it: the key Agile insight is that old-style “waterfall” project management practices, which were plan-driven (rather than feedback-driven), generated bad products. Those products were buggy and bloated with features people didn’t use. Those projects were also always late and over-budget.

Why? Delayed feedback. In the old days, to create software, you would:

• Gather requirements in advance
• Then specify software features
• Then design the software
• Then develop the software (for months and months)
• Then have a QA department (not end-users) test it
• And finally deploy the software, maybe a year after you gathered requirements.

In other words, you only got real feedback from real users in real work situations at the end of the process. All the key decisions were made in advance, based on guesswork. It was disciplined guesswork, but still guesswork.

The Agile remedy is to build a small product with just a few features and give it to real users. You build that as quickly and cheaply as possible, and watch people use it. Then you improve the product based on what you learn. It’s empirical. After many cycles of real-time feedback, the end product is well-tested, useful, has only those features people need, and few surviving bugs.

The Illusion of Predictability

Here’s the hard truth. Old-style estimates have always been pure fantasies. Budgets based on them were always blown away. We need to stop wanting the false reassurance that fortune telling (planning) provides. Instead, we should pragmatically confront the mix of certainty and uncertainty that is inescapable in software development, and set up mechanisms that let us make the right decisions at the right times to manage cost and limit risk.

Agile Contract Mechanisms

The key cost/risk limiting mechanisms that Opelt et al. define in their book are:

1. Estimates
2. Riskshare Ratios
3. Checkpoints
4. Exit Points

1. Estimates

Cost vs. Time Estimate

Opelt et al. call cost estimates “Indicative Fixed-Price Ranges”. On the one hand, this is useful because many Agile teams work hard to do time and effort estimation during projects, and this is not exactly the same thing as cost estimation. For example:

• The cost of developers’ time varies depending on their skill set and seniority, which impacts cost.
• Complex projects require more coordination and project management overhead cost.
• Projects that have to meet higher performance benchmarks require more testing, debugging and refactoring at every step.

So there is more to cost estimation than raw time/effort estimation. However, as long as we keep this difference in mind, we can talk about the first concern of Agile Contracting as the “cost estimate”, instead of using the less-familiar term “Indicative Fixed-Price Range”.

Levels of Cost Estimation

You can do cost estimates for the Whole Project, for Exit Point Phases, and for Checkpoint Phases.

Whole Project Estimates define the outer limits of cost, based on our best current information. They are not contractual promises. Because of the nature of software development, the business owners and development team will need to discuss the project as work progresses, which may impact the final cost.

However, at the outset, the Whole Project Cost Estimate defines the maximum that a client will be charged, unless they decide otherwise. The developer team promises to honor all the mechanisms of the Agile Contract that govern the process of managing cost as the project evolves.

The Whole Project Cost Estimate is based on what Agile practitioners call “Epic” use-cases that describe the software’s main functions. These are the most general Agile specifications, and developers never make exact promises about exactly how long it will take to build things at the Epic level. It would be irresponsible to pretend exact estimation is possible at this level.

However, Agile teams break large projects down into smaller chunks, and can do a fairly detailed time/effort estimate for what they will do in the next chunk as they prepare to do it. We work in “Sprints” of 2 or 3 weeks. We also know who will be doing the various tasks in a Sprint, and what the performance benchmarks are for the features in that Sprint. This means that the cost estimate for a Sprint is much more accurate than the Whole Project Cost Estimate, and we can guarantee how much functionality will be delivered in that brief time period for that specific price.

These low level, one-batch-at-a-time estimates are sure things. As the project progresses, we can see how many of the Epics are realistically getting built within the fixed cost for the project, and adjust our expectations for project scope.

Agile practitioners always prefer to adjust scope, building simple, solid products missing some bells and whistles, in order to deliver on time and on budget. Experience shows the simpler projects usually meet the client’s business need. Hard time/budget limits force good decisions about what features matter most.

Agile Contract Mechanisms

We make Agile Contracts because we accept the reality that large-batch estimates are unreliable illusions. This is an unfortunate fact of life. Small-batch estimates are more accurate. Agile Contracts therefore set a hard outer limit to project cost, and define a schedule of two kinds of business meetings for where clients and developers discuss their business deal. These meetings are Exit Point Meetings and Checkpoint Meetings. Both are described below.

The key point to emphasize here is that the Whole Project Estimate freezes the outer limit for project cost, and there is a clear process for monitoring progress against cost. In other words, the Agile business deal has a “brake pedal and steering wheel”, as well as a “gas pedal and ignition key”. It has clearly defined mechanisms for making adjustments in the face of reality. It is not a money train where clients risk falling asleep, and waking up later to find out they missed their stop and are now many miles farther than they planned to go.

2. Riskshare Ratios

Agile has a little secret. The planning fallacy never goes away. Estimates for a Sprint are more accurate than estimates for a Whole Project, but it is still common to underestimate how much time and effort it will take to build software, even if you are only planning a 2 or 3 week Sprint. So how can we guarantee to be on time and on budget?

Sprint Risk: Borne by Developers

Basically, Agile teams assume 100% of the cost overrun risk within a single Sprint. If our team accepts too much work during a Sprint, and we had to work long hours to get everything done on time, we eat those costs. We deliver the Sprint on time and on budget as promised, no matter what. Of course, based on what we learned, we make a more realistic estimate for scope of work in the next Sprint.

Scope Adjustment: Risk Shared 50/50

Since we accept the Whole Project Cost Estimate as a fixed outer limit on project cost and duration, this means that if it turns out that the initial proposed scope of the project was too ambitious (it often is), we need to discuss how to make the scope more realistic with clients. Clients also often decide they want new features they had not thought of at first, or they want existing features to behave differently.

We try to make all these changes “free” changes by suggesting tradeoffs, or simpler ways of achieving product goals. If the client is willing to consider these adjustments, we try to accommodate that without charging more, even though sometimes that means some extra effort on our side. We share risk 50/50 in this process of mutual adjustment, so long as the adjustments are reasonably manageable.

Note that project scope may need to be adjusted even when the client has not asked for anything extra. If developers building the software discover it will be much harder to build than we thought, this is an objective fact. The planning fallacy was the illusion, but the real complexity of the task, confronted by people trying to implement it, is real.

After discovering this complexity – and realizing that we all made the planning fallacy when we drafted the Whole Project Cost Estimate – we have two choices: define a more realistic scope (shared risk), or expand the project scope.

Scope Expansion: Borne by Client

If clients insist on having their full wish-list of Epics built, even though new evidence has made it clear that their project is bigger in reality than anybody anticipated, this counts as an expansion of project scope. We know it does not feel like expanded scope: you said you wanted those Epics built, and we estimated we could do it, but there is a real risk whenever you plan to do something ambitious. There is a real risk that it will be harder, take longer and cost more than you planned.

Please understand this going in to a software development project, and face this reality with open eyes. We will try to work with you to adjust scope and give you a product that solves the main problem you want to solve. But if you are not willing to adjust scope in light of new evidence that the project will be harder than anticipated to complete, that is a risk that you must bear.

The same constraints apply when you look at how early iterations of your software function for users. If, at those times, you add features to the wish-list, or ask that features be substantially changed, you must realize that this can have an impact on project scope.

It’s the same if you decide to significantly reposition or redefine your product, fundamentally changing it at the “Epics” level. This creates a situation where you are essentially asking for a new project, from our perspective, and the whole business deal needs to be revised.

These are critical decisions of great strategic importance, and we think it is very important to schedule regular opportunities to monitor progress and consider these issues. Those scheduled opportunities are called Checkpoint Meetings.

3. Checkpoints

I mentioned that we work in Sprints, and we interact with clients at the beginning and end of every Sprint, but these Sprint Planning Meetings, and all the other common Agile Project Management Events, are not Agile Contract Checkpoint Meetings.

Agile Contract Checkpoint Meetings can be scheduled in different ways. They might take place after a fixed number of Sprints, or after completion of a certain number of Epics, or Agile work units (called “story points“). They can also be scheduled as needed whenever news from the development team requires a business response.

Contract Checkpoints are business meetings, not project management meetings. They are meetings where we examine and update the hypothesis on which our business agreement is based. For example:

1. We might suggest we can deliver a better, more minimal product at lower cost. If you agree, we shrink the project scope.
2. You might decide you need to reduce or slow down your spend, and so some features can be dropped. We can adjust our estimate to match.
3. We may mutually decide to re-scope the releases of the product, doing it in phases and postponing work on some features until a later release.
4. Users may not be using the product in ways you expected, and you may need to pivot – to change the product’s goals and direction. This changes our estimate.
5. You might be concerned that our “burndown rate” (task completion rate) shows the project may run long or exceed budget. We can discuss if this is so, along with mitigation strategies.
6. We might be concerned that your feature requests will exceed your budget, seek verification that you can afford the scope increases you want, or draft up an addendum to our initial agreement to formally expand scope. Terms for the addendum might include partial advance payment for the additional scope of work.

Checkpoint meetings provide us with an orderly way to govern scope changes and manage costs, and they do it in a way that deals with the inherent unpredictability of software development, instead of pretending we can make it go away.

4. Exit Points

Exit Points are clear conditions or junctures where the parties may terminate the project in a controlled manner. Some Exit Points are traditional and obvious, like non-payment of an invoice, or cost overruns. Others become available as a benefit of Agile.

In Agile, we try to deliver functional iterations of client products as often as possible. The goal is always to leave product owners with usable software, even if a project has to be halted early. This gives clients more freedom. There are viable Exit Points in Agile projects, where clients can walk away with a complete, production-ready software product they can use. We can schedule one or more Exit Points during the course of a project, with the stipulation that the product be ready to ship prior to each Exit Point Meeting.

Scheduled Exit Point Meetings are less frequent than Checkpoint Meetings. Exit Point Meetings can also be set up as needed, if scope/cost issues are raised during Checkpoint Meetings that cannot be resolved. During such Checkpoint Meetings, one or both sides think they may need to exit the project. This should not be decided right away. Instead, an Exit Meeting should be scheduled.

In preparation for the meeting, the development team can determine how much work is needed to make the current iteration of software ready to ship, and clients can review their own cost and scope expectations for both an Exit and a Don’t Exit scenario. If Exit proves to be the best option for the project, the process of finalizing the current iteration and amending contracts can be planned out and executed using an orderly and cooperative process.

There is also, naturally, an Exit Point meeting at the end of the project! It’s not just a celebration, but also an orderly way to make sure the product is shipped and working as promised, that all payments for work are finalized, and all development contract obligations are complete, and if ongoing maintenance and support work is needed, that these matters have been finalized as well.

Conclusion

Software development always involves some uncertainty regarding what the scope of the project is, and how much it will cost. The best way to manage this is to construct estimates based on Agile best practices for sizing stories (units of Agile work), and to wrap the cost/scope estimates with an orderly process for revising them. That way any and all scope changes will be well governed across the project lifecycle.

Even if the estimate is good, it will not reflect the final cost of the project to the penny, and so cannot be committed to as final during the creation of the contract. However, following the Agile Contract process can be promised with full certainty, and the mechanisms of this process make the risks of software development manageable.

This blog post has offered a very brief overview of an important book, as it applies to our work processes at ArcBees. To see how these ideas apply to your own Agile practices, we encourage you to get a copy and enjoy!

Agile Contracts: Creating and Managing Successful Projects with Scrum.
Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr.
Wiley 2013