The Agile System Development Life Cycle (SDLC)
This article covers:
- The scope of life cycles
- Iteration -1: Pre-project planning
- Iteration 0: Project inception
- Construction iterations
- Release iterations
- Production
- Retirement
1. The Scope of Life Cycles
As we described in the book The Enterprise Unified Process (EUP) the scope of life cycles can vary dramatically. For example, Figure 1 depicts the Scrum construction life cycle whereas Figure 2 depicts an extended version of that diagram which covers the full system development life cycle (SDLC) and Figure 3 extends that further by addressing enterprise-level disciplines via the EUP life cycle. The points that I'm trying to make are:
- System development is complicated. Although it's comforting to think that development is as simple as Figure 1 makes it out to be, the fact is that we know that it's not. If you adopt a development process that doesn't actually address the full development cycle then you've adopted little more than consultantware in the end. My experience is that you need to go beyond the construction life cycle of Figure 1 to the full SDLC of Figure 2 (ok, Retirement may not be all that critical) if you're to be successful
- There's more to IT than development. To be successful at IT you must take a multi-system, multi-life cycle stage view as depicted in Figure 3. The reality is that organizations have many potential projects in the planning stage (which I'll call Iteration -1 in this article), many in development, and many in production.
Figure 1 uses the terminology of the Scrum methodology. The rest of this article uses the terminology popularized in the mid-1990s by the Unified Process (Sprint = Iteration, Backlog = Stack, Daily Scrum Meeting = Daily Meeting). Figure 1 shows how agilists treat requirements like a prioritized stack, pulling just enough work off the stack for the current iteration (in Scrum iterations/sprints are often 30-days long, although this can vary). At the end of the iteration the system is demoed to the stakeholders to verify that the work that the team promised to do at the beginning of the iteration was in fact accomplished.
Figure 1. The Scrum construction life cycle.
The Scrum construction life cycle of Figure 1, although attractive proves to be a bit naive in practice. Where does the product backlog come from? Does it get beamed down from the Starship Enterprise? Of course not, it's actually the result of initial requirements envisioning early in the project. You don't only implement requirements during an iteration, you also fix defects (disciplined agile teams have a parallel testing effort during construction iterations where these defects are found), go on holiday, support other teams (perhaps as reviewers of their work), and so on. So you really need to expand the product backlog into a full work items list. You also release your system into production, often a complex endeavor.
A more realistic life cycle is captured Figure 2, overviewing the full agile SDLC. This SDLC is comprised of six phases: Iteration -1, Iteration 0/Warm Up, Construction, Release/End Game, Production, andRetirement. Although many agile developers may balk at the idea of phases, perhaps Gary Evan's analogy of development seasons may be a bit more palatable, the fact is that it's been recognized that processes such as Extreme Programming (XP) and Agile Unified Process (AUP) do in fact have phases (for diagrams, see XP life cycle and AUP life cycle respectively). The Disciplined Agile Delivery (DAD) lifecyclealso includes phases (granted, I lead the development of DAD). Furthermore, the Agile MSF calls its phases/seasons "tracks".
Figure 2. A detailed agile SDLC.
Figure 3. The Enterprise Unified Process (EUP) life cycle.
Figure 4. The Agile SDLC (high-level).
On the surface, the agile SDLC of Figure 4 looks very much like a traditional SDLC, but when you dive deeper you quickly discover that this isn't the case. This is particularly true when you consider the detailed view of Figure 2. Because the agile SDLC is highly collaborative, iterative, and incremental the roles which people take are much more robust than on traditional projects. In the traditional world a business analystcreated a requirements model that is handed off to an architect who creates design models that are handed off to a coder who writes programs which are handed off to a tester and so on. On an agile project, developers work closely with their stakeholders to understand their needs, they pair together to implement and test their solution, and the solution is shown to the stakeholder for quick feedback. Instead of specialists handing artifacts to one another, and thereby injecting defects at every step along the way, agile developers are generalizing specialists with full life cycle skills.
2. Iteration -1: Pre-Project Planning
Iteration -1, the “pre-Inception phase” in the Enterprise Unified Process (EUP), is the pre-project aspects of portfolio management. During this phase you will:
3. Iteration 0/Warm Up: Project Initiation
The first week or so of an agile project is often referred to as “Iteration 0” (or "Cycle 0") or in The Eclipse Way the "Warm Up" iteration. Your goal during this period is to initiate the project by:
Figure 5: The Agile Model Driven Development (AMDD) life cycle.
The 2009 Agile Project Initiation Survey found that the average time to initiate an agile project took 3.9 weeks. Figure 6 depicts the range of initiation periods. Differences are the results of the complexity of the domain/problem space, technical complexity of what you're trying to accomplish, availability of stakeholders, ability of stakeholders to come to agreement as to the scope. and ability of the team to form itself and to obtain necessary resources.
Figure 6. How long did it take to initiate an agile project?
 4. Construction Iterations
During construction iterations agilists incrementally deliver high-quality working software which meets the changing needs of our stakeholders, as overviewed in Figure 7.
Figure 7. Agile software development process during a construction iteration.
We achieve this by:
Figure 8. Taking a "test first" approach to construction.
Figure 9. Testing during construction iterations.
 5. Release Iterations(s): The "End Game"
During the release iteration(s), also known as the "end game", we transition the system into production. Not that for complex systems the end game may prove to be several iterations, although if you've done system and user testing during construction iterations (as indicated by Figure 6) this likely won't be the case. As you can see in Figure 10, there are several important aspects to this effort:
Figure 10. The AUP Deployment discipline workflow.
As you can see in Figure 11, on average agile teams take 4.6 weeks to transition their system into production according to the November 2010 Agile State of the Art Survey. As you can see in the figure there is a wide range of time taken. I believe this variance ranges based on the complexity of the solution, the amount of deployment automation (teams that have adopted a continuous deployment strategy automate many of the technical aspects of transition), the comprehensiveness of the agile testing effort during construction, the need for manual efforts such as training and educating end users (or support or operations staff), and the organizational complexity of your environment.
Figure 11. Amount of time experienced agile teams invested in releasing/transitioning their solution into production.
 6. Production
The goal of the Production Phase is to keep systems useful and productive after they have been deployed to the user community. This process will differ from organization to organization and perhaps even from system to system, but the fundamental goal remains the same: keep the system running and help users to use it. Shrink-wrapped software, for example, will not require operational support but will typically require a help desk to assist users. Organizations that implement systems for internal use will usually require an operational staff to run and monitor systems.
This phase ends when the release of a system has been slated for retirement or when support for that release has ended. The latter may occur immediately upon the release of a newer version, some time after the release of a newer version, or simply on a date that the business has decided to end support. This phase typically has one iteration because it applies to the operational lifetime of a single release of your software. There may be multiple iterations, however, if you defined multiple levels of support that your software will have over time.
7. Retirement
The goal of the Retirement Phase is the removal of a system release from production, and occasionally even the complete system itself, an activity also known as system decommissioning or system sunsetting. Retirement of systems is a serious issue faced by many organizations today as legacy systems are removed and replaced by new systems. You must strive to complete this effort with minimal impact to business operations. If you have tried this in the past, you know how complex it can be to execute successfully. System releases are removed from production for several reasons, including:
|
Comments