Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Software Development
March 2003

It’s your first day on a new project; you’ve just left the kick-off meeting and the energy is palpable: A senior vice president explained the project’s importance, management promised complete support, and key stakeholders pledged their loyalty to your team, which is staffed with experts. Why, in the face of all this bonhomie, do you have that sinking feeling? Because you know that the project will fail—and there’s nothing you can do about it.

The Iron Triangle
Failure is inescapable because the project is constrained by the iron triangle: The powers that be made it clear that none of the three critical factors—schedule, budget and scope—will be allowed to vary. When this triumvirate remains rigid, without adjusting to the inevitable changes that crop up in every development project, the triangle becomes unbalanced and will break. If you try to define the exact schedule, the exact cost and the exact scope to be delivered, you virtually guarantee failure because you have no room to maneuver. The only course left to you is to let quality suffer—rarely an option. To be sure, if you set the factors to a very small scope, a very large budget and long schedule, success might be possible, but most organizations desire the exact opposite, without providing sufficient funds to develop all of the requirements within the time allotted. Something’s gotta give.

How Long Will It Take?
The Project Management Institute (www.pmi.org) defines time as the first corner of the iron triangle. Unrealistically tight scheduling is a familiar problem for most developers—aggressive schedules are fine; unattainable ones are not. Equally troublesome is setting a multiyear schedule without interim deliverables, guaranteeing that no practical progress will be made for the first year or two because of the lack of motivating milestones.

Agile project teams organize their schedules into short iterations, typically between one and four weeks, during which they implement a subset of the requirements. The primary product is working software that fulfills the most important requirements to date. With this approach, you can set the schedule, but leave some leeway in terms of the product delivered at deadline—or you can set the scope, but allow some flexibility in the time frame. By stretching one corner of the triangle, you dramatically increase your chance of delivering a working system, at the negligible cost of additional management uncertainty.

What Will It Cost?
Budget is the triangle’s second corner. Here, an inflexible attitude will almost always doom a project. Funds are often mismanaged, assigned early on to rigid categories, resulting in artificial under- and over-funding on the same project. How often have you seen teams secretly take money from the training “bucket” to pay for development tools that they desperately need?

Are you ready for a shock? I believe that annual budgets are the bane of effective management. First, they encourage people to focus on financial issues only at budgeting time. Second, they promote a “bucket” mentality: “This year, we have $50,000 to spend on training, $10,000 for books and $20,000 for tools” instead of “We have $80,000 to spend wisely.” Third, they create a “stack of money” mentality. Although thinking that you have $80,000 to spend wisely is a step in the right direction, better yet is the attitude that you should invest whatever you need to get the job done. No, you can’t expect an unlimited budget, but you will spend what you have wisely and adjust your strategy as required.

How can you manage project resources in an agile manner? Think of money as flowing from a tap instead of from a collection of prefilled buckets. The traditional approach is to define a project as a six-month, half-million-dollar effort. This is a fundamental mistake. Instead, give the team $100,000 for the first month. At the end of that time, evaluate their progress and base next month’s resources on their track record. If they did a good job, let them have $125,000; if they did a poor job, cut their budget to $75,000 and put them on notice of cancellation. Scrum is one proven method (www.controlchaos.com) that espouses this philosophy.

The advantage? By directing your resources to the teams that are cost-effective, you get the most value for your investment. The disadvantage? You don’t know what you’re going to spend—but that’s the reality of all budgets. The Canadian government recently discovered that its national gun registry project went 500 times over budget: Originally estimated at $2 million, the agency spent $1 billion before it got caught. The fundamental trade-off? To ensure that your money is spent wisely, you don’t exactly know what you’ll get or exactly when you’ll get it.

What Will I Get?
Scope forms the triangle’s third corner. Traditional project teams mistakenly try to define most of the requirements early on—the classic Big Requirements Up Front (BRUF) tactic. BRUF adherents must understand what needs to be built, so they can accurately plan and develop a robust system design. This approach doesn’t reflect the fact that requirements change as knowledge and environments evolve. Worse yet, when people try to get everything they want into a single release, requirements bloat beyond recognition. At best, this approach results in building too much of the wrong thing, while at worst, nothing gets built at all, because you’re too busy trying to get the requirements right.

Agile developers invest some time—perhaps a few hours or days—investigating the system’s initial, high-level requirements. This gives them a handle on the scope and enables them to start assigning functionality to iterations based on priority. Agile developers implement the highest-priority requirements in each iteration, ensuring that they deliver the greatest value to their stakeholders at all times. They also deliver working software in each iteration, thereby providing tangible results from the project’s inception. New requirements are prioritized and put onto the stack for future iterations, enabling a simple yet effective change-management process. The primary problem? It’s difficult to define exactly what you’ll have after six months of effort—but you do know that you’ll have the most important functionality built with the resources available to you at the time.

Will It Be Good Enough?
Quality is at the center of the iron triangle—but that center will implode when you refuse to manage schedule, cost and scope properly. Nobody is willing to settle for a low-quality product, though that much-desired element is in the eye of the beholder: To developers, a high-quality system is easy to maintain and evolve; to users, perhaps it’s a system that’s simple to use.

Reviews, which enable other sets of “qualified eyes” to examine artifacts for defects, are the traditional way to guarantee quality. But is this the best approach? No. Instead of looking for defects after the fact, wouldn’t it be better to create an error-free product to begin with? From the agile viewpoint, the desire to hold an inspection is an indication that you’ve failed to be effective elsewhere. For example, if people are qualified to validate that the system meets the corporate architecture standards, why didn’t they work on the architecture at the outset?

On agile projects, quality comes through collaboration. Coding standards and modeling guidelines help, as does test-first development and active stakeholder participation. Extreme Programming’s practice of collective ownership is one way to promote high quality; when many eyes are on the watch, mistakes are more likely to be found and fixed. Furthermore, the use of generalizing specialists (see "Isn’t That Special?", Jan. 2003) ensures that developers have a sufficiently wide range of skills to understand every aspect of the software they’re building. By promoting effective collaboration, you ensure that the “qualified eyes” are present from the start to ensure a high-quality product.

It’s a Matter of Trade-Offs
The most effective managers realize that, to ensure project success, the iron triangle has to give, accommodating change as the need arises. At the XP/Agile Universe conference in 2002, the Software Engineering Institute’s Watts Humphrey, father of the CMM, made a statement that goes to the heart of the matter: “What people really want is a high-quality system that implements everything they want, at no cost, right now. Everything else is a trade-off.” By maintaining the elasticity of these three critical factors, making adjustments as the project evolves, you can successfully build and deliver high-quality working systems that meet your users’ needs.

Scott Ambler is a senior consultant with Ronin International Inc. His latest book is The Elements of UML Style (Cambridge University Press, 2002).

RELATED ARTICLES Dr. Dobb's Agile Update 05/09 Measuring the Results of Your Agile Adoption		TOP 5 ARTICLES No Top Articles.