The Continuous Delivery (CD) Software Lifecycle

Figure 1 depicts a lean, Kanban-based continuous delivery lifecycle that is well suited for a DevOps environment. The lifecycle shown in Figure 1 is oriented towards teams evolving an existing solution – with minor modifications it can be easily tailored for service teams.

Figure 1. The lean continuous delivery (click to enlarge) software lifecycle.

These are the key aspects of the lean continuous delivery lifecycle:

1. Ideation occurred in the past. Ideation and other team initiation activities occurred at some point in the past, but are not shown here for sake of simplicity.
2. Small, independent work items. Work items should be small, ideally able to be addressed in minutes or hours by the team. Furthermore, they should be independent of one another in that it shouldn’t matter in which order they are addressed.
3. Multi-classification backlog. With a lean approach your work backlog is organized into categories of work. Figure 1 indicates four categories – Expedite, Business value, Technical, and Team health – which are common ones to start with if you’re working on a software team. However, you will want to identify categories that make sense for your situation. For example, a help desk team might have Severity 1, Severity 2, Severity 3, Improvement, and Team health as categories.
4. Just in time (JIT) prioritization. Work is pulled from the backlog one item at a time when the team has the capacity to bring that item into their work process. The team will need to develop a protocol for choosing work from each category in a fair manner, you don’t want to starve out one or more of the categories.
5. Plan work. Work is planned one item at a time when that item is pulled from the backlog. This planning is hopefully done in a self-organizing manner.
6. Evolve the solution. In the case of a solution team, each work item extends the existing solution with new or updated value. Ideally the team is working on a consumable (usable, functional, and desirable) solution (addressing changes to software, hardware, supporting documentation, business processes, and even organizational structure) rather than just “working software”.
7. Deploy the solution into production. When ready, the updated solution is deployed to its customers. Because work items should be small and independent deployment ideally occurs several times a day. For teams working on software-based solutions they will require basic DevOps infrastructure – such as automated regression testing, continuous integration (CI) and continuous deployment (CD) – in place to make this work.
8. Coordination meeting. The team will want to coordinate their activities as needed. A common strategy is to have a quick meeting at the beginning of the day, although I’ve seen teams coordinate twice a day or even just a few times a week.
9. Evolve way of working (WoW). Effective teams take explicit time to learn and improve, and will often choose to experiment with WoW. Although many agile coaches will promote a “fail fast” strategy to continuous improvement, my experience is that you’re better off taking a guided continuous improvement (GCI) approach if you’re mature enough to do so.
10. Change requests. Your end users will very likely provide feedback, including both new ideas as well as potential defects. This is indicated in the diagram as change requests which should be explored and potentially evolve into work items that get categorized and put onto your backlog.
11. Replenishment session. A replenishment session is typically an agile modeling session where the team works with its stakeholders to identify new work items. Replenishment sessions occur on an as-needed basis when you get to the point that there isn’t many work items on your backlog. Your team will need to decide what they feel is the minimal amount of work they want to have on their backlog at any given time.
12. Categorize work. When new work is identified, either as change requests coming in from end users or as the result of replenishment sessions, it needs to be categorized and put onto your backlog. Part of categorization optionally includes guesstimating the work effort required for each work item.

The Continuous Delivery Lifecycle in Context

The following table puts the continuous delivery lifecycle into context. No lifecycle is suited for all situations, including this one.

Related Resources

• The Agile System Development Lifecycle (SDLC)
• Do Agile Lifecyles Have Phases? Yes!
• The Scrum Lifecycles: Construction, Project, and Solution