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