Disciplined Agile

The results of the 2018 State of Agile survey (StateOfAgile.com) have just been released.  This survey, while not particularly scientific in its approach, is a widely read and frequently quoted survey of what people are actually doing on a variety of agile topics.  It is good to see that Disciplined Agile continues to grow in popularity, up from 5% marketshare to 7%, behind only  SAFe which commands a 30% market share and is the clear leader (Scrum of Scrums is ahead of DAD, but it is just a practice, not a method).  While we are very pleased that people are finally starting to understand what DA is and how it can help them, I am not particularly fond of the way the question is framed in the survey and would like to share my thoughts for how it could be improved, and my interpretation of the findings.

1. Disciplined Agile (DAD) is listed as an option in the “Which scaling method/approach do you use?”.  People who understand DA know that it is actually not specifically a scaling framework.  It is rather a toolkit of strategies, a hybrid of practices from many methods and frameworks which can help you optimize your way of working (WoW) regardless of which approach you use.  It can be used on one small Scrum team, or dozens of SAFe teams.  Whatever approach you use, DA can help you to become even more awesome! #beawesome
2. As I said above, Scrum of Scrums should not be one of the choices as it is simply a coordination practice for Scrum at scale, not a method.
3. “Don’t know” is interesting as an option.  It puzzles me that people that are answering this survey aren’t aware of their organization’s approach.  My suspicion is that many of the people picking this selection actually mean “Not applicable” as many organizations do not scale agile.  I think that this should available as a selection.
4. The question really should be a multiple choice, rather than single.  Most organizations use a variety of approaches.  It would be more useful to ask “What percentage of your IT spend uses each of the following approaches?”
5. Spotify is actually not a framework.  It is how a Swedish music company circa 2014 had adapted agile at that point in time, to optimize their WoW for their unique context.  If you copy their approach you are copying an old approach of a company in a situation unlike yourselves, and for which they have evolved away from significantly.
6. I find “Internally created methods” intriguing as a choice.  We think that this is what all companies should aspire towards.  Start with either where you are currently, or one of the other methods (recipes), and then use the DA Toolkit to either evolve away from, or to improve your approach for your unique organization and team context.
7. Spotify actually embodies this approach.  They have continually evolved, improving, and optimizing their way of working.  Menlo Innovations also has done the same thing, starting with Extreme Programming (XP) as their core method, and then optimized for what works for them.  Rather than copying other companies approaches we should “learn how to learn” about what works best for us. We describe this approach of leveraging proven fit-for-context practices in our Choose your Wow! book as “Continuous Guided Improvement”.  Starting with some basic scaffolding of an existing method (what we refer to as “lifecycles” in DAD) provides a jumpstart on your WoW optimization.

We would recommend that you do not aspire to “be Spotify”, but rather “be like Spotify”.  Start with a basic method/lifecycle (recipe), then spice it up with the help of proven strategies from the DA Toolkit (ingredients).

Become your own Spotify or Menlo, not somebody else’s.

Thoughts?

Please don’t call yourself a “Disciplined Agile shop”.  It is the kiss of death.  I was recently having a discussion with a client about visiting them on an upcoming visit to the UK.  At one point in the past they had proudly declared themselves a Disciplined Agile “shop”.  The senior exec that I spoke with told me “We have moved on now from DA to SAFe”.  Upon further discussion he admitted that SAFe is being used on just a few initiatives, but that they had sent lots of people to SAFe training.  The inference seemed to be that since they had previously taken DA training, but had now taken SAFe training that they have now changed “shops”.  Ironically while a lot of budget was committed to SAFe training and related consulting, most of the work done at this organization actually used other agile and lean lifecycles such as Scrum and Kanban.  You know, DAD stuff.

Why is it that our industry has an obsession with labelling themselves as a type of “shop”, when the reality is that they will likely use a variety of approaches depending on the context? You could be building something from scratch, extending a solution, or implementing a commercial off the self package.  You could be in a straightforward situation, or building defence or life critical systems.  Our industry has become extremely fragmented, with organizations trying to put themselves in a certain box such as Scrum, SAFe, Scrum/XP, LeSS, DAD, Kanban, Spotify, and it goes on and on.  So let’s stop doing this.

Unfortunately, Disciplined Agile (aka DAD) has gotten lumped in with scaling frameworks such as SAFE, LeSS, Nexus etc, when the reality is that DA is not a purpose-built framework for scaling situations exclusively, like a true scaling framework.  It is, rather, a rich and flexible toolkit than can be used to apply fit-for-context strategies for your unique situation for initiatives of all sizes and types.  If you need to apply them at scale, you can.  But our preferred approach is to descale where possible rather than apply a prescriptive recipe to a large and risky problem.

When we take a closer look at different types of shops, we see a lot of MethodBut.  For example, ScrumBut is where teams use Scrum but they don’t do retrospectives or some other ceremony.  Or teams use SAFe but management doesn’t buy in to doing quarterly 2-day big room planning sessions.  Practitioners in these “shops” are ostracized and may be excommunicated from their religion for not following one of their prescribed ceremonies.  Disciplined Agile’s core principles include context counts, choice is good and pragmatism.  While we believe that skipping parts of a method early in your adoption is likely a mistake, as your teams mature and understand options that can make them more efficient we support the idea of being freed from the “method prisons” (as described by Ivar Jacobson) so that they can optimize their WoW (Way of Working).  This essentially is why the DA “toolkit” was created.  It contains hundreds of strategies to help you to make better decisions on your journey to high performance agility.

As you can see from the diagram, regardless of what framework or method you are using, there will likely be strategies that supplement your approach which are not described in the method recipe(s) that you have chosen.  DA is a toolkit of ingredients, to enable you to be a better chef.  If you don’t know what is in the pantry, and which combinations will delight the unique preferences of your guests/stakeholders, then you probably won’t meet your potential as a Michelin Star Chef.

We have come to realize that the methods/framework industry is a moving target.  Waterfall shops, then RUP, then SAFe, then….?  There will be more frameworks, indeed it seems that we learn of a new one every few months.  As consultants seek to differentiate themselves, and have something new to sell, or organizations fail in their agile adoption and look for the “next big thing”, new frameworks/recipes will continue to emerge, with related training programs and certifications.

Regardless of the recipe, the main ingredients for them don’t change that much.  Yes, new ingredients emerge, such as mob programming, UX practices, WSJF, etc.  But generally accepted fit-for-context principles tend to last.  Disciplined Agile is an agnostic approach to solution delivery.  A rich toolkit to help you to make better decisions, leading to better outcomes.

At Disciplined Agile, we are beginning to make a concerted effort to separate ourselves from the toolkits, as we really shouldn’t be competing with them.  It is not DA or .  It should be DA and .  So our recommendation is to take a DA workshop to expand your pantry of ingredients, and learn how to be a better cook. Or a good starting point is to read the Choose your Wow! book (Ambler/Lines).  But please, don’t call yourselves a “Disciplined Agile shop”.

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.

We are excited to announce that the inaugural DA Day virtual conference is taking place May 15th.  Call for presentations is open until April 2nd.  We are looking for short 15 minute presentations on a variety of topics. If you would like to speak on a different topic please feel free to submit it anyway as we may adjust the topics based upon the submissions received.  Share your experiences with the community regarding how DA has benefited your organization.  Get your submission in today!

Attending is an excellent way to attain all of your annual professional development credits in one day.   We will also be providing a sneak peak into a new Disciplined Agile tool to make DA easier to use and learn which will be available to members in good standing.  We are very excited about this application and we think that you are going to love it.

So join us! It promises to be a fun and informative day.

More information here…

Mark & Scott

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:

• 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.