Schedule vs. Cost: The Tradeoff in Agile

To a large extent, agile is about making tradeoffs. Product owners learn they can trade scope for schedule: get more later or less sooner. Agile projects need to strike a balance between no upfront thinking and too much upfront thinking, a subject I’ve written about before.

I want to write now about a tradeoff that isn’t talked about a lot in agile circles. And this is the tradeoff between schedule and cost. We’ve all heard the old story that nine women can’t make a baby in one month. But on software projects, it is possible (to some extent) to deliver a project faster by adding more people.

For example, suppose a project would take one person one year to do. Two people might be able to do it in six-and-a-half months. That’s one more total person-month to account for the overhead of communicating, for misunderstandings between the two, and so on. Adding a third, fourth or fifth person to the project will likely bring the calendar date in, but probably at the expense of more total person-months on the project.

Adding person-months to a project will presumably make the project more expensive to deliver. There is, then, a tradeoff to be made between schedule and cost. And most of the time, schedule wins. Companies always want things at the lowest cost they can—but not at the expense of schedule.

In an influential 1988 article in Harvard Business Review, George Stalk, Jr., declared that time was the next source of competitive advantage. Shortening development cycles resulting in releasing new products faster is a competitive advantage—often a more important one than developing a new product at the lowest price.

This distinction is glossed over in many agile discussions. Just because a shorter schedule is more important most of the time, does not mean it is more important all of the time. This difference can lead to important but subtle differences in how an agile process may be applied.

For example, standard agile advice is that designers should work as closely as possible with programmers, testers and others on the team. User interface designs are ideally done in the same sprint in which the rest of the development work will occur. Occasionally, exceptions are made for particularly complex interfaces for which a designer may be allowed to work perhaps a sprint ahead of the others.

This is optimizing for schedule. Having the user interface designer work with the team will shorten the schedule. But this could come with the expense of some rework due to design inconsistencies discovered over a number of sprints. It could also come with additional costs due to the programmers sitting idle while waiting for the newest design.

In an agile process optimized for cost, however, the designer would not work as little ahead as possible. The designer would instead work as far ahead as possible while avoiding the opposite problems of designing hard-to-implement ideas and designing things that are no longer needed.

The designer in the latter case of our example should not strive to create a pixel-perfect design of every screen that will be part of the system. However, if cost is a more important consideration than schedule, it may very well be best for the designer to work a couple of sprints ahead.

I’d love to know what you think. What’s more important on your projects? Schedule or cost? (No fair saying both. You cannot optimize for two things.) And, to lower cost, do your designers sometimes work further ahead than an agile process might otherwise say they should?