How Do You Choose Between Software Lifecycles?
From the Disciplined Agile Blog
by Tatsiana Balshakova,
Mark Lines, Mike Griffiths, James Trott, Bjorn Gustafsson, Curtis Hibbs, Scott Ambler
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.
View Posts By:
Tatsiana Balshakova
Mark Lines
Mike Griffiths
James Trott
Bjorn Gustafsson
Curtis Hibbs
Scott Ambler
Past Contributors:
Joshua Barnes
Michael Richardson
Daniel Gagnon
Valentin Tudor Mocanu
Kashmir Birk
Glen Little
Klaus Boedker
Recent Posts
DA 5.6 is released
Disciplined Agile 5.5 Released
Choose Your WoW! Second Edition Is Now Available
Requisite Agility applied in Project Management
Disciplined Agile and PMBoK Guide 7th Edition
Categories
#ChoiceIsGood,
#ChooseYourWoW,
#ConsumableSolution,
#ContinuousImprovement,
#CoreAgilePractices,
#experiment,
#Experimentation,
#GuidedContinuousImprovement,
#Kaizen,
#LifeCycles,
#ProcessImprovement,
#TealOrganizations,
Adoption,
agile,
agile adoption,
Agile Alliance,
Agile Business Analyst,
Agile certification,
agile data,
agile governance,
agile lifecycle,
agile metrics,
agile principles,
agile transformation,
Agile2018,
Agile2019,
Agile20Reflect,
AgileData,
Analogy,
announcement,
Architecture,
architecture,
architecture owner,
Articles and publications,
Asset Management,
Atari,
Backlog,
Barclays,
being agile,
benefits,
bi,
blades,
book,
Branching strategies,
Browser,
Business Agility,
business intelligence,
business operations,
capex,
Case Study,
Certification,
certification,
charity,
Choose your WoW,
CMMI,
cmmi,
Coaching,
Collaboration,
Communications Management,
Compliance,
Compliancy,
Conference,
Construction,
Construction phase,
Context,
Continuous Improvement,
coordination,
COVID-19,
Culture,
culture,
Cutter,
DA,
DAD,
DAD Book,
DAD discussions,
DAD press,
DAD roles,
DAD supporters,
DAD webcast,
DADay2019,
Data Management,
database,
dependencies,
Deployment,
Development Strategies,
DevOps,
disaster,
Discipline,
discipline,
Disciplined Agile,
disciplined agile delivery,
disciplined agile delivery blog,
Disciplined Agile Enterprise,
disciplined devops,
Documentation,
Domain complexity,
dw,
DW/BI,
Energy Healing,
Enterprise Agile,
Enterprise Architecture,
Enterprise Awareness,
enterprise awareness,
Essence,
estimation,
Evolving DA,
Executive,
Experiment,
facilitation,
FailureBow,
feedback-cycle,
finance,
Financial,
FLEX,
Flow,
foundation layer,
Funding,
GCI,
GDD,
Geographic Distribution,
gladwell,
global development,
Goal-Driven,
goal-driven,
goals,
Governance,
GQM,
Guideline,
Hybrid,
Improvement,
inception,
Inception phase,
India,
information technology,
infosec,
Introduction,
iterations,
Kanban,
large teams,
layer,
lean,
Lean Startup,
learning,
Legal Project Management,
LeSS,
Lifecycle,
lifecycle,
Manifesto,
mark lines,
marketing,
MBI,
Metaphor,
Metrics,
metrics,
mindset,
Miscellaneous,
MVP,
News,
News and events,
Non-Functional Requirements,
non-functional requirements,
Non-solo development,
offshoring,
Operations,
opex,
Organization,
Outsourcing,
outsourcing,
paired programming,
pairing,
paper,
People,
People Management,
phases,
Philosophies,
Planning,
PMBoK,
PMI,
PMI and DA,
PMI Chapter,
Portfolio Management,
post-format-quote,
Practices,
practices,
Principle,
Process,
process improvement,
process tailoring,
Product Management,
product owner,
Product Owners,
productivity,
Program Management,
Project Management,
project-initiation,
Promise,
Quality,
quality,
rational unified process,
Refactoring,
Reiki,
Release Management,
release management,
Remote Training,
Remote Work,
repeatability,
requirements,
Requirements Management,
research&development,
responsibilities,
retrospectives,
Reuse,
Reuse Engineering,
ride for heart,
rights,
Risk Management,
Risk Management,
Risk management,
Roles,
RUP,
SAFe,
sales,
Scaling,
scaling,
scaling agile,
Scheduled Workshops,
SCM,
scorecard,
Scrum,
ScrumMaster,
SDLC,
Security,
security,
self-organization,
SEMAT,
serial,
skill,
solutions software consumable shippable,
Stakeholder Management,
strategy,
Support,
Surveys,
Teal organizations,
team development,
Team Lead,
team lead,
Teams,
Technical Debt,
Teleconferencing,
Terminology,
terraforming,
test strategy,
testing,
time tracking,
Tool kit,
Toolkit,
tools,
traditional,
Transformation,
Transition iteration,
transition phase,
Uncategorized,
Upmentors,
Using PMI Standards,
value stream,
velocity,
vendor management,
Virtual Training,
Workflow,
workflow,
workspaces
Date
As you know the Disciplined Agile (DA) toolkit supports several delivery lifecycles – Agile, Lean, Continuous Delivery: Agile, Continuous Delivery: Lean, Exploratory, and Program. We do this because solution delivery teams face different situations, so one lifecycle will not fit all. This begs the question of when would a team adopt each lifecycle? That is the focus of this blog.
This blog explores the following topics:
- What lifecycles does DAD support?
- What criteria should you consider when choosing a lifecycle?
- Who chooses?
What Lifecycles Does DAD Support?
The delivery lifecycles we will explore are:
- Agile. DAD’s Agile lifecycle which extends Scrum’s construction lifecycle. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re taking an agile project approach.
- Advanced. The Lean lifecycle encompasses lean strategies such as minimizing work in process, maximizing flow, a continuous stream of work (instead of fixed iterations), and reducing bottlenecks. New work is pulled from the work item pool when the team has capacity.
- Continuous Delivery: Agile. The Continuous Delivery: Agile lifecycle is a natural progression from the Agile lifecycle. Teams typically evolve to this lifecycle from the Agile/Basic lifecycle, often adopting iteration lengths of one-week or less. The key difference between this and the Agile lifecycle is that the continuous delivery lifecycle results in a release of new functionality at the end of each iteration rather than after a set of iterations.
- Continuous Delivery: Lean. DAD’s Continuous Delivery: Lean lifecycle is basically a leaner version of the Continuous Delivery: Agile lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.
- Exploratory/Lean Startup. DAD’s Exploratory lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.
- Program. DAD’s Program lifecycle describes how to coordinate a team of teams. It is very similar to the LeSS lifecycle although does not prescribe that the subteams/squads need to be following Scrum. It can also be thought of as a simplified version of the SAFe lifecycle.
- Waterfall/Serial. Although this is not supported by Disciplined Agile, we do recognize that some teams will still follow this more traditional way of working. For more thoughts on this subject, please see the blog posting When Does Traditional Software Development Make Sense?
What Criteria Should You Consider When Choosing a Lifecycle?
The following table compares the lifecycles, suggesting when you would choose to follow each one.
| Lifecycle |
Team Type |
Time to Market |
Advantages |
Disadvantages |
When to Use |
| Agile |
Project |
Medium |
- Straightforward lifecycle based on Scrum that is easy to learn due to its prescription
|
- Iterations (sprints) motivate teams to build functionality in multi-week batches
- Releases into production typically months apart
- Tends to fall apart when requirements change often
|
Teams new to agile |
| Lean |
Project |
Fast |
- Functionality is released into production when it`s ready to go
- Work can be prioritized via a variety of criteria
- Small batches of work lead to quick flow
|
- Requires greater skill and discipline compared to the Agile lifecycle
|
Disciplined teams with quickly evolving requirements |
| Continuous Delivery: Agile |
Product (long lived) |
Fast |
- Functionality is released into production regularly at a steady flow (typically weekly)
|
- Requires significant skill and discipline
- Requires automated testing, integration, and deployment
|
Long-running teams |
| Continuous Delivery: Lean |
Product (long lived) |
Very Fast |
- Functionality is released into production continuously, typically one or more times a day
|
- Requires significant skill and discipline
- Requires automated testing, integration, and deployment
|
Long-running, disciplined teams |
| Exploratory/Lean Startup |
Experimental |
Fast |
- Quick and inexpensive way to run business experiments
- Low-risk approach to validating potential new business strategies
|
- Requires a way to target a subset of your (potential) customer base
- Often not applicable in regulatory compliance situations
- Often perceived as a strategy for startup companies only
|
Identification of a new product or service offering for the marketplace where there is a high risk of misunderstanding the needs of potential end users |
| Program (Team of Teams) |
Project |
Medium |
- Enables you to organize a large team of teams (yes, some problems require this)
- Subteams/squads can choose their own WoWs
|
- Coordination required between subteams
- Requires solid experience with small teams first (if you can’t succeed with a small agile team, you have no hope with a large one)
|
When you have a very large agile project team that is organized into a “team of teams” |
| Waterfall/Serial |
Project |
Slow |
- Comfortable approach for experienced IT professionals who have not yet transitioned to an agile or lean way of working
|
- Tends to be very high-risk in practice due to long feedback cycles and delivery of a solution only at the end of the lifecycle
- Associated risks are often overlooked by management due to façade of predictability and control provided by the paperwork produced
|
Low-risk situations where the requirements are stable and the problem has a well-known solution. For example, upgrading the workstations of a large number of users or migrating an existing system to a new platform |
Who Should Choose the Lifecycle?
The team.
They will often do this with the guidance of an experienced Disciplined Agile coach, particularly when they are new to DA. It’s tempting to have your portfolio management team to make this choice, and they may often make a (hopefully solid) suggestion when the first initiated an endeavour, but in the end it needs to be the choice of the team. As you see in the table above there are common considerations for when to use each lifecycle, but the primary considerations are always the skill and preferences of the team itself.
Related Reading
Posted
by
Scott Ambler
on: August 03, 2017 11:37 AM |
Permalink
Comments (0)
Please login or join to subscribe to this item
Please Login/Register to leave a comment.
|
No matter how much cats fight, there always seem to be plenty of kittens.
- Abraham Lincoln
|
