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?

For those of you who are Star Trek fans you’ve likely been seeing ads for this t-shirt on your social media feeds.  It is an apt metaphor for the empirical approach that we take with Disciplined Agile – we regularly run studies to explore what is actually going on out there on agile teams, we gather data, as opposed to pouting some of the wishful thinking (spreading lore) that we often hear from consultants and vendors.

We are currently running an agile mini-survey of only 6 questions, so this will take you a few minutes at most to fill out, exploring some important issues about agile adoption within your organizations.  We hope that you choose to invest a few minutes of your valuable time to fill it out, and thank you in advance for doing so.

What Will We Do With the Results?

As you already know the surveys that we run are completely open – We share the source data (without identifying information), the questions as they were originally asked, and a Powerpoint deck summarizing our interesting findings after the survey has closed.  In fact, we have the results from dozens of previous studies posted at the IT Surveys page for you to take a look at.

We also write blogs discussing the results.  For example, for the 2016 Agile Scaling survey that we ran in November, we published several blogs:

• Can you outsource and still be agile?
• Do agile teams take on hard problems?
• Do agile teams face regulatory compliance?
• How “whole” are agile teams in practice?
• How geographically distributed are agile teams in practice?
• How large are agile teams in practice?
• Do agile teams pay down technical debt in practice?

Recently, we’ve created a new infographic summarizing the results of the study.  If you click on the thumbnail below it will take you to the page where you can download a high-resolution PDF of it.  This infographic is only available to members of the Disciplined Agile Consortium (DAC).

Where Can You Get the T-Shirt?

If you’re interested in the T-Shirt, it is a time limited offering on Teespring.

The quick answer is no, that’s an incredibly bad idea.

We ran a study in February 2017, the 2017 Agile Governance survey, to explore the issues around governance of agile teams. This study found that the majority of agile teams were in fact being governed in some way, that some agile teams were being governed in an agile or lightweight manner and some agile teams in a traditional manner.  See the blog Are Agile Teams Being Governed? for a summary of those results.

The study also examined the effect of governance on agile teams, exploring the perceived effect of the organization’s governance strategy on team productivity, on the quality delivered, on IT investment, and on team morale.  It also explored how heavy the governance strategy was perceived to be and how well it was focused on the delivery of business value. The following figure summarizes the results of these questions.

Here are our conclusions given these results:

1. Agile governance helps agile teams. There is a clear co-relation between an agile approach to governing agile teams and positive results such as improving productivity, increasing quality, spending your investment in IT wisely, and improved team morale. This is what we believe the goal to be, to help the people being governed to be more effective and successful.
2. Traditional governance hinders agile teams.  There is a clear co-relation between traditional approaches to governing agile teams and reduced team productivity, reduced quality of output, wasting IT investment, and decreased team morale.  We believe that these results are the exact opposite of what you hope to achieve with your governance strategy.
3. Agile teams should be governed in an agile manner.  This follows directly from the previous two conclusions.  It should come as no surprise that your governance strategy should be well-aligned with what it is being governed.
4. Traditional governance strategies likely hinders traditional teams too.  We didn’t look into this issue directly, but our experience has been that traditional governance tends to be more of a hindrance than a help to traditional teams as well.

When we work with organizations to help them to adopt agile ways of working, we often find that they are running into several common challenges when it comes to IT governance:

1. They have both agile teams and traditional software teams.  This is because it’s a multi-modal world: You will have some teams taking a traditional approach, some an agile approach, some take a lean approach, and some are even skilled enough for continuous delivery.  Each team will follow the lifecycle that makes the most sense for them, and as a result each team should be governed by the approach that best suits the way that they are working.  To do anything different would be to hinder the teams, and that isn’t what good governance should be about.
2. There is a desire for a single approach to governing software teams. This makes sense on the surface because it would simplify your overall governance strategy, thereby making things easier for the people doing the governing.  But, as we’ve learned, this results in negative effects in practice.  Your governance strategy must be flexible enough to support the range of teams being governed.
3. The governance team is struggling to understand agile.  Your executives and middle management need education and coaching in agile and lean just like the people on your software team do.  It is naive to expect your governance people to devise a governance strategy for agile when they don’t really understand the implications of agile to begin with.

For agile to succeed in your organization the way that you approach IT must evolve to enable and support it, and this includes your governance strategy.  Reach out to us if you would like some help in addressing this important issue.

Related Reading

• Lean IT Governance
• Governing Agile Teams

For the major of teams the answer is yes.  We ran a survey in February 2017, the 2017 Agile Governance survey, to explore the issues around governance of agile teams.  As you can see in the following diagram, 78% of respondents indicated that yes, their agile teams were in fact being governed in some manner.

We also asked people about the approach to governing agile teams that their organization followed.  As you can see in the following diagram, a bit more than a third of respondents indicated that the governance strategy was lightweight or agile in nature.  Roughly the same indicated that their agile teams had a more traditional approach to governance applied to them, and one quarter said their governance approach was neither helping nor hindering their teams.

Governance tends to be a swear word for many agilists and they will tell you that governance is nothing than useless bureaucracy.  Sadly in many organizations this seems to be the case.    In the next blog in this series we will compare the effectiveness of agile and traditional strategies for governing agile teams.

Related Reading

• Lean IT Governance
• Governing Agile Teams

We are often told that agile teams should be whole, that they should have sufficient people, funding, and skills to fulfill their mission.  The idea is that this reduces the dependencies that your team has on others, enabling them to make decisions and to collaborate more effectively.  But, is this actually happening in practice?  Are agile teams truly whole, or do they still need to collaborate with other teams (hopefully productively) to get the job done?  Being strong believers in empiricism over rhetoric we decided to look into this issue.

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following infographic summarizes the findings from the question that explored whether agile delivery teams need to work with external teams or groups to get their work done – in other words, are agile teams truly whole or do they rely on others?  As you can see, 96% of respondents indicated that in practice their team had to work with one or more other teams, leading to the conclusion that very few agile teams appear to be truly whole.

One of the fundamental principles underlying the Disciplined Agile (DA) toolkit is that disciplined agilists should be enterprise aware – they should recognize that they need to collaborate with others outside of their team, that they should work towards a common organizational vision, and that they should strive to do what is best for the organization and not just what is convenient for them.  Given that agile teams are collaborating with others in practice, it is clear that this philosophy of being enterprise aware is important.

The following diagram presents the results from the survey question in greater detail.  You can obtain the source data, a copy of the original questions, and a slide deck key diagrams at the 2016 Agility at Scale survey page.

Related Posts:

• Can you outsource and still be agile?
• Do agile teams take on hard problems?
• Do agile teams face regulatory compliance?
• How geographically distributed are agile teams in practice?
• How large are agile teams in practice?