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:
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:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
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.
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 framework 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.
Many people, particularly those new to agile, will tell you that agile teams must be small and co-located. That is certainly a smart way of organizing a team, but is isn’t required. In fact agile teams are more likely to be geographically distributed in some way than they are to be co-located. In practice, not theory.
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 graph summarizes the responses around geographic distribution.
The survey found that less than one-third of agile teams are near-located, where all of the IT members are either co-located or at least in a shared open space. Previous studies have found that this number drops to one-in-ten teams being near located when you also include primary stakeholders.
Don’t let anyone tell you that you can’t do agile with a geographically distributed team because others are clearly doing so in practice. Yes, geographically distributed agile is different than near-located agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery. The Disciplined Agile framework provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including geographic distribution. In fact, you may find our article around geographically distributed agile teams to be an interesting read.
During the first week of August we ran a mini-survey exploring whether or not teams have fixed iteration lengths. It was motivated by a question about the results of our Agile Cadences and Technical Debt Survey we ran earlier this year. Apparently the person was working on a team where their iteration length often shifted and he was wondering how common this was. I responded that it wasn’t very common and that instead the common practice was to not allow the iteration length to vary. He found this hard to believe and wondered why we didn’t have any data to back up that claim. So we decided to run a short survey to discover what is happening in practice. Over a one-week period we had 264 responses (thank you very much to those of you who did take the time to fill out the survey).
The following diagram summarizes the results of the third question that explored whether teams that were working with iterations kept the iteration length fixed. As you can see, the majority of agile teams (68%) that have iterations/sprints keep their iteration lengths fixed. Furthermore, for those teams that allow iteration lengths to vary it’s a rare occurrence (often the result of valid reasons, such as a holiday in the middle of the iteration).
The survey consisted of four questions:
- The first asked if the respondent was working on an agile team (if not they exited the survey)
- The second asked how long iterations are (the majority said two weeks or less). If the team didn’t work with iterations (such as lean teams or continuous delivery teams) or if the respondent didn’t know then they exited the survey.
- The third question asked whether the length of the iteration was fixed (see the chart above).
- The fourth question was presented only to people who said that their iteration length could vary. It explored the reasons why this was the case. I will summarize these results in a future blog posting.
I will post the survey details at the IT Surveys page towards the end of August. This will include the questions as asked, the answers as provided, and a short slide deck summarizing the results. Normally I’d do that right way but I’m on vacation right now and shouldn’t even have taken the time to post this blog (hey, I’m dedicated).
Are you guys able to quote any studies in your book on the increase in effectiveness that can be achieved by establishing permanent dedicated cross-functional teams as opposed to teams that get torn down and re-assembled for each project? I am looking for a solid industry study that is widely excepted. Our company currently has a mix of both types of teams and I am looking for some industry data to compare against.