Dr. Dobb's | Agile on a Fixed Budget

Scott examines strategies for dealing with constraints that business stakeholders may put on software development teams.

I'm often asked how you could possibly do agile software development given a fixed budget. The good news is that, yes, in many cases, it is in fact possible to work under these sorts of restrictions and still be agile. Because your budget isn't the only potential restriction you may face, this month I explore strategies for dealing with the common constraints your business stakeholders may choose to put on software development teams.

A common concept within the project management community is the iron triangle (Figure 1), which says that of the three factors of resources, schedule, and scope at least one must vary, otherwise quality will suffer. Quality suffers because of shortcuts and/or poor decisions made by technical staff in order to conform to the constraints placed upon them. Ideally all three factors should be allowed to vary, giving you the greatest management flexibility, but that rarely occurs in practice. I explored this concept in detail in my March 2003 column "Iron Triangle: Something's Gotta Give" (www.ddj.com/dept/architect/184414962).

An implication of the iron triangle is that although your team may face some constraints, you still have some room to maneuver if some factors are not constrained. Although many people say they are worried about how to manage a "fixed-price" or "fixed-estimate" project, their real concern is how to manage a "fixed-everything" project. This is the worst-case scenario, so let's not start there. Instead, let's explore strategies for how to work when each individual factor is allowed to vary. With this knowledge in hand it becomes much clearer what management options you still have for your given situation.

Variable Scope

When the requirements for a software development project are allowed to vary, your best strategy is to work in short, time-boxed iterations delivering working software on a regular basis. Working software provides concrete feedback to your stakeholders, enabling them to determine whether what you have built meets their needs, and if not, to direct you accordingly. A common agile strategy—found in methods such as Extreme Programming (XP), Scrum, and Agile Modeling—is to work on requirements in priority order as defined by your stakeholders and to allow stakeholders to change the requirements as the project progresses. Working in priority order enables you to maximize the return on investment (ROI) as defined by your stakeholders yet remain flexible enough to build software that meets their actual needs. Figure 2 shows the OpenUP's (www.eclipse.org/epf) strategy for treating all work items, including requirements, in this manner. It adopts Agile Modeling's strategy of "Model a Bit Ahead" when you have complex work items to address in the near team, enabling you to increase your team's velocity by paving the ground ahead of it.

A common problem with allowing requirements to change throughout a project is that stakeholders will try to motivate you to do more than you actually can in an iteration, putting you at risk. If you actually have the time to implement the feature then by all means do so, but if not then either ask them to wait until a coming iteration or to remove an equivalent amount of work from the current iteration. An analogy that I like to use is a shopping cart. If you have $50 to spend and you've already filled up your shopping cart with $50 of stuff, to add a $4 bag of cookies into your cart you need to remove at least $4 worth of existing food. Stakeholders understand this comparison, and once they see that you deliver working software each iteration, they quickly recognize that they eventually will get the functionality that they want.

The implications of fixing the scope early in a project can prove to be quite dire. People are not very good at defining what they want up front, so no matter how good your business analysts are, it's incredibly unlikely that you'll write an accurate, detailed requirements specification at the beginning of the project. Even if you could get the requirements right, they're going to change anyway based on changes in the marketplace, decisions by senior management, regulatory changes, and so on. The earlier your requirements are "firmed up," the greater the risk of building something that your stakeholders don't actually want. My April 2007 newsletter entitled The Dire Consequences of Fixed-Price IT Projects (6) explored these problems in greater detail.

Variable Resources

Sometimes the resources, particularly funding, are allowed to vary. Although this sounds like a recipe for disaster, when it's done right you can dramatically reduce your financial risk on a project. In Figure 2 you see that just enough work items are removed from the top of the stack for each iteration, as determined by the length of the iteration and the resources available to the team. This approach enables stakeholders to govern agile projects far more effectively than traditional projects because they can base the funding of an iteration on the previous track record of the team based on the concrete evidence provided by working software. This enables stakeholders to treat their IT investment like an investment—they can increase funding to effective teams and reduce funding to ineffective teams, enabling them to spend their money as wisely as possible.

Many agile teams are asked to give a fixed estimate at the beginning of the project, often motivated by the stakeholders' desire to limit their financial risk. Many people are convinced that you can't apply agile in this sort of circumstance, but the reality is that you can easily make this work if you choose to. The secret is to do just enough high-level requirements modeling at the beginning of your project so that you can gather sufficient information to create a reasonable estimate. This is actually quite a common practice within the agile community, as last month's column showed which overviewed the results of DDJ's 2007 Agile adoption survey. You can do some up-front modeling without having to write a detailed requirements specification, see www.agilemodeling.com/essays/amdd.htm for details. Besides, where else would the initial requirements stack of Figure 2 come from except from some initial requirements modeling?

There are several estimating best practices that you want to adopt to help you to manage your resources effectively. First, because the longer away something is the harder it is to estimate, you want to provide a range estimate to reflect the actual temporal risk. For example, if I'm estimating the cost of a six-month project, at the very start I may have a range of +/-20 percent, yet if there was only one month left my estimate range may be +/-3 percent. Second, update estimates as the project progresses based the improved information that you've gained. Third, recognize that it's easier to accurately estimate small things rather than large things. Fourth, the estimate should be done by the people doing the work because they're more motivated to get it right. Fifth, if possible, ensure that someone who has done the work before is involved in creating the estimate to take advantage of his or her experience. Sixth, involve as many people as possible to ensure that you've covered all of the potential issues. An effective way to do so is Mike Cohn's Planning Poker technique described in his book Agile Estimating and Planning (Pearson Education, 2006) that gets the entire team involved.

Too many people think that funding is a black and white issue, either you take a time and materials (T&M) approach or you do fixed price/estimate, yet there are shades of grey in between. For example, if stakeholders balk at what is effectively a T&M approach to funding, one option is to spread the risk by having a low hourly rate that covers your variable IT costs and delivery bonuses for making key milestones (such as having new working software each iteration). The problem with a fixed-price approach is that it motivates you to take a fixed-scope approach, thereby running the risk of building something to spec instead of building something that stakeholders actually need. It also motivates the development team to pad their estimate, increasing the overall average cost to the stakeholders of their IT projects. Worse yet, it motivates you to put a traditional change management process in place to prevent requirements changes, increasing your IT management overhead. In short, fixing the price/estimate at the beginning of a software development increases your financial risk in practice instead of decreasing it as intended.

Variable Schedule

When your schedule is allowed to vary, you are better able to focus on time-to-market considerations and other competitive considerations. A common strategy is to release a system incrementally instead of all at once. The initial release can be the hardest to predict because you know the least about your stakeholders actual needs at the beginning, you haven't built up a good working relationship with them, and you haven't established a team rhythm yet. The first release must implement sufficient and cohesive value for your stakeholders yet still be timely. Subsequent releases must also have the same characteristics, and over time you'll find that you'll be able to stabilize the release dates and thereby bring greater predictability to your schedule.

It's important to understand that even when your schedule is allowed to vary, you still need to plan for certain types of inflexible events that just aren't flexible. Examples include your operations department having a fixed release schedule that you must conform to, needing to schedule in advance technical writers to produce external documentation or translators for your internationalization efforts, a team member is getting married and will be going on her honeymoon, or a training course that several team members want to attend is scheduled at a specific time. The implication is that your schedule may be partially variable and partially fixed.

Release dates are often fixed due to regulatory concerns or for competitive reasons in the marketplace. These dates may not be as fixed as you think—regulations often change and market-driven dates are often based on perceptions that can change. Furthermore, the fact that a large percentage of IT projects are delivered late clearly implies that many software development project schedules vary. Instead of having circumstances late in the project force you to make unpalatable scheduling decisions anyway, perhaps it's better to simply choose to vary your schedule from the start.

Egads, I've Been Constrained!

So, what do you do when one or more of the three management factors of the iron triangle are constrained? Table 1 summarizes the strategies available to you for each combination of constraints that could be inflicted upon your project team.

As you've seen, you can still take an agile approach to development even when constraints are imposed upon the team. The secret is to understand the implications of the iron triangle and then act accordingly. Project management is enhanced because if you identify which factors can vary, you can still work as effectively as your constraints let you—all is often not lost. Portfolio management, where the goal is to identify and then execute IT projects in a manner that reflects the goals and direction of your organization, is also enhanced because you can start projects off on the right foot when stakeholders understand the implications of constraining the three project factors.

Constraints	Strategy
None	Count yourself lucky.
Fixed Resources	Address work items in priority order, allowing them to vary as dictated by your stakeholders. Release the system incrementally, the initial release being at the point where you have implemented sufficient cohesive value for your stakeholders. You may need to cut the project short if you discover that your burn rate is higher than expected.
Fixed Scope	Ensure that very good modelers are involved with up-front requirements definition because you rely on getting the requirements right at the very start. Note that the longer the project goes the greater the chance that the requirements will change, regardless of how "fixed" you think they are. Ensure that money is being spent wisely by delivering working software regularly.
Fixed Delivery Date	Implement the work items in priority order, allowing them to vary over time. Validate expenditures through the regular delivery of working software.
Fixed Resources and Scope	Pad the budget as much as possible to give you some flexibility, then set the delivery date to reflect the work to be done. As the project progresses, update the delivery date as needed to reflect the team's actual velocity.
Fixed Resources and Delivery Date	Identify an appropriate iteration length, i.e. two weeks, determine the number of iterations the delivery date allows, then divide the budget by this number to determine your average budget per iteration. Implement the work items in priority order, allowing them to vary as appropriate, thereby ensuring that stakeholders receive the greatest ROI.
Fixed Scope and Delivery Date	Do a really good job of modeling the requirements at the beginning of the project and estimate them to the best of your ability. Determine the number of iterations that you intend to work to, then assign work items in priority to the iterations. Initially, pad your schedule with a few empty iterations at the end so that work can slip if required.
Fixed Resources, Scope, and Delivery Date	Either lift one or more constraints or cancel the project because your project is pretty much doomed to failure. If you deliver at all, your system is likely to be late, over budget, and of low quality due to "shortcuts" took during development.

Table 1: Strategies.

Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted at www.ambysoft.com/scottAmbler.html.