Project Management

Disciplined Agile

by , , , , , ,
#ChooseYourWoW | #ContinuousImprovement | #Kaizen | #ProcessImprovement | Adoption | agile | Agile certification | agile transformation | Analogy | Architecture | architecture | book | Business Agility | Certification | Choose your WoW | CMMI | Coaching | Collaboration | Compliancy | Configuration management | Construction phase | Context | Continuous Improvement | COVID-19 | Culture | culture | DAD | DAD discussions | DAD roles | Data Management | database | DevOps | Discipline | disciplined agile delivery | Documentation | DW/BI | Enterprise Agile | Enterprise Architecture | Enterprise Awareness | Essence | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Hybrid | Improvement | inception | Inception phase | Kanban | Large Teams | Lean | Lifecycle | lifecycle | Metrics | mindset | News | News and events | Non-Functional Requirements | non-functional requirements | Operations | Outsourcing | People | Philosophies | Planning | PMI | PMI and DA | Portfolio Management | Practices | Principle | Process | process improvement | Product Management | Product Owners | Program Management | Project Management | Promise | quality | Release Management | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | Workflow | show all posts

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Failure Bow: Choosing Between Life Cycles Flowchart Update

Evolving Disciplined Agile: Guidelines of the DA Mindset

Evolving Disciplined Agile: Promises of the DA Mindset

Evolving Disciplined Agile: Principles of the DA Mindset

Evolving Disciplined Agile: The DA Mindset

How Do You Choose Between Software Lifecycles?

 

Confused

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:

  1. What lifecycles does DAD support?
  2. What criteria should you consider when choosing a lifecycle?
  3. Who chooses?

What Lifecycles Does DAD Support?

The delivery lifecycles we will explore are:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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)

Successful Agile Software Development Requires a Hybrid Approach

Hybrid

Disciplined Agile Delivery (DAD) is a hybrid framework that builds upon the solid foundation of other methods and software process frameworks.  The DA toolkit adopts practices and strategies from existing sources and provides advice for when and how to apply them together.  In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.

The DA toolkit adopts strategies from the following sources:

  • Scrum.  The Scrum method focuses on team leadership and requirements change management during the construction portion of the delivery lifecycle.  Scrum captures some really great ideas that have become commonly adopted by agile teams.
  • Extreme Programming (XP). XP is an agile method that focuses primarily on construction-oriented practices such as continuous integration (CI), test-driven development (TDD), pair programming, sustainable pace, small releases, simple design, and many others.  Although XP’s practices appear straightforward on the surface, many of them require significant technical skill and discipline on the part of practitioners.
  • Lean software development.  Practitioners of agile development are increasing looking to adapt ideas from lean thinking.  Lean software development is based on seven principles: Eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole.
  • Kanban.  Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is visualized and team members pull work from a queue or work item pool.
  • Unified Process (UP).  The UP is an iterative and incremental process framework for software development.  Although often instantiated as a heavy-weight approach, it has in fact been instantiated in a very light weight and agile manner, particularly in the form of Agile Unified Process (AUP) or OpenUP.  The DA toolkit adopts and enhances several critical governance strategies from the UP.
  • Agile Modeling (AM).  AM is a practice-based methodology for effective modeling and documentation of software-based system. AM was purposely architected to be a source of strategies which can be tailored into other base processes, something DAD takes explicit advantage of.   AM strategies adopted by DAD include initial requirements and architecture envisioning, just in time (JIT) model storming, continuous documentation, and several others.
  • Agile Data.  The Agile Data (AD) method defines a collection of strategies that IT professionals can apply in a wide variety of situations to work together effectively on the data aspects of software systems. Practices for evolutionary/agile database development include database refactoring, database regression testing, agile data modeling, and continuous database integration.
  • Enterprise methods. DAD is starting to adopt strategies from enterprise IT methods such as Scaled Agile Framework (SAFe) and Enterprise Unified Process (EUP).  These strategies address enterprise architecture, product management, portfolio management, operations and support, release management and other important IT disciplines. These strategies reflect the DAD philosophy of enterprise awareness.
  • Other methods.  DAD adopts techniques and practices from other methods such as Dynamic System Development Method (DSDM), Feature Driven Development (FDD), Evo, Outside-In Development (OID), and Crystal Clear.
  • Agile development practices.  There are many practices that are not specific to agile methods that have been developed within the agile community, and DAD leverages many of them.

One of the great advantages of agile and lean software development is the wealth of practices, techniques, and strategies available to you.  This is also one of its greatest challenges because without something like DAD it’s difficult to know what to choose and how to fit them together.

Posted by Scott Ambler on: February 05, 2014 02:43 PM | Permalink | Comments (0)
ADVERTISEMENTS

"Education is an admirable thing. But it is well to remember from time to time that nothing that is worth knowing can be taught."

- Oscar Wilde

ADVERTISEMENT

Sponsors