Greater Stakeholder Control
With the approach in Figure 1, stakeholders can change their requirements at any time, they can add new ones, and they can reprioritize existing ones, putting them in complete control of the scope. This works when the development team writes high-quality code that is loosely coupled and highly cohesive, when they refactor when required to keep their design of high quality, and when they have a regression test suite, which they run regularly. It's very easy to add new functionality to an existing code base in this sort of situation, particularly when the team invested a bit of time at the beginning of the project envisioning the architecture with a bit of initial Agile modeling.
Because Agile teams ask stakeholders each iteration how much they want to invest, our stakeholders are effectively in control of the budget—and rightfully so seeing as it's their money that is being spent. When stakeholders have insight into the actual status of a project team, and when they can change the funds that each team receives each iteration, they're in a position to actually govern IT projects. Figure 2 shows the current status of a collection of software development projects. The height of each stack indicates the relative amount of work the individual teams have left, the color of the stack indicates the current status, and the number of the top of the stack indicates the expected ROI of the system under development. With this sort of information, stakeholders can make intelligent governance decisions. For example, the projects with red status clearly need to be redirected, and I'd even consider canceling the low ROI one at this point. The yellow status projects also could use some help. From a portfolio-management point of view, I'd consider increasing the funding to the high-ROI green teams because I want to put my money into successful teams that provide the greatest value. In other words, with an Agile approach, stakeholders can start treating their IT investment as an investment. Following a traditional approach, it often seems that money spent on IT is more of a gamble than an investment, and I think that it's because of the lack of visibility and control that traditional teams provide to stakeholders.
Stakeholders are put in control of the schedule as a side effect of producing working software each iteration: We can be six months into a project and the stakeholders can tell us that we've delivered sufficient functionality to justify delivery into production. In combination with working in priority order, they can drive Agile development teams to deliver a system to the marketplace at the earliest opportunity.
