Processes as Cycles

Most people have described the development process as a linear process over time. These descriptions were never wholly accurate and are generally too complicated to read. Some people simply draw a big circle or perhaps circles connected to each other in a bigger circle. These either look wishy-washy or are again too complicated to use. The generic circle doesn't map to a calendar in any way that helps a project manager. Around 2001, Don Wells solved the problem, in part, by illustrating XP using nested cycles at different time spans for different practices.

Figure 4.1-1 shows an incremental development process using nested cycles. This nested-cycle idea fits most projects and fits agile projects particularly well. The version in Figure 4.1-1 is intended to show both the linear aspects of the project (read the activities clockwise around each ring) and the cyclical aspects (go around the inner rings multiple times for each outer ring). A linear or time-based unfolding of Figure 4.1-1 is shown in Figure 4.1-2.

Figure 4.1-1. Nested-cycle model of an agile process.

Figure 4.1-2. The cycles unrolled.

Neither the circular nor the linear version is completely correct because there are interactions between the inner and outer cycles. For example, both iterations and deliveries contain planning, reflection, and celebration. Of course, one typically does not hold two planning sessions at the start of the first iteration in a delivery cycle, or two reflections and two celebrations at the end of the last iteration in a delivery cycle. One merges and adjusts them accordingly. Trying to show these interactions on either form of diagram is too complicated. In practice, people have no trouble understanding that the planning at the start of a delivery cycle will include both delivery and iteration time horizons, and the same goes for the endof-cycle activities. This is where practice is for once simpler than theory.

Read Figure 4.1-1 as follows:

• A project starts with a chartering activity, which could take from an hour to several weeks. Within the project is some number of deliveries, after which the project ends with a wrap-up activity of some sort.

• The delivery cycle starts with an update to the project plan and contains some number of iterations. It ends with the delivery of the system to some number of users. Agile teams tend to reflect after each delivery to improve their process and the product.

• Each iteration starts with a planning session. The iteration ends with a reflection workshop and, in the best shops, a celebration event of some sort. For the last iteration in a delivery cycle, it is probably the case that the iteration reflection session is held after the delivery as part of the delivery reflection workshop.

• Within an iteration, there are two cycles that operate at their own independent rates. There are regular weekly activities, such as the Monday morning staff meeting. There are also regular daily activities, such as the daily stand-up meeting and the daily full integration with testing.

• Within and overlapping the daily and weekly cycles are integration cycles and design episodes.^[1] Each design episode consists of doing some design, programming the design (and the unit and acceptance tests to match), checking in the new code and tests, and running the tests. The programmers may go through several design episodes before checking in and integrating their code. There are usually multiple design episodes within a day, which is why I show the design episode as the inner cycle. Some teams integrate multiple times a day; other teams integrate every few days.

  ^[1] Thanks to Ward Cunningham for this term. See http://c2.com/ppr/episodes.html.

What I find particularly useful about Figure 4.1-1 is that it allows us to capture periodic "operations" activities such as the weekly status meeting and the daily integration in the same format as "progress" activities such as chartering the project and designing new features. Each cycle is quite simple in itself, which helps in the presentation of an otherwise complex process.

As they go about during the day, people have no trouble knowing what cycle each activity belongs to. While attending the weekly status meeting or the daily stand-up meeting, they know they are in an operations activity. When they walk out, they know they are entering a design episode. It is not confusing to them that they switch between multiple cycles in the same day.

Presenting the process as nested cycles has one more benefitmost people misinterpret a linear drawing of a process as being "waterfall," even when it is specifically not. This misinterpretation is because the linear process drawings really describe a dependency graph between work products! The dependency graph should be read right-to-left for its dependencies, not left-to-right for a process.

The "process" diagram shown in so many presentations shows Gather requirements pointing to Do design (and Write code), which points to Run tests, and so on, leading to Deliver system. Although to the unwary it looks like a process diagram, what it really is saying is that the people can't deliver the system until the tests are run. They can't run the tests until the code is written. They can't write the code until they learn what the requirements are, and so on. Although these are all true statements, they are not really informative, and they particularly don't say the really interesting things that need to be said:

• How many requirements at what level of completion are needed before design can usefully get started? (The answers are usually "relatively few" and "relatively low," by the way.)

• How does feedback from the design team affect the amount of detail put into the written requirements?

• How much of the system must be designed and programmed before useful integration and testing can be done? ("Relatively little")

• How much of the system at what level of correctness is needed before being useful to the users or suitable for user review? ("Relatively little" and "relatively low")

There are two important points to take from this discussion:

• Consider processes as nested cycles. This simplifies their description, allowing capture of both progress and operations activities, and it allows incremental/iterative development to be described much more accurately.

• Don't confuse dependency diagrams with process diagrams.