Applying Iterative Development Methodologies to Large Software Projects

I wrote previously about my effort to develop a project schedule for a large software effort and alluded to my use of Time Boxing. In this post I’ll explain my interpretation of Time Boxing and describe some questions I still have with respect to applying the technique to large projects.

When I was given this scheduling task I spent time researching software project management approaches and came across a good discussion of Time Boxing versus Scope Boxing in Bittner and Spence’s Managing Iterative Software Development Projects. They strongly recommend the use of Time Boxing and I subsequently found the same opinion in other references.

In their description of iterative development, a software project evolves through the phases defined in the Rational Unified Process (RUP). Those phases are Inception, Elaboration, Construction and Transition. Explanations of RUP are easy to find with a Google search so I won’t bother describing it here. With Time Boxing, the phases are divided into iterations, which are time periods of fixed duration. Requirements are then prioritized and allocated to iterations. I found no reference that offered an opinion as to whether iterations should differ from one another in length but most of the literature recommends an iteration length between 4 and 8 weeks. So we can assume that one tailors the length of an iteration during the project planning phase to accommodate logical milestones related to some set of requirements. With Scope Boxing, a set of requirements is worked until completion. The time is extended until the planned scope is achieved.

One of the motivations for Time Boxing can be found in Bittner and Spence’s assertion that (Fixed Scope) + (Fixed Duration) = Failure. This can seem a little counterintuitive at first. I interpret it as follows:

• Early software estimates are rarely accurate, especially for large, unique projects where historical estimation data is usually not available.
• Combine that with Brooks’ Law: Adding more manpower to a late software project makes it later.
• Therefore project teams must be able to make tradeoffs in scope to complete the project within a fixed duration

Time Boxing is a project control technique for maximizing the effectiveness of available time to achieve the most important scope. The key to Time Boxing is the prioritization of requirements so that the most important scope is worked first. Any scope that was not completed in an iteration is shifted to the next iteration but the iteration’s end date is never extended. At the end of the project, any unfinished scope goes undelivered. The following figure illustrates this concept (click to enlarge).

Requirements priorities are derived by determining the most essential system features and assessing both technical and business risks. The fixed time increment focuses the team on delivering essential capability first, before nice-to-have features, emphasizing depth before breadth. If delivery deadlines are immutable but scope exceeds available time, we end up with the most essential capabilities fully implemented because of the emphasis on priorities. If we have to sacrifice scope to meet a deadline, we leave the lowest-priority requirements on the table.

Here is my summary of Time Boxing:

• Time Boxing is a method for controlling a software project through frequent measurement by forcing a progress assessment at each ending boundary. If planned scope isn’t achieved, the cause can be identified and corrected. Fixed time increments cause a beneficial sense of schedule urgency that can be absent with Scope Boxing (e.g. Parkinson’s Law: Work expands to fill the time available).
• Time boxing is not an abandonment of customer obligations. One can still set scope milestones for customer deliveries but Time Boxing is a method for maximizing the use of available time, regardless of whether that time is sufficient to achieve the planned scope.

Bittner and Spence discuss the concept of “evolutions,” where a system is delivered through multiple releases. There may be many reasons for this – time to market, bug fixes, demonstrating progress to secure future funding, etc. The figure below (click to enlarge) illustrates the combination of iterative development along with evolutionary releases.

Each evolution is treated as a mini project and progresses through the RUP phases (inception, elaboration, construction, transition). When one evolution is in the transition phase the next evolution is beginning the inception or elaboration phase, which is why the evolutions overlap in time.

This is where I begin to have some trouble applying the guidance provided in the Bittner and Spence book. They write about managing projects with this methodology as if they could pop their heads over the wall of their cubical and lay their eyes on every systems and software engineer working on the project. They write about planning and managing a project divided into evolutions, which is further divided into RUP phases and finally divided into iterations. But how does that apply to the System of Systems develop we often face in the Defense community, where we are integrating multiple subsystems into one enormous, distributed “enterprise” system? For example, consider the figure below (click to enlarge).

In this situation we find ourselves with multiple subprojects, each combining a collection of software applications into a logical system to provide some overall capability. The problem is that each of these subprojects could be in completely different states of maturity, where subproject #1 requires considerable prototyping just to understand the requirements and subproject #2 has significant technical risks that must be burned down through architecture trade studies and subproject #3 is based on very mature technologies and simply requires some tailoring for our specific system. So how do we apply the RUP phases and iterations to the overall project? My answer is… we don’t. We apply the phases and design the content of the iterations for each subproject and our milestones for the overall project are just synchronization milestones. Each overall project milestone is an aggregation of subproject milestones (see the figure). So milestone M1 may include a prototyping milestone for subproject #1, an architecture analysis milestone for subproject #2 and a software development milestone for subproject #3.

I do believe the intent of iterative development is still satisfied with this approach, which is to provide visibility into our progress by measuring often and to then take corrective action if we are not meeting objectives.

I’m also concerned about the description of the 4-8 week iterations as producing some executable piece of software. I understand that we’re moving beyond the Waterfall Model, where we spend some long period of time focusing only on requirements analysis, then on design, etc, but on large-scale software development projects there are times when it seems that 8 weeks is too short a period to close on anything substantial, particularly in the Defense community, where simply understanding requirements can take months of working group meetings and coordinating across large, distributed project teams is a reality of life.

I’m thinking hard about how to apply iterative development concepts to my project and I’d certainly like to hear about other’s experiences with these techniques – particularly in the Defense community.