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.