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.
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.
Not 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:
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:
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:
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:
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.
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.
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.