Disciplined Agile Delivery (DAD), the solution delivery portion of the Disciplined Agile (DA) framework, supports several full delivery life cycles. It does this because solution delivery teams face different situations, so one life cycle will not fit all. This article explores the concept of what a full delivery life cycle means, overviews each of the life cycles supported by DA, overviews the waterfall/serial life cycle (which is not explicitly supported by DA), and how to choose and evolve between the life cycles.
Table of Contents
This article is organized into the following sections:
The 30,000 ft. View
One of the key aspects of Disciplined Agile Delivery (DAD) is that it promotes a full, beginning-to-end, solution delivery life cycle. Figure 1 below overviews a high-level view of a project-based delivery life cycle. It is a three-phase life cycle, more on this in a minute, where you incrementally build a consumable solution over time. We start with this high-level view so that we can explore several important concepts before diving into details.
Figure 1. A high-level view of the delivery life cycle (click to expand)
Granted, as you see in Figure 2 which depicts more of a system life cycle there is more to the agile SDLC than just those phases. First, there are pre-project aspects to portfolio management where potential projects or products are identified, priortized, and sufficiently funded to start an Inception phase effort. Furthermore, business and technical roadmaps may be available to guide the team’s efforts. After Transition a solution is operated and supported in production (or the marketplace in the case of commercial products). Eventually, potentially after decades of use, a solution is retired (taken out of operation). If we were to look at things from the point of view of IT, there are also cross-product/project concerns at the enterprise level such as enterprise architecture, portfolio management, reuse engineering, and more that the DA tool kit now supports. Figure 2 also indicates how the Construction, Transition, and Production phases are what is typically considered the purview of Disciplined DevOps.
Figure 2. A high-level system life cycle (click to expand)
First, the DAD delivery life cycle explicitly calls out three phases for agile project teams:
Inception. Team initiation activities occur during this phase. Although “phase” tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project. While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2013 Agile Project Initiation survey found the average agile team spends about a month in Inception whereas the most common iteration/sprint length is two weeks). So in DAD’s Inception phase we do some very lightweight visioning activities to properly frame the project. It takes discipline to keep Inception short.
Construction. During this phase a delivery team will produce a potentially consumable solution on an incremental basis. They may do so via a set of iterations (Sprints in Scrum parlance) or do so via a lean, continuous flow approach (different versions of the life cycle are discussed later). The team applies a hybrid of practices from Scrum, XP, Agile Modeling, Agile Data, and other methods to deliver the solution.
Transition. The DA recognizes that for sophisticated enterprise agile projects deploying the solution to the stakeholders is often not a trivial exercise. Delivery teams, as well as the enterprise overall, will streamline their deployment processes so that over time this phase become shorters and ideally disappears from adopting continuous deployment strategies. It takes discipline to evolve Transition from a phase to an activity.
The DAD Life Cycles
The DA tool kit does not prescribe a single life cycle, unlike other agile methods such as Scrum. Every team is in a unique situation, therefore the DA tool kit supports several life cycles to choose from.
In this section we present overviews of each DAD life cycle, each of which links to a more detailed article. The DAD life cycles are:
- The Agile Life Cycle: A Scrum-based Project Life Cycle
- The Lean Life Cycle: A Kanban-based Project Life Cycle
- The Continuous Delivery:Agile Life Cycle
- The Continuous Delivery:Lean Life Cycle
- The Exploratory (Lean Startup) Life Cycle
- The Program Life Cycle for a Team of Teams
The Agile Life Cycle: A Scrum-based Project Life Cycle
Figure 3 presents a detailed view of DAD’s Agile life cycle which extends Scrum’s construction life cycle. We call this the basic/agile life cycle because it’s likely where you’re going to start. Common scenarios for adopting this version of the life cycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach.
Figure 3. DAD’s Agile (Scrum based) life cycle (click to expand)
- It’s iteration based
- It uses non-Scrum terminology
- It shows inputs from outside the delivery life cycle
- There is a work item list, not a product backlog
- It includes explicit milestones
Figure 4 depicts what we call the Lean life cycle. This 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 4. DAD’s Lean life cycle (click to expand)
There are several interesting features to this life cycle:
It supports a continuous flow of development
Practices are on their own cadences
It has a work item pool
The Continuous Delivery: Agile life cycle is depicted in Figure 5. This life cycle is a natural progression from the Agile life cycle. Teams typically evolve to this life cycle from the Agile life cycle, often adopting iteration lengths of one-week or less. The key difference between this and the Agile life cycle is that the continuous delivery life cycle results in a release of new functionality at the end of each iteration rather than after a set of iterations. Teams require a mature set of practices around continuous integration and continuous deployment and other Disciplined DevOps strategies.
Figure 5. DAD’s Continuous Delivery: Agile life cycle (click to expand)
The Continuous Delivery: Lean DAD Life Cycle
Figure 6 depicts DAD’s Continuous Delivery: Lean life cycle. It is basically a leaner version of the previous life cycle 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. As with the agile version of the continuous delivery life cycle, teams require a mature set of practices around continuous integration and continuous deployment and other Disciplined DevOps strategies.
Figure 6. DAD’s Continuous Delivery: Lean life cycle (click to expand)
Figure 7 depicts DAD’s Exploratory life cycle. This life cycle 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. As a result they need to quickly explore what the market wants via a series of quick learning experiments. In effect this life cycle can be a replacement for the Inception phase of other DAD life cycles to validate the vision or used continuously throughout the life cycle.
Figure 7: DAD’s Exploratory life cycle (click to expand)
A Program Life Cycle for a Team of Teams
Figure 8 depicts DAD’s Program life cycle. DAD’s Program life cycle describes how to organize a team of teams. Large agile teams are rare in practice, but they do happen. This is exactly the situation that scaling frameworks such as SAFe, LeSS, and Nexus address.
Figure 8: DAD’s Program Life Cycle (click to expand).
And Don’t Forget Waterfall
Traditional development, also called serial or waterfall, is based on the idea that the delivery life cycle should be organized into phases or stages. Figure 1 depicts a classic waterfall life cycle, similar to what Winston Royce originally proposed (and recommended against) in his 1970 paper. Figure 8 depicts the V-model version of the traditional approach where the test phase is depicted as multiple stages and there are clear indications of what each testing activity validates (for example, Integration Test validates your architecture).
Figure 9: The Waterfall Life Cycle – V-model depiction (click to expand).
The DA tool kit does not support a traditional life cycle. We have purposefully left traditional out of scope for DA. Having said that, we do recognize that in the vast majority of organizations you will have a multi-modal approach where some teams are following an agile approach, some are lean, some are taking a continuous delivery approach, and some are still following traditional. The more disciplined your organization, the more skilled your people, the less likely it is to have traditional teams in practice. For more about the waterfall life cycle, read the article When Does Traditional Development Make Sense?
How to Choose a Life Cycle
The team should choose it’s own life cycle. 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 below there are common considerations for when to use each life cycle, but the primary considerations are always the skill and preferences of the team itself.
The following table compares the life cycles, suggesting when you would choose to follow each one.
|Life Cycle||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|
Life Cycles and Continuous Improvement
Disciplined Agile teams are always striving to optimize flow, to improve their process and work environment as they learn through their experiences and through purposeful experimentation. An implication of this is that they may choose to improve their process so much that they effectively work their way into a more effective life cycle. Figure 10 shows common evolution paths that we’ve seen teams go through. Along the X-axis you see that over time teams will progress towards a continuous release strategy (along the lines of Disciplined DevOps), being long-lived stable teams as opposed to short-term project teams, towards shorter feedback cycles (due to improved collaboration), and towards automated regression testing.
Figure 10. Evolution paths for DAD life cycles (click to expand)
What Figure 10 doesn’t show is how the Exploratory life cycle fits in. This is because the Exploratory life cycle isn’t a full solution development 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 appears the product will succeed then the team shifts into one of the delivery life cycles of Figure 10. In that way it replaces a good portion of the Inception phase efforts for the team. Another common scenario is that a team is in the middle of development and realizes that they have a new idea for a major feature that needs to be better explored before investing serious development effort into it. So the team will shift into the Exploratory life cycle for as long as it takes to either flesh out the feature idea or to disprove its market viability.
Why Support Several Life Cycles?
This is a good question. First, one life cycle clearly does not fit all. Teams find themselves in a unique situation: team members are unique individuals with their own skills and preferences for working, let alone the scaling/tailoring factors such as team size, geographic distribution, domain complexity, organizational culture, and so on which vary by team. Because teams find themselves in a wide variety of situations shouldn’t a tool kit such as DA support several life cycles? Furthermore, just from the raging debates on various agile discussion forums, in agile user groups, at agile conferences, and even within organizations themselves it’s very easy to empirically observe that agile teams are in fact following different types of life cycles.
Second, we were uncomfortable with the idea of prescribing a single life cycle. We wanted to avoid prescription in the DA tool kit to begin with, for all the rhetoric about the evils of prescription within the Scrum community it’s clear that Scrum is in fact quite prescriptive in practice. We’ve seen many teams get into trouble trying to follow agile methods such as Scrum to the letter of the law in an environment where “Scrum out of the box” really isn’t a good fit.
Third, we’re firm believers in process improvement. If you are in fact improving your process as you learn, is it not realistic that your life cycle will evolve over time? Of course it will. We’ve seen teams start with something close to the basic/agile life cycle that evolve it to the advanced/lean or continuous delivery life cycles over time.
The Downside of Supporting Several Life Cycles
There is clearly a downside to explicitly supporting several life cycles. By doing so we explicitly admit that DA teams will be follow a unique tailoring of the process that best fits their situation, a concept that can be antithetical in organizations still clinging to the notion of repeatable processes (DA promotes repeatable results over repeatable processes). It also makes it clear that enterprise professionals, such as enterprise architects or data management groups, need to be sufficiently flexible to support several delivery life cycles. Instead of sub-optimizing around such enterprise processes (i.e. forcing all project teams to conform to a single data management strategy) you instead want to build enterprise teams that are sufficiently skilled and flexible to support delivery teams in a manner which best suits the delivery teams. Finally, it’s clear that governance needs to be results based, not artifact based. The good news is that DA builds effective governance right into the tool kit.