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

Supporting Several Lifecycles Allows for Wider Adoption of Agile

Categories: Adoption, Lifecycle

DAD Lifecycles

DAD Lifecycles

One of the key benefits of Disciplined Agile is its flexibility to apply different lifecycles, practices, and strategies based on the vast array of situations that a typical enterprise faces. It is “pragmatic agile” after all. Unfortunately many organizations box agile into a corner. Many try to standardize on one flavor such as Scrum/XP, Kanban, or worse, a prescriptive scaling pattern such as SAFe. We also sometimes see project authorities restrict agile to initiatives that pass all of a certain criteria such as; teams of less than nine people, full-time Product Owner, requirements not needed beyond user stories, collocated team, whole team, and other characteristics of “classic agile”. Using such restrictive selection criteria means that the percentage of teams that are permitted to adopt agile is often far less than if a more pragmatic approach to applying agile was permitted.   As a result we see situations whereby a large percentage of projects that could benefit from agile approaches are forced to use traditional methods. This marginalizes the adoption of agile in such enterprises as exceptions rather than the default approach that it should be.

We know that the majority of enterprises can benefit from each of DA’s lifecycles. There are some situations where a basic Agile/Scrum approach is the best choice, but in others where the work is difficult to plan a Lean lifecycle would be a better fit. On other teams that have good Disciplined DevOps technical practices in place the advantages of the Continuous Delivery:Lean lifecycle could be applied. Additionally, many organizations have leading edge initiatives such as mobile applications where the market demand of features is not known so it may be that the Exploratory lifecycle is the best fit.  Different teams require different approaches.  Choice is good.

Organizations that have adopted Disciplined Agile appreciate this flexibility and over time their mix of lifecycles changes as they move their the projects in their application portfolio from tradition to basic, and eventually to the advanced continuous lifecycles. The following diagram depicts an actual strategy of one of our customers, which shows their expected evolution to a mix of lifecycles as their adoption proceeds and their agile capabilities improve.

Adoption mix of lifecycles

As you can see from this example this organization expects to use Agile/Scrum for the majority of new agile initiatives but gradually increase the mix of the more advanced Continuous Delivery lifecycle as the teams’ capabilities improve. This is a typical pattern that we see for companies that are adopting Disciplined Agile, and in fact our new book Introduction to Disciplined Agile Delivery describes a team’s process improvement journey doing exactly that. The flexibility to adopt different lifecycles and apply a pragmatic and measured approach to adopting agile practices means that a far greater of percentage of projects can benefit from agile.

Posted by Mark Lines on: December 28, 2018 08:01 AM | Permalink | Comments (0)

Why Companies are Choosing DAD over SAFe

Scalability - canstockphoto19089920Not a week goes by where we are not asked to contrast DAD to SAFe.  In this short blog I would like to point out some things to consider as you decide whether to implement SAFe, DAD, or both.  First of all, a review of some quick facts about DAD:

  • DAD is a process decision framework, not a methodology.  It is a hybrid of leading agile and lean methods with guidance on how to make better choices when applying strategies for the situation that you find yourself in.  DAD can be summed up as “pragmatic agile“, giving you the flexibility to adapt your approach for your unique context.
  • DAD is not a scaling framework per se.  Indeed it can be equally effective on one small team as it is for agile at scale.  However mastering the DAD fundamentals of agile and lean in the enterprise dramatically increases your probability of sustainable success at scale.
  • Unlike other frameworks, DAD supports four lifecycles:  Agile/Scrum, Lean, Continuous Delivery, and Exploratory/Lean Startup.  Most if not all large organizations will find each of these lifecycles to be necessary in some situations.

SAFe provides a largely prescriptive approach to decomposing large initiatives into smaller streams of work which can be implemented by a number of teams in parallel with periodic integrations of their work and delivery to stakeholders.  SAFe does fill a need as our industry had been lacking such a pattern for scaling these large initiatives.  In our opinion, it is suitable for situations for large agile teams (say 100+) and are working on a cohesive product ideally based upon a shared architecture.  The teams should also be very competent and can be depended on to reliably deliver functionality on a common cadence with the other teams in their release train.  SAFe is definitely not a good fit for teams new to agile.

In the last few weeks I reached out to a couple of our customers at very large organizations to find out in their words why they selected DAD over SAFe.  In the first company, although they had been doing some agile in pockets over the last eight or so years, they were lacking consistency in their approach and struggling to achieve the promised benefits of agile.  They initially chose to rollout SAFe.  However, after training 120+ practitioners they stopped the training and chose to pivot to DAD.  They realized that SAFe was a poor fit for their organization for the following reasons:

  • The level of disruption required to roll out SAFe across the organization was not palatable
  • The investment in training and the overhead associated with running the SAFe program would be too high
  • SAFe would not be applicable to all types of projects so they would need another framework anyway.

In the second example, we spoke with a Fortune 100 company that is farther along in their agile journey with many highly advanced agile teams.  Their agile community of practice has over 1,700 members and they use many flavours of agile and lean.  They made a choice to go with DAD across the company rather than SAFe.  They do use SAFe in one area of business that has a large yet highly cohesive development team working on a common product.  But beyond this line of business they have a vast array of projects, technologies, and skill sets.  They chose DAD for the following reasons:

  • Enterprise practicality
  • A choice of four lifecycles supporting all flavors of agile yet having some consistency that a toolkit provides
  • Built-in, lightweight agile governance
  • Most of their development teams are geographically dispersed which would make SAFe impractical
  • Support for projects using more traditional approaches (Note: In the majority of large enterprises agile teams need to collaborate with traditional teams)

We of course understand DAD’s value proposition but it is particularly useful to hear it from real customers.  While we are pleased that SAFe has given us a pattern for scaling agile initiatives albeit in a largely rigid and prescriptive fashion, we encourage you to consider the following points before rolling it out aggressively across your organization:

  • Do you really need to have large projects?  A large organization does not necessarily equate to large development teams.  In fact you should try to reduce the size of your projects and product teams whenever possible to reduce overall risk.  In short, your first approach should be to “descale” to whatever degree possible because large projects typically fail.
  • DAD provides the foundation for scaling.  Without a solid base of enterprise agile capability it will be difficult to successfully adopt scaling frameworks such as SAFe or LeSS.  If you’re still struggling to succeed consistently on small agile teams, what makes you think you can succeed on large agile teams?
  • Agile governance built in.  Your sponsors don’t care what agile “religion” you follow.  They would however like to see consistent views on the health and status of your projects regardless of the implementation approach.  DAD provides guidance on lightweight governance in a consistent fashion.
  • DAD is pragmatic agile.  The framework provides rich and flexible guidance for the vast array of situations that your organization faces.  DAD does this through its process goal driven approach.  Choice is good.
  • One process does not fit all.  Beware the hype.  There is no silver-bullet process.  Even if you find a place to utilize SAFe, you will need other approaches.  So beware of hitting all projects with the SAFe sledgehammer.  It simply doesn’t fit in many if not most situations.

In a nutshell, our recommendation is to adopt DAD to support the diversity of people, processes, and technologies found in any large organization.  Then apply the SAFe scaling pattern if and when it makes sense.  Not the other way around.

In an upcoming article we will be describing how you could apply DAD to help you be more successful in your SAFe implementations.

Posted by Mark Lines on: June 17, 2015 10:37 AM | Permalink | Comments (0)

Comparing DAD to the Rational Unified Process (RUP) - Part 2

This post is a follow-up to Comparing DAD to the Rational Unified Process (RUP) – Part 1.  In that post I described in some detail why Disciplined Agile Delivery (DAD) is not “Agile RUP”.  DAD is quite different in both approach and content.  There are however some very good principles that the Unified Process (UP) incorporates that are not part of mainstream agile methods.  This post describes what parts of the UP made it into the DA toolkit.

DAD suggests a full delivery lifecycle approach similar to RUP.  DAD recognizes that despite some agile rhetoric projects do indeed go through specific phases.  RUP explicitly has four phases for Inception, Elaboration, Construction, and Transition.  For reasons that I described in the last post, DAD does not include an explicit Elaboration phase.  However the milestone for Elaboration is still in DAD which I will describe shortly.  As the DAD basic lifecycle diagram shows, DAD has three of the four RUP phases.

DAD Agile Project Lifecycle

  • The Inception phase.  An important aspect  of DAD is its explicit inclusion of an Inception phase where project initiation activities occur.  As Scott Ambler says in one of his posts “Although phase tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project.  While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than the general perception (the 2009 Agile Project Initiation survey  found the average agile team spends 3.9 weeks in Inception)”.  So in DAD’s Inception phase (usually one iteration) we do some very lightweight visioning activities to properly frame the project.  The milestone for this phase is to obtain “Stakeholder consensus” on how to proceed.  In the book we describe various strategies to get through the Inception phase as quickly as possible, what needs to be done, and how to get stakeholders consensus.
  • The Construction phase.  This phase can be viewed as a set of iterations (Sprints in Scrum parlance) to build increments of the solution.  Within each iteration the team applies a hybrid of practices from Scrum, XP, Agile modeling, Agile data, and other methods to deliver the solution.  DAD recommends a risk-value approach of prioritizing work in the early iterations which draws from the RUP principle of mitigating risk as early as possible in the project by proving the architecture with a working solution.  We therefore balance delivering high-value work with delivering work related to mitigating these architectural risks.  Ideally we deliver stories/features in the early iteration that deliver functionality related to both high business value and risk mitigation (hence DAD’s “risk-value” lifecycle). It is worthwhile to have a checkpoint at the end of the early iterations to verify that indeed our technical risks have been addressed.  DAD has an explicit milestone for this called “Proven architecture”.  This is similar to the RUP Elaboration milestone without risking the confusion that the Elaboration phase often caused for RUP implementations.  All agile methods seek to deliver value into the hands of the stakeholders as quickly as possible.  In many if not most large enterprises it is difficult to actually deliver new increments of the solution at the end of each iteration.  DAD therefore recognizes this reality and assumes that in most cases there will be a number of iterations of Construction before the solution is actually deployed to the customer.  As we make clear in the book, although this is the classic DAD pattern, you should strive to be able to release your solution on a much more frequent basis in the spirit of  achieving the goal of “continuous delivery”.  The milestone for the end of Construction is that we have “Sufficient functionality” to deploy to the stakeholders.  This is the same milestone as the RUP’s Construction milestone.  During the Construction phase it may make sense to periodically review the progress of the project against the vision agreed to in Inception and potentially adjust course.  These optional milestones in DAD are referred to as “Project viability”.
  • The Transition phase.  DAD recognizes that for sophisticated enterprise agile projects often deploying the solution to the stakeholders is not a trivial exercise.  To account for this reality DAD incorporates the RUP Transition phase which is usually one short iteration.  As DAD teams, as well as the enterprise overall streamline their deployment processes this phase should become shorter and ideally disappear over time as continuous deployment becomes possible.  RUP’s Transition milestone is achieved when the customer is satisfied and self-sufficient.  DAD changes this to “Delighted stakeholders”.  This is similar to lean’s delighted customers but we recognize that in an enterprise there are more stakeholders to delight than just customers, such as production support for instance.  One aspect of RUP’s Transition phase is that it is not clear on when during the phase deployments actually take place.  Clearly stakeholders aren’t delighted and satisfied the day the solution goes “live”.  There is usually a period of stabilization, tuning, training etc. before the stakeholders are completely happy.  So DAD has a mid-Transition milestone called “Production ready”.  Some people formalize this as a “go/no go” decision.

So in summary, DAD frames an agile project within the context of an end-to-end risk-value lifecycle with specific milestones to ensure that the project is progressing appropriately.  These checkpoints give specific opportunities to change course, adapt, and progress into the next phases of the project.  While the lifecycle is similar to that of RUP, as described in Part 1 of this post it is important to realize that the actual work performed within the iterations is quite different and far more agile than a typical RUP project.

At Scott Ambler + Associates we are getting a lot of inquiries from companies seeking help to move from RUP to the more agile yet disciplined approach that DAD provides.

Posted by Mark Lines on: November 11, 2012 11:48 AM | Permalink | Comments (0)
ADVERTISEMENTS

I think somebody should come up with a way to breed a very large shrimp. That way, you could ride him, then, after you camped at night, you could eat him. How about it, science?

- Jack Handey

ADVERTISEMENT

Sponsors