- Context Counts-The Agile Scaling Model
- What Is the Disciplined Agile Delivery (DAD) Process Framework?
- People First
- Learning Oriented
- Agile
- A Hybrid Process Framework
- IT Solutions over Software
- Goal-Driven Delivery Lifecycle
- Enterprise Aware
- Risk and Value Driven
- Scalable
- Concluding Thoughts
- Additional Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
Goal-Driven Delivery Lifecycle
DAD addresses the project lifecycle from the point of initiating the project to construction to releasing the solution into production. We explicitly observe that each iteration is not the same. Projects do evolve and the work emphasis changes as we move through the lifecycle. To make this clear, we carve the project into phases with lightweight milestones to ensure that we are focused on the right things at the right time. Such areas of focus include initial visioning, architectural modeling, risk management, and deployment planning. This differs from mainstream agile methods, which typically focus on the construction aspects of the lifecycle. Details about how to perform initiation and release activities, or even how they fit into the overall lifecycle, are typically vague and left up to you.
Time and again, whenever either one of us worked with a team that had adopted Scrum we found that they had tailored the Scrum lifecycle into something similar to Figure 1.3, which shows the lifecycle of a DAD project.1 This lifecycle has several critical features:
- It’s a delivery lifecycle. The DAD lifecycle extends the Scrum construction lifecycle to explicitly show the full delivery lifecycle from the beginning of a project to the release of the solution into production (or the marketplace).
- There are explicit phases. The DAD lifecycle is organized into three distinct, named phases, reflecting the agile coordinate-collaborate-conclude (3C) rhythm.
- The delivery lifecycle is shown in context. The DAD lifecycle recognizes that activities occur to identify and select projects long before their official start. It also recognizes that the solution produced by a DAD project team must be operated and supported once it is delivered into production (in some organizations called operations) or in some cases the marketplace, and that important feedback comes from people using previously released versions of the solution.
- There are explicit milestones. The milestones are an important governance and risk reduction strategy inherent in DAD.
)
Figure 1.3. The Disciplined Agile Delivery (DAD) lifecycle
The lifecycle of Figure 1.3, which we focus on throughout this book, is what we refer to as the basic agile version. This is what we believe should be the starting point for teams that are new to DAD or even new to agile. However, DAD is meant to be tailored to meet the needs of your situation. As your team gains more experience with DAD you may choose to adopt more and more lean strategies, and may eventually evolve your lifecycle into something closer to what you see in Figure 1.4. A primary difference of this lean version of the DAD lifecycle is that the phase and iteration cadence disappears in favor of a “do it when you need to do it” approach, a strategy that works well only for highly disciplined teams.
)
Figure 1.4. A lean version of the DAD lifecycle
One of the challenges with describing a process framework is that you need to provide sufficient guidance to help people understand the framework, but if you provide too much guidance you become overly prescriptive. As we’ve helped various organizations improve their software processes over the years, we’ve come to the belief that the various process protagonists are coming from one extreme or the other. Either there are very detailed processes descriptions (the IBM Rational Unified Process [RUP] is one such example), or there are very lightweight process descriptions, with Scrum being a perfect example. The challenge with RUP is that many teams do not have the skill to tailor it down appropriately, often resulting in extra work being performed. On the other hand many Scrum teams had the opposite problem with not knowing how to tailor it up appropriately, resulting in significant effort reinventing or relearning techniques to address the myriad issues that Scrum doesn’t cover (this becomes apparent in Chapter 3). Either way, a lot of waste could have been avoided if only there was an option between these two extremes.
To address this challenge the DAD process framework is goals driven, as summarized in Figure 1.5. There are of course many ways that these goals can be addressed, so simply indicating the goals is of little value. In Chapters 6 through 19 when we describe each of the phases in turn, we suggest strategies for addressing the goals and many times discuss several common strategies for doing so and the trade-offs between them. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy most appropriate for them. This may not be the snazzy new strategy that everyone is talking about online, and it may require the team to perform some work that they would prefer to avoid given the choice.
)
Figure 1.5. Goals addressed throughout a DAD project
Figure 1.5 doesn’t provide a full listing of the goals your team will address. There are several personal goals of individuals, such as specific learning goals and the desire for interesting work, compensation, and public recognition of their work. There are also specific stakeholder goals, which will be unique to your project.
Let’s overview the DAD phases to better understand the contents of the DAD process framework.
The Inception Phase
Before jumping into building or buying a solution, it is worthwhile to spend some time identifying the objectives for the project. Traditional methods invest a large amount of effort and time planning their projects up front. Agile approaches suggest that too much detail up front is not worthwhile since little is known about what is truly required as well as achievable within the time and budget constraints. Mainstream agile methods suggest that very little effort be invested in up-front planning. Their mantra can be loosely interpreted as “let’s just get started and we will determine where we are going as we go.” To be fair, some agile teams have a short planning iteration or do some planning before initiating the project. “Sprint 0” is a common misnomer used by some Scrum teams. Extreme Programming (XP) has the “Planning Game.” In fact, a 2009 Ambysoft survey found that teams take on average 3.9 weeks to initiate their projects. In DAD, we recognize the need to point the ship in the right direction before going full-speed ahead—typically between a few days and a few weeks—to initiate the project. Figure 1.6 overviews the potential activities that occur during Inception, described in greater detail in Chapters 6 through 12. This phase ends when the team has developed a vision for the release that the stakeholders agree to and has obtained support for the rest of the project (or at least the next stage of it).
)
Figure 1.6. Inception phase overview
The Construction Phase
The Construction phase in DAD is the period of time during which the required functionality is built. The timeline is split up into a number of time-boxed iterations. These iterations, the potential activities of which are overviewed in Figure 1.7, should be the same duration for a particular project and typically do not overlap. Durations of an iteration for a certain project typically vary from one week to four weeks, with two and four weeks being the most common options. At the end of each iteration a demonstrable increment of a potentially consumable solution has been produced and regression tested. At this time we consider the strategy of how to move forward in the project. We could consider executing an additional iteration of construction, and whether to deploy the solution to the customer at this time. If we determine that there is sufficient functionality to justify the cost of transition, sometimes referred to as minimally marketable release (MMR), then our Construction phase ends and we move into the Transition phase. The Construction phase is covered in greater detail in Chapters 13 through 17.
)
Figure 1.7. Construction iteration overview
The Transition Phase
The Transition phase focuses on delivering the system into production (or into the marketplace in the case of a consumer product). As you can see in Figure 1.8 there is more to transition than merely copying some files onto a server. The time and effort spent transitioning varies from project to project. Shrink-wrapped software entails the manufacturing and distribution of software and documentation. Internal systems are generally simpler to deploy than external systems. High visibility systems may require extensive beta testing by small groups before release to the larger population. The release of a brand new system may entail hardware purchase and setup while updating an existing system may entail data conversions and extensive coordination with the user community. Every project is different. From an agile point of view, the Transition phase ends when the stakeholders are ready and the system is fully deployed, although from a lean point of view, the phase ends when your stakeholders have worked with the solution in production and are delighted by it. The Transition phase is covered in greater detail in Chapters 18 and 19.
)
Figure 1.8. Transition phase overview
Some agilists will look at the potential activities listed in Figure 1.8 and ask why you couldn’t do these activities during construction iterations. The quick answer is yes, you should strive to do as much testing as possible throughout the lifecycle and you should strive to write and maintain required documentation throughout the lifecycle, and so on. You may even do some stakeholder training in later construction iterations and are more likely to do so once your solution has been released into production. The more of these things that you do during the Construction phase, the shorter the Transition phase will be, but the reality is that many organizations require end-of-lifecycle testing (even if it’s only one last run of your regression test suite), and there is often a need to tidy up supporting documentation. The November 2010 Ambysoft Agile State of the Art survey found that the average transition/release phase took 4.6 weeks.