Disciplined Agile (DA) teams will often evolve from one life cycle to another, as we show in Figure 1. This is because DA teams are always striving to Optimize Flow, to improve their way of working (WoW) as they learn through their experiences and through purposeful experimentation. As the result of evolving their WoW, they may gradually evolve away from the life cycle that they started with towards something that more closely resembles one of the other life cycles. The arrows in Figure 1 indicate the type of improvements that generally push your team over from one life cycle to another.
Figure 1. Evolving between life cycles (click to enlarge).
Figure 2 shows common evolution paths that we’ve seen teams go through. The times indicated in Figure 2 reflect our experiences when teams are supported by Disciplined Agile® (DA™) training and a Disciplined Agile® Senior Scrum Master (DASSM) or Disciplined Agile® Coach (DAC)—without this, expect longer times and most likely higher total costs, on average. For example, when helping a traditional team move to a more effective WoW, a common approach is to start with the Agile life cycle. This is a “sink or swim” approach that experience shows can be very effective, but it can prove difficult in cultures that resist change. A second path shown in this diagram is to start traditional teams with a Lean Kanban-based approach wherein the team starts with their existing WoW and evolves it over time via small changes into the Lean life cycle. While this is less disruptive, it can result in a much slower rate of improvement since the teams often continue to work in a silo fashion with kanban board columns depicting traditional specialties.
Figure 2. Common improvement paths for existing teams following a traditional life cycle.
What Figure 2 doesn’t show is where the Program or Exploratory life cycles fit in. First, in some ways it does apply to the Program life cycle. You can take an agile program approach (similar to what scaling frameworks such as LeSS do in practice), where the program releases large increments on a regular cadence (say quarterly). You can also take a lean program approach, where the subteams stream functionality into production and then at the program level this is toggled on when it makes sense to do so. Second, the focus of the diagram is on full-delivery life cycles, whereas the Exploratory life cycle isn’t a full-delivery life cycle in its own right. It is typically used to test out a hypothesis regarding a potential marketplace offering, and when the idea has been sufficiently fleshed out and it appears the product will succeed, then the team shifts into one of the delivery life cycles of Figure 1.
February 2022