As you know the Disciplined Agile (DA) toolkit supports several delivery lifecycles – Agile, Lean, Continuous Delivery: Agile, Continuous Delivery: Lean, Exploratory, and Program. We do this because solution delivery teams face different situations, so one lifecycle will not fit all. This begs the question of when would a team adopt each lifecycle? That is the focus of this blog.
This blog explores the following topics:
- What lifecycles does DAD support?
- What criteria should you consider when choosing a lifecycle?
- Who chooses?
What Lifecycles Does DAD Support?
The delivery lifecycles we will explore are:
- Agile. DAD’s Agile lifecycle which extends Scrum’s construction lifecycle. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re taking an agile project approach.
- Advanced. The Lean lifecycle encompasses lean strategies 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.
- Continuous Delivery: Agile. The Continuous Delivery: Agile lifecycle is a natural progression from the Agile lifecycle. Teams typically evolve to this lifecycle from the Agile/Basic lifecycle, often adopting iteration lengths of one-week or less. The key difference between this and the Agile lifecycle is that the continuous delivery lifecycle results in a release of new functionality at the end of each iteration rather than after a set of iterations.
- Continuous Delivery: Lean. DAD’s Continuous Delivery: Lean lifecycle is basically a leaner version of the Continuous Delivery: Agile lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.
- Exploratory/Lean Startup. DAD’s Exploratory lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.
- Program. DAD’s Program lifecycle describes how to coordinate a team of teams. It is very similar to the LeSS lifecycle although does not prescribe that the subteams/squads need to be following Scrum. It can also be thought of as a simplified version of the SAFe lifecycle.
- Waterfall/Serial. Although this is not supported by Disciplined Agile, we do recognize that some teams will still follow this more traditional way of working. For more thoughts on this subject, please see the blog posting When Does Traditional Software Development Make Sense?
What Criteria Should You Consider When Choosing a Lifecycle?
The following table compares the lifecycles, suggesting when you would choose to follow each one.
|Lifecycle||Team Type||Time to Market||Advantages||Disadvantages||When to Use|
||Teams new to agile|
||Disciplined teams with quickly evolving requirements|
|Continuous Delivery: Agile||Product (long lived)||Fast||
|Continuous Delivery: Lean||Product (long lived)||Very Fast||
||Long-running, disciplined teams|
||Identification of a new product or service offering for the marketplace where there is a high risk of misunderstanding the needs of potential end users|
|Program (Team of Teams)||Project||Medium||
||When you have a very large agile project team that is organized into a “team of teams”|
||Low-risk situations where the requirements are stable and the problem has a well-known solution. For example, upgrading the workstations of a large number of users or migrating an existing system to a new platform|
Who Should Choose the Lifecycle?
They will often do this with the guidance of an experienced Disciplined Agile coach, particularly when they are new to DA. It’s tempting to have your portfolio management team to make this choice, and they may often make a (hopefully solid) suggestion when the first initiated an endeavour, but in the end it needs to be the choice of the team. As you see in the table above there are common considerations for when to use each lifecycle, but the primary considerations are always the skill and preferences of the team itself.