Progressive Estimation and Tollgates

Kelly Waters from All About Agile picked up on my post yesterday about project velocity. Kelly made a great point about how we can use a toll-gate approach for estimation and project funding.

Here is Kelly’s comment:

In some methodologies – for example RUP – there is an initial stage of the project (“inception”) to do some high level scoping before seeking approval for full funding. It’s also quite common in waterfall projects to complete the reuirements analysis before going on to request full funding. In these cases, only the initial stages need to be funded and then the team knows more by the time they ask for the rest of the money.

This is an essential concept for large scale agile development, and here is why…. coherent software architecture, UX and UI design, and requirements are not going to just emerge from multiple small teams working independently on a significant, enterprise level initiative. Without some degree of lightweight, up-front planning (to integrate the activities of several teams working together) it is unlikely that we will converge on a well integrated product.

Schwaber talks about this when he talks about iteration 0. Leffingwell talks about this when he refers to an architectural runway. In my opinion, these guys are dancing around the idea of Inception and Elaboration. This almost has to be done because RUP is such an unpopular topic in the agile community… otherwise people tune out. Ambler is more direct explaining these concepts when he talks about the Agile Unified Process.

By introducing these higher order agile concepts, we can help teams learn to effectively structure large scale agile implementations, and furthermore, help teams understand what decisions need to made and when… from both a busines and a technical perspective. A year or so ago I did a post called the Agile Heart of the Unified Process (back when this blog had no subscribers whatsoever).

Rather than reinvent the wheel, I am going to grab some text from that article and update with some commentary to tie back to Kelly’s original comments… the text in bold was added today.

Inception

The goal of Inception is to minimize business risk. This means that you have to understand the vision for what you are trying to create, have a high level understanding of the requirements, and have defined the characteristics of the systems architecture you intend to build.

Begin Inception with a single Scrum team. The team should at a minimum have a ScrumMaster, a Product Owner, an Analyst, a Quality expert, and an Architect. The product backlog will include the features necessary to create the Vision, Use Case Inventory, and Candidate Architecture. It may be necessary to include features in the Inception backlog that prove key aspects of the business vision.

Inception is the least code focused of all the RUP phases. This is due to the requirement to have an idea of where you are going before you begin the project. Since Inception is the least focused on creating working software, and without working software the team is not mitigating risk, it is in the team’s best interest to make decisions quickly and get on with the business of delivering working software.

At the end of Inception, there is a business decision that must be made. Do we have a strong enough product vision, and a strong enough architectural vision, to fund the next increment of product development. This is a good time to reestimate the backlog and decide if the value proposition of the project still holds.

Elaboration

The goal of Elaboration is to minimize technical risk. This involves choosing the smallest subset of features that will prove out the significant technical assumptions made during Inception. At the end of Elaboration, the system should be fully functional with the subset of features you have chosen to build. The system should be fully tested and the team should be confident that the architecture is stable.

During Elaboration, you may still have a single Scrum team. It is likely that you will add several more senior level technical folks to help begin building the system. The product backlog includes the features necessary to prove the application architecture and to deliver any non-functional components required to build out the system. It is important that the Elaboration backlog contain features the team will need to collaborate at scale. Source control, build environments, automated testing infrastructure, instant messaging, and collaboration software should not be overlooked when preparing to scale an Agile team.

At the end of Elaboration, we have another business decision. Have we built enough of the application to validate our technical assumptions. Can we move forward with the project, scale into multiple agile teams, and move forward with confidence we have a workable and proven solution? This is the next point where you need to reestimate the backlog. After proving the solution, updating the backlog, reestimating based in what we have learned, do we have a business case for moving forward?

Construction

The goal of Construction is to mitigate logistical risk. This is where the bulk of the software is created and where the Agile team really begins to scale. The core team that helped build the foundation of the system during Elaboration is broken up to seed the newly created Scrums. Each team is organized around a major component of the architecture or a significant feature set within the overall scope. Each team is a complete cross-functional entity that is responsible for delivering its part of the system. These teams are coordinated by a master team that includes a more senior ScrumMaster, Architect, its own technical staff, and the Technical Leads and/or ScrumMasters from the component teams.

At this stage, the backlog is completely feature driven, progress is extremely measureable, and the teams are focused on delivering the bulk of the business value to the customer. As is true during every phase, the code delivered at the end of each Construction iteration is fully tested and integrated with the rest of the system.

Construction is the most like the prototypical agile project as described in most of the common literature. We have several independent feature teams working in concert. Each is tracking velocity and burndown and making product adjustments as necessary to converge into a solution that delivers the most business value possible. The business is involved actively assessing progress iteration over iteration deciding when enough of the product has been built to take the solution to market.

Transition

This phase deals with training and hand-off to the customer, final user testing, and resolving any issues that were not caught earlier in the process.

During this phase, the team should be able to scale back down to a single cross-functional team or two. The backlog is related to the remaining documentation, training, and defect resolution features remaining to get the product in the hands of the customers.

I think of transition like many talk about hardening iterations. This is the place where we clean up anything leftover. If we need any final user acceptance, doc work… whatever, this is where it goes. We are asking our customers if they are ready to accept the project deliverables.