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:
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:
There are two important points to take from this discussion:
|