There are many sources of change: competitive entries, customer demand, evolving missions, and so on. However, as Figure 1 illustrates, there are two main situations that require a need for agility:
- Incomplete knowledge and learning. Many organizations have incomplete knowledge about what they need to accomplish.
- Variation and irregular flow. Many business processes deal with a stream of dissimilar items and irregular arrival rates.
Figure 1 — The two dimensions of the Agile management landscape.
As discussed below, dealing with either dimension in a timely, cost-efficient manner requires agility. However, the Agile practices applied vary along the dimensions. Consequently, an Agile manager must be aware of his or her mix of work and apply the right methods.
The Three Levels of Uncertainty
Understanding how to become Agile starts with understanding the kind of work your organization performs. The taxonomy introduced here cuts across domains. Indeed, each is applicable to software but can be extended into other domains. The types differ in the completeness of information and, inversely, the uncertainty — the ability to make tight estimates (see Figure 2). The three classes are:
- Sustaining engineering. This effort involves maintenance and small improvements. For software, this includes bug fixes. For hardware, this class includes small design changes to address manufacturability and warrantee experience. The work comes in as a stream of defect reports or change requests. They are implemented and released as parts of point or point releases and on a periodic basis. For example, content could be delivered as Release 2.1 or Release 2.1.3. Generally, these change requests are well specified in detail, and the products to which they are applied are well understood by the team. For that reason, the ability to predict the level of effort and time required is high. Commonly, mature development organizations spend 60%-80% of their resources on these efforts.
- New features. This effort is to significantly modify or add new features to a product or system. In IT, rehosting or rearchitecting the system would fall into this class. This results in major releases going from Version 2.X to Version 3.0. In this case, there is some uncertainty about both the requirements and how the technical solution will come together and perform. For that reason, the team is not capable of making firm estimates or commitments at the onset of the program.
- New systems. On occasion, a development organization builds the 1.0 version of a system or product. From the organization’s perspective, this is a very innovative system or product. In this case, there is a lot of uncertainty around the requirements and the solution. The team must learn as it goes, and its ability to predict the level of effort and duration of the work is very limited.
Figure 2 — Three different classes of uncertainties.
These three types of categories apply to any sort of development. For example, in construction, building a bunch of tract homes falls under Type 1. These often can be built on a tight, predictable schedule. Building a custom home with some back and forth between the developer and the buyer is a good example of Type 2. These often slip schedule and exceed the initial budget. Building an innovative, highly efficient home with new materials and unique technologies for the first time would be a Type 3 project. Another example of a Type 3 effort might be a large civil engineering project like the Boston Big Dig or the first commercial aircraft built from composite materials like the Boeing 787.
We can argue fairly that the historical “failure” of software projects to deliver the original planned content on time and on budget is not due to immaturity of the field, but rather to the fact that software takes on more innovation than many other fields. A very non-Agile management approach is to try to apply the same management approach to all three types of projects.
[For more from the author on this topic, see "Agile Management, Part I: What and Why."]
