All software development methods, including the Agile ones, have some sort of underlying project lifecycle. System Development Lifecycle (SDLC) is the common name for a software development process, but in the Agile world I prefer calling it a “heartbeat” reflecting the organic nature of an Agile project. Some of the big Agile methods don’t make a big deal of the heartbeat and others do. Some have such abstract lifecycles that it is actually hard to know what activities to schedule. And they all use different terms for the same thing. I have pulled out the common activities to create a generic agile lifecycle.
Generic Agile Lifecycle
I’ve come up with a generic Agile lifecycle to make it clearer what to do when. This is based on an earlier Agile Lifecycle I created for my Agile Comparison of a few years ago, which in turn was based on XP, DSDM and Scrum (Beck, 2000; Beck & Fowler, 2001; DSDM Consortium, 1997, 2002; Schwaber & Beddle, 2002, Stapleton, 1997). These methods have much in common, particularly around Agile Project Management. In addition to the Planning Game, XP also offers technical practices which are now becoming widely accepted regardless of what the project management process is. My Generic Agile Lifecycle / Agile Heartbeat takes the common elements of XP, Scrum, and DSDM and rationalises the Terminology.
The key elements are a Project Initiation followed by one or more Releases made up on one or more Timeboxes (although usually 3), and ending with a Project Closure.
Pre-Project
Before the project starts the main task is to justify doing the project, resulting in a Project Vision, Brief, Mission Statement or Business Case.
Project Initiation
Justify the project if you haven’t already done it. Form the team and get the Initial Plan, Requirements and Infrastructure. In XP this Project Initiation is called Iteration Zero.
Project Initiation: Form Team
Mobilise the people and other resources.
See Agile Project Initiation and Agile Roles and Responsibilities
Project Initiation: Initial Plan
Plan out the rest of the project, i.e. everything after Project Initiation. The plan will be detailed for Timebox 1 and high level thereafter.
The Initial Plan will evolve in parallel to the Initial Requirements and Initial Infrastructure.
See Agile Project Planning and Agile Project Estimating
Project Initiation: Initial Requirements
Gather the high level requirements during Project Initiation, but remember they are high level. Don’t get bogged down in a detailed requirements spec. Keep it light. Facilitated workshop(s) are an excellent technique to identify high level requirements from all stakeholders.
See Agile Project Scope and Agile Project Control
Project Initiation: Initial Infrastructure
The Agile approach is generally design for today and refactor tomorrow, but the Agile community now generally accepts that some upfront infrastructure work is necessary. This means setting up environments and testing frameworks, plus doing the initial architecture.
Release
A Release in this context is a piece of development ending in a public launch. Releases can be from 2 weeks to 6 months, but are usually about 3 months long. Releases have one or more Timeboxes.
DSDM originally had only one Release per project, which is the model we ended up with at the BBC as well. At the BBC we found it difficult to plan further out. In contrast, when I was running Agile projects in a software house for external customers, I found it essential to have a Release Plan that covered the entire planned scope including multiple public Releases.
Note: the term “Release” is used in several ways in the Agile approach:
- all the work needed for a public launch (the meaning intended here)
- any deployment of the software
- the final deployment of the software at the public launch
Release: Timebox
A Timebox is 1 – 6 weeks long, but usually 3 – 4 weeks. The most important thing about a timebox is that the delivery date is fixed.
Each Timebox represents a plan-do-check-act cycle (TQM) (Wikipedia: PDCA). Within the Timebox there is a Timebox Plan activity, a Development activity and a Review activity corresponding to the plan-do-check of TQM. The Act element of this PDCA cycle is when further work is scheduled into later Timeboxes.
See Agile Quality Management, Agile Risk Management, Agile Change Management, Agile Project Execution, and Agile Project Planning
Release: Timebox: Plan
Create the Timebox Plan in a Timebox Planning Meeting where the Product Owner outlines the goal for the Timebox and the developers estimate the work..
See Agile Project Planning and Agile Project Estimating
Release: Timebox: Develop
Build an increment of the software. The development part of the Timebox is sub-divided into days. Each Day has features a Daily Team Meeting.
See Agile Quality Management, Agile Risk Management, Agile Change Management, Agile Project Execution
Release: Timebox: Review
At the Timebox Review Meeting the team reviews the increment of the software and generates requirements to go back into the Release Plan. They also have a Retrospective to look at the process and how to improve it.
See Agile Quality Management, Agile Change Management, Agile Project Planning
Project Closure
Celebrate, pack up, go home.
Post-Project
Review the project to see if it and the associated product were a success.
References
Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.
Beck, K, & Fowler, M. (2001). Planning Extreme Programming. Boston: Addison-Wesley.
DSDM Consortium. (1997). Dynamic System Development Method [3rd ed.]. Tesseract Publishing.
DSDM Consortium. (2002). Framework for Business Centred Development:Handbook for DSDM Version 4.1. Author.
Schwaber, K., & Beddle, M. (2002). Agile Software Development with Scrum. NJ: Prentice Hall.
Stapleton, J. (1997). DSDM – Dynamic System Development Method: The method in practice. Harlow, England: Addison-Wesley.