1. Inception. Inception is sometimes called “sprint 0,” “iteration 0,” startup, or initiation. The basic idea is that the team does just enough work to get organized and going in the right direction. The team will initially form itself, and invest some time in initial requirements and architecture exploration, initial planning, aligning itself with the rest of the organization, and of course securing funding for the rest of the project. This phase should be kept as simple and as short as possible while coming to an agreement on how the team believes it will accomplish the outcomes being asked of it by their stakeholders. The average agile/lean team spends 11 work days, so a bit more than two weeks, in Inception activities [SoftDev18].

2. Construction. The aim of Construction is to produce a consumable solution with sufficient functionality, what's known as a minimal marketable release (MMR), to be of value to stakeholders. The team will work closely with stakeholders to understand their needs, to build a quality solution for them, to get feedback from them on a regular basis, and then act on that feedback. The implication is that the team will be performing analysis, design, programming, testing, and management activities potentially every single day. More on this later.

3. Transition. Transition is sometimes referred to as a “release sprint” or a “deployment sprint,” and if the team is struggling with quality, a “hardening sprint.” The aim of Transition is to successfully release your solution into production. This includes determining whether you are ready to deploy the solution and then actually deploying it. The average agile/lean team spends six work days on Transition activities, but when you exclude the teams that have fully automated testing and deployment (which we wouldn't do), it's an average of 8.5 days [SoftDev18]. Furthermore, 26 % of teams have fully automated regression testing and deployment, and 63 % perform Transition in one day or less.

1. Testing and quality practices shift left. Agilists are clearly shifting testing practices left through greater automation and via replacing written specifications with executable specifications via practices such as test-driven development (TDD) [W] and behavior-driven development (BDD) [W]. TDD and BDD, of course, are supported by the practice of continuous integration (CI) [W]. Adoption of these strategies are key motivators for an infrastructure as code strategy where activities that are mostly manual on traditional teams become fully automated on agile teams.

2. Modeling and planning practices shift right. Agilists have also shifted modeling/mapping and planning practices to the right in the life cycle so that we can adapt to the feedback we're receiving from stakeholders. In DAD, modeling and planning are so important that we do them all the way through the life cycle in a collaborative and iterative manner [AgileModeling].

3. Stakeholder interaction shifts right. DAD teams interact with stakeholders throughout the entire endeavor, not just during the requirements and test phases at the beginning and end of the life cycle.

4. Stakeholder feedback shifts left. Traditional teams tend to leave serious stakeholder feedback to user acceptance testing (UAT) performed during the traditional test phase. DAD teams, on the other hand, seek to gain stakeholder feedback as early and as regularly as possible throughout the entire endeavor.

5. Deployment practices shift left. Deployment practices are being fully automated by agile teams, another infrastructure as code strategy, so as to support continuous deployment (CD). CD is a linchpin practice for DAD's two continuous delivery life cycles described below.

6. The real goal is continuous delivery. All of this shifting left and shifting right results in teams that are able to work in a continuous delivery manner. Process improvement is about working smarter, not harder.

1. Agile. Based on the Scrum construction life cycle, teams following this project life cycle will produce consumable solutions via short iterations (also known as sprints or timeboxes).

2. Continuous Delivery: Agile. Teams following this agile-based life cycle will work in very short iterations, typically one week or less, where at the end of each iteration their solution is released into production.

3. Lean. Based on Kanban, teams following this project life cycle will visualize their work, reduce work in process (WIP) to streamline their workflow, and pull work into the team one item at a time.

4. Continuous Delivery: Lean. Teams following this lean-based life cycle will release their work into production whenever possible, typically several times a day.

5. Exploratory. Teams following this life cycle, based on Lean Startup [Ries] and design thinking in general, will explore a business idea by developing one or more minimal viable products (MVPs), which they run as experiments to determine what potential customers actually want. This life cycle is often applied when a team faces a “wicked problem” [W] in their domain.

6. Program. A program is effectively a large team that is organized into a team of teams.

• The Inception phase. As we described earlier, the team's focus is to do just enough work to get organized and going in the right direction. DAD aims to streamline the entire life cycle from beginning to end, including the initiation activities addressed by Inception. Inception ends when we have an agreed-upon vision regarding the expected outcomes for the team and how we're going to achieve them.

• Construction is organized into short iterations. An iteration is a short period of time, typically two weeks or less, in which the delivery team produces a new, potentially consumable version of their solution. Of course, for a new product or solution you may not have something truly consumable until after having completed several iterations. This phase ends when we have sufficient functionality, also known as a minimal marketable release (MMR).

• Teams address work items in small batches. Working in small batches is a fundamental of Scrum, and because this life cycle is based on Scrum, it's an important aspect of it. DAD teams, regardless of life cycle, are likely to work on a range of things: implementing new functionality, providing stakeholders with positive outcomes, running experiments, addressing end-user change requests coming in from usage of the current solution running in production, paying down technical debt, taking training, and many more. Work items are typically prioritized by the product owner, primarily by business value although risk, due dates, and severity (in the case of change requests) may also be taken into account. The Address Changing Stakeholder Needs process goal (Chapter 16) provides a range of options for managing work items. In each iteration, the team pulls a small batch of work off of the work item list that they believe they can achieve during that iteration.

• Critical ceremonies have a defined cadence. Also like Scrum, this life cycle schedules several agile ceremonies on specific cadences. At the beginning of each iteration, the team performs detailed planning for the iteration, and at the end of the iteration, we hold a demonstration. We hold a retrospective to evolve our WoW, and we make a go-forward decision. We also hold a daily coordination meeting. The point is that by prescribing when to hold these important work sessions, we take some of the guess work out of the process. The downside is that Scrum injects a fair bit of process overhead with ceremonies. This is a problem that the Lean life cycle addresses.

• The Transition phase. The aim of the Transition phase is to ensure that the solution is ready to be deployed and, if so, to deploy it. This “phase” can be automated away (which is exactly what happens when evolving toward the two continuous delivery life cycles).

• Explicit milestones. This life cycle supports the full range of straightforward, risk-based milestones, as you see depicted along the bottom of the life cycle. The milestones enable leadership to govern effectively, more on this later. By “lightweight” we mean that milestones do not need to be a formal bureaucratic review of artifacts. Ideally, they are merely placeholders for discussions regarding the status and health of the initiative. See the Govern Delivery Team goal in Chapter 27 for a more detailed discussion of how to keep milestones light.

• Enterprise guidance and roadmaps are explicitly shown. On the left-hand side of the life cycle, you see that important flows come into the team from outside of the delivery life cycle. That's because solution delivery is just part of your organization's overall DevOps strategy, which in turn is part of your overall IT strategy. For example, the initial vision and funding for your endeavor may be coming from a product management group, and the roadmaps and guidance from other areas such as enterprise architecture, data management, and security (to name a few). Remember, DAD teams work in an enterprise-aware manner, and one aspect of doing so is to adopt and follow appropriate guidance.

• Operations and support are depicted. If your team is working on the new release of an existing solution then you are likely to receive change requests from existing end users, typically coming to you via your operations and support efforts. For teams working in a DevOps environment, it may be that you're responsible for running and supporting your solution in production.

• Automation and technical practices are key. Teams require a mature set of technical practices around automated regression testing, continuous integration (CI), and continuous deployment (CD). To support these practices, investment in tools and paying down technical debt, and in particular writing the automated regression tests that are missing, needs to occur.

• Inception occurred in the past. When the team was first initiated, Inception would have occurred and it may have occurred again when significant change occurred such as a major shift in business direction or technical direction. So, if such as shift occurs again then yes, you should definitely invest sufficient effort to reorient the team—we see this as an activity, not a phase, hence Inception isn't depicted. Having said this, we do see teams stop every few months and explicitly invest several days to negotiate, at a high level, what they will do for the next few months. This is something that SAFe calls big room planning and Agile Modeling calls an agile modeling session. These techniques are discussed in the Coordinate Activities process goal (Chapter 23).

• Transition has become an activity. Through automation of testing and deployment, the Transition phase has evolved from a multiday or multiweek effort to a fully automated activity that takes minutes or hours.

• Explicit milestones and incoming workflows. There are still common, risk-based milestones to support consistent governance. Some milestones are no longer appropriate, in particular Stakeholder Vision and Proven Architecture would have been addressed in the past (although if major changes occur there's no reason why you couldn't address these milestones again). Incoming workflows from other parts of the organization are shown, just as with the Agile and Lean life cycles.

• Delivery of new functionality is truly continuous. Changes to production are delivered several times a day by the team, although the functionality may not be turned on until it is needed (this is a DevOps strategy called feature toggles described in Chapter 19).

• Automation and technical practices are key. This is similar to the Continuous Delivery: Agile life cycle.

• Inception and Transition have disappeared from the diagram. This occurred for the same reasons they disappeared for Continuous Delivery: Agile.

• Explicit milestones and incoming workflows. Once again, similar to the Continuous Delivery: Agile life cycle.

• This is a simplified scientific method. We come up with a hypothesis of what our customers want, we develop one or more minimal viable products (MVPs) which are deployed to a subset of potential customers, then we observe and measure how they work with the MVP(s). Based on the data we collect, we decide how we will go forward. Do we pivot and rethink our hypothesis? Do we rework one or more MVPs to run new experiments based on our improved understanding of customer needs? Do we discard one or more ideas? Do we move forward with one or more ideas and “productize them” into real customer offerings?

• MVPs are prototypes (at best). The MVPs we create are built hastily, often “smoke and mirrors” or prototype-quality code, of which the sole purpose is to test out a hypothesis. It is not the “real thing,” nor is it meant to be. It's a piece of functionality or service offering that we get out in front of our potential customers to see how they react to it. See Figure 6.11 for an overview of MVPs and related concepts.

• Run several experiments in parallel. Ideally, this life cycle entails running several experiments in parallel to explore our hypothesis. This is an improvement over Lean Startup, which focuses on a single experiment at a time—although it is easier to run a single experiment at a time, it takes longer to get to a good idea and, worse yet, runs the risk of identifying a strategy before other options have been considered.

• Failed experiments are still successes. Some organizations are reluctant to run experiments because they are scared of failing, which is unfortunate because an exploratory approach such as this actually reduces your risk of product failure (which tend to be large, expensive, and embarrassing). Our advice is to make it “safe to fail,” to recognize that when an experiment has a negative result that this is actually a success because you have inexpensively learned what won't work, enabling you to refocus on looking for something that will.

• Follow another life cycle to build the real product. Once we've discovered one or more ideas that it appears will succeed in the market, we now need to build the “real solution.” We do this by following one of the other DAD life cycles.

1. Exploration of a new offering. The most compelling reason, at least for us, is to apply this life cycle to explore an idea that your organization has for a new product.

2. Exploration of a new feature. At a smaller scale, the Exploratory life cycle is effectively the strategy for running an A/B test or split test where you implement several versions of a new feature and run them in parallel to determine which one is most effective.

3. Parallel proof of concepts (PoCs). With a PoC, you install and then evaluate a package, sometimes called a commercial off-the-shelf solution (COTS), within your environment. An effective way to decrease the risk of software acquisition is to run several PoCs in parallel, one for each potential software package that you are considering, and then compare the results to identify the best option available. This is often referred to as a “bake-off.”

4. Strategy comparisons. Some organizations, particularly ones in very competitive environments, will start up several teams initially to work on a product. Each team basically works through Inception, and perhaps even a bit of Construction, the aim being to identify a vision for the product and prove out their architectural strategy. In this case, their work is more advanced than an MVP but less advanced than an MMR. Then, after a period of time, they compare the work of the teams and pick the best approach—the “winning team” gets to move forward and become the product team.

• There's an explicit Inception phase. Like it or not, when a team is new, we need to invest some up-front time getting organized, and this is particularly true for large teams given the additional risk we face. We should do so as quickly as possible, and the best way is to explicitly recognize what we need to do and how we'll go about doing so.

• Subteams/squads choose and then evolve their WoW. Subteams, sometimes referred to as squads, should be allowed to choose their own WoW just like any other team would. This includes choosing their own life cycles as well as their own practices—to be clear, some teams may be following the Agile life cycle, some the Continuous Delivery: Lean life cycle, and so on. We may choose to impose some constraints on the teams, such as following common guidance and common strategies around coordinating within the program (captured by the Coordinate Activities process goal in Chapter 23). As Figure 6.13 implies, we will need to come to an agreement around how we'll proceed with cross-team system integration and cross-team testing (if needed), options for which are captured by the Accelerate Value Delivery process goal (Chapter 19) and the Develop Test Strategy process goal (Chapter 12), respectively. Where a framework such as SAFe would prescribe a strategy such as a release train to do this, DAD offers choices and helps you to pick the best strategy for your situation.

• Subteams can be feature teams or component teams. For years within the agile community, there has been a debate around feature teams versus component teams. A feature team works vertical slices of functionality, implementing a story or addressing a change request from the user interface all the way through to the database. A component team works on a specific aspect of a system, such as security functionality, transaction processing, or logging. Our experience is both types of teams have their place, they are applicable in certain contexts but not others, and the strategies can and often are combined in practice.

• Coordination occurs at three levels. When we're coordinating between subteams, there are three issues we need to be concerned about: coordinating the work to be done, coordinating technical/architectural issues, and coordinating people issues. In Figure 6.13, this coordination is respectively performed by the product owners, the architecture owners, and the team leads. The product owners of each subteam will self-organize and address work/requirements management issues among themselves, ensuring that each team is doing the appropriate work at the appropriate time. Similarly, the architecture ownership team will self-organize to evolve the architecture over time and the team leads will self-organize to manage people issues occurring across teams. The three leadership subteams are able to handle the type of small course corrections that are typical over time. The team may find that they need to get together occasionally to plan out the next block of work—this is a technique that SAFe refers to as program increment (PI) planning and suggests that it occurs quarterly. We suggest that you do it when and if it makes sense.

• System integration and testing occurs in parallel. Figure 6.12 shows that there is a separate team to perform overall system integration and cross-team testing. Ideally, this work should be minimal and entirely automated in time. We frequently need a separate team at first, often due to lack of automation, but our goal should be to automate as much of this work as possible and push the rest into the subteams. Having said that, we've found that usability testing across the product as a whole, and similarly user acceptance testing (UAT), requires a separate effort for logistical reasons.

• Subteams are as whole as they can be. The majority of the testing effort should occur within the subteams just like it would on a normal agile team, along with continuous integration (CI) and continuous deployment (CD).

• We can deploy any time we want. We prefer a CD approach to this, although teams new to agile programs may start by releasing quarterly (or even less often) and then improve the release cadence over time. Teams who are new to this will likely need a Transition phase, some people call these “hardening sprints” or “deployment sprints” the first few times. The Accelerate Value Delivery process goal (Chapter 19) captures various release options for delivery teams and the Release Management process blade [AmblerLines2017] for organizations as a whole. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context-sensitive manner. Each process blade addresses a specific capability, such as finance, data management, reuse engineering, or procurement—just like process goals are described using process goal diagrams, so are process blades.

• Scaling is hard. Some problems require a large team, but to succeed you need to know what you're doing. If you're struggling with small-team agile, then you're not ready for large-team agile. Furthermore, as we learned in Chapter 3, team size is only one of six scaling factors that our team may need to contend with, the others being geographic distribution, domain complexity, technical complexity, organizational distribution, and regulatory compliance. We cover these issues in greater detail at DisciplinedAgileDelivery.com.

1. Team skills. The two continuous delivery (CD) life cycles require the team to have a lot of skill and discipline. The other DAD life cycles also require skill and discipline, although the two CD life cycles stand out. With the traditional life cycle, you can get away with lower skilled people—due to the handoff-oriented nature of traditional, you can staff each phase with narrowly skilled specialists. Having said that, we have seen many traditional teams with very skilled people on them.

2. Team and organization culture. The Agile and Continuous Delivery life cycles require flexibility within the team and within the parts of the organization that the team interacts with. Lean strategies can be applied in organizations with a varying range of flexibility. Traditional can, and often is, applied in very rigid situations.

3. The nature of the problem. The Continuous Delivery life cycles work very well when you can build and release in very small increments. The other DAD life cycles work very well in small increments. Traditional is really geared for big releases.

4. Business constraints. The key issue here is stakeholder availability and willingness, although financial/funding flexibility is also critical. The Exploratory life cycle requires a flexible, customer-oriented, and experimental mindset on the part of stakeholders. Agile, because it tends to release functionality in terms of complete features, also requires flexibility in the way that we interact with stakeholders. Surprisingly, the Continuous Delivery life cycles require less stakeholder flexibility due to being able to release functionality that is turned off, thereby providing greater control over when something is released (by simply toggling it on).

1. Stakeholder Vision. The aim of the Inception phase is to spend a short, yet sufficient amount of time, typically a few days to a few weeks, to gain stakeholder agreement that the initiative makes sense and should continue into the Construction phase. By addressing each of the DAD Inception goals, the delivery team will capture traditional project information related to initial scope, technology, schedule, budget, risks, and other information albeit in as simple a fashion as possible. This information is consolidated and presented to stakeholders as a vision statement as described by the Develop Common Vision process goal (see Chapter 13). The format of the vision and formality of review will vary according to your situation. A typical practice is to review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page with regard to the project intent and delivery approach.

2. Proven Architecture. Early risk mitigation is a part of any good engineering discipline. As the Prove Architecture Early process goal (see Chapter 15) indicates, there are several strategies you may choose to adopt. The most effective of which is to build an end-to-end skeleton of working code that implements technically risky business requirements. A key responsibility of DAD's architecture owner role is to identify risks during the Inception phase. It is expected that these risks will have been reduced or eliminated by implementing related functionality somewhere between one and three iterations into the Construction phase. As a result of applying this approach, early iteration reviews/demos often show the ability of the solution to support nonfunctional requirements in addition to, or instead of, functional requirements. For this reason, it is important that architecture-savvy stakeholders are given the opportunity to participate in these milestone reviews.

3. Continued Viability. An optional milestone to include in your release schedule is related to project viability. At certain times during a project, stakeholders may request a checkpoint to ensure that the team is working toward the vision agreed to at the end of Inception. Scheduling these milestones ensures that stakeholders are aware of key dates wherein they should get together with the team to assess the project status and agree to changes if necessary. These changes could include anything such as funding levels, team makeup, scope, risk assessment, or even potentially canceling the project. There could be several of these milestones on a long-running project. However, instead of having this milestone review, the real solution is to release into production more often—actual usage, or lack thereof, will provide a very clear indication of whether your solution is viable.

4. Sufficient Functionality. While it is worthwhile pursuing a goal of a consumable solution (what Scrum calls a potentially shippable increment) at the end of each iteration, it is more common to require a number of iterations of Construction before the team has implemented enough functionality to deploy. While this is sometimes referred to as a minimal viable product (MVP), this not technically accurate as classically an MVP is meant to test the viability of a product rather than an indication of minimal deployable functionality. The more accurate term to compare to this milestone would be “minimum feature set” or “minimal marketable release (MMR),” as Figure 6.11 shows. An MMR will comprise one or more minimal marketable features (MMFs), and an MMF provides a positive outcome to the end users of our solution. An outcome may need to be implemented via several user stories. For example, searching for an item on an ecommerce system adds no value to an end user if they cannot also add the found items to their shopping cart. DAD's sufficient functionality milestone is reached at the end of the Construction phase when a MMR is available, plus the cost of transitioning the release to stakeholders is justified. As an example, while an increment of a consumable solution may be available with every two-week iteration, it may take several weeks to actually deploy it in a high-compliance environment, so the cost of deployment may not be justified until a greater amount of functionality is completed.

5. Production Ready. Once sufficient functionality has been developed and tested, transition-related activities such as data conversions, final acceptance testing, production, and support-related documentation normally need to be completed. Ideally, much of the work has been done continuously during the Construction phase as part of completing each increment of functionality. At some point, a decision needs to be made that the solution is ready for production, which is the purpose of this milestone. The two project-based life cycles include a Transition phase where the Production Ready milestone is typically implemented as a review. The two continuous delivery life cycles, on the other hand, have a fully automated transition/release activity where this milestone is addressed programmatically—typically the solution must pass automated regression testing and the automated analysis tools must determine that the solution is of sufficient quality.

6. Delighted Stakeholders. Governance bodies and other stakeholders obviously like to know when the initiative is officially over so that they can begin another release or direct funds elsewhere. The initiative doesn't end when the solution is deployed. With projects, there are often closeout activities such as training, deployment tuning, support handoffs, post-implementation reviews, or even warranty periods before the solution is considered completed. One of the principles of DA, see Chapter 2, is Delight Customers, which suggests that “satisfied” customers is setting the bar too low. The implication is that we need to verify whether we've delighted our stakeholders, typically through collection and analysis of appropriate metrics.

• Some teams within your organization will still follow a traditional life cycle—DAD explicitly recognizes this but does not provide support for this shrinking category of work.

• DAD provides the scaffolding required for choosing between, and then evolving, six solution delivery life cycles (SDLCs) based on either agile or lean strategies.

• Project-based life cycles, even agile and lean ones, go through phases.

• Every life cycle has its advantages and disadvantages; each team needs to pick the one that best reflects their context.

• Common, risk-based milestones enable consistent governance—you don't need to force the same process on all of your teams to be able to govern them.

• A team will start with a given life cycle and often evolve away from it as they continuously improve their WoW.