Agile and the Iron Triangle
Topic: Agile management
The term "Iron Triangle" is generally understood in the context of politics, but in the software development profession it refers to a set of three factors that affect the successful outcome of a project. The three factors may be given different names by different authors, but most people would agree they comprise three of the four listed in this article in Software Development magazine: scope, schedule, budget, and quality.

If we assume cost is largely determined by schedule, then we can choose scope or feature set as one factor, quality as another, and schedule or time as the third. Although there are certainly other components to cost, because cost and time are so closely related, we can assume they vary in direct proportion. When none of these factors is allowed to change in the course of a project, the project is said to be overconstrained, and will probably fail.

There are those who think we can trick the Iron Triangle by short-circuiting formal procedures, or transcend it through methodology, or maybe just melt it by reducing the cost of everything to a trivial level so that it becomes cheap to overconstrain a project.

I don't see it that way. I see the Iron Triangle as a natural force in software development in much the same way as the "law of supply and demand" is a natural force in economics. You can't make a natural force disappear just by wishing it away, by asking your team to work a million hours of overtime, or by yelling and screaming until you're blue in the face. It is what it is. We have to deal with it somehow.

The way Agile projects deal with it is by defining one of the factors - time - as fixed. At agreed-upon points in the process, such as at Iteration Planning Meetings (IPMs), the Customer (or Product Owner, depending on one's preferred terminology) can make adjustments in the priority of stories to ensure the most important work will fit into the defined time frame. When the Customer increases the feature set (or scope), the quality automatically decreases. When the Customer increases the acceptable quality, features drop off the bottom of the list and the scope automatically decreases.

This is never a question of confrontation or argument between the development team and the Customer. It is always entirely in the hands of the Customer. The only thing the Customer cannot do is change a force of nature. In that sense, the Customer wields as much power as any human being can ever possess. When you look at it that way, Customers on Agile projects have considerably more power than they ever had with traditional software development methods. It is a sobering thought indeed.

This characteristic of Agile projects is advantageous in two important and common software development situations.

Corporate IT departments typically operate on a predetermined annual budget. They need a software development process that enables them to make accurate budget allocations to projects in advance. Historically, the challenge in this has been the fact that requirements can never be fully elaborated in advance. Agile methods serve corporate IT departments well, because by locking down time they also very nearly lock down cost. The close ties between time and cost enable them to allocate budget accurately despite the fact they cannot know the final shape of any given solution in advance.

The second situation is that of a software consultancy that engages in fixed-bid development projects. Because clients must agree to a fixed timeline for their projects while allowing for flexibility in the final selection of features and acceptable quality levels, the consultancy can accurately judge how much to charge clients for Agile software development. This is better for both the consultancy and the client because it enables them to manage their own operating costs without massive, unpleasant surprises.