DAD’s Lean life cycle promotes lean principles such as minimizing work in process, maximizing flow, a continuous stream of work (instead of fixed iterations), and reducing bottlenecks. New work is pulled from the work item pool when the team has capacity. While Scrum prescribes the use of a set of “ceremonies”, such as the daily co-ordination meeting (Scrum), iteration (sprint) planning sessions, retrospectives to be done on certain cadences within the iterations (sprints), Lean does not prescribe this overhead and instead suggests that it be done if and when necessary. This requires a degree of discipline and self-awareness not usually found on teams new to agile, hence this life cycle is considered advanced. While the concepts of Lean and the Kanban system it uses are very easy to learn, it can be difficult to master the principles of lean flow and maximizing the throughput of the system.
Figure 1. DAD’s Lean Life Cycle (click to expand).
Features of this Life Cycle
There are several interesting features to this life cycle:
- It supports a continuous flow of development. In this life cycle the solution is deployed as often, and whenever, it makes sense to do so. Work is pulled into the team when there is capacity to do it, not on the regular heartbeat of an iteration.
- Practices are on their own cadences. With iterations/sprints many practices (detailed planning, retrospectives, demos, detailed modeling, and so on) are effectively put on the same cadence, that of the iteration. With a lean approach the observation is that you should do something when it makes sense to do it, not when the calendar indicates that you’re scheduled to do it.
- It has a work item pool. All work items are not created equal. Although you may choose to prioritize some work in the “standard” manner, either a value-driven approach as Scrum suggests or a risk-value driven approach as both DA and RUP suggests, but other work may fit this strategy. Some work, particularly that resulting from legislation, is date driven. Some work must be expedited, such as fixing a severity one production problem. So, a work item pool and not a prioritized stack makes a bit more sense when you recognize these realities.
When to Apply This Life Cycle
It is suitable in these situations:
- Work can be broken down into very small work items of roughly the same size
- Work is difficult to predict in advance. For example, teams that are focused on fixing defects or handling support issues are good candidates for this life cycle
- The team favors the lean approach of minimizing batch size (which helps to reduce work in progress) and any planning in advance of doing the work
- The team is typically working on a project