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.
