The concept of “team” is at the heart of Scrum. We bring work to a team. We say “software = team”. We structure our organization around teams. We focus on the team because you can get so much more value delivered with a team if just have a group of individuals. More than that as the team learns how to deliver value, they accelerate. The impact of this on value delivery is probably bigger than you think.
Jeff Sutherland recently released "Scrum: The Art of Doing Twice the Work in Half the Time". We all know there that the difference between, for example, an average programmer and a great programmer, is about 10X, and that this kind of factor is generally applicable. To quote from the book:
“… in a Yale study, the fastest students outpaced their slow compatriots by a ratio of 10:1. They were ten times faster, and they got just as good a grade. Ten times faster is pretty dramatic, right?”
Continuing
“If you look at teams instead of individuals, you see something interesting. There are studies that looked at some 3,800 different projects, ranging from work done at accounting firms to software development for battleships to tech projects at IBM. The analysts didn’t look at individual performance data, but rather team performance data. And when you examine how the teams did, you see something surprising. If the best team could perform a task in one week, how long do you think it took the worst team? You might guess the same ratio as was observed at Yale—10:1 (that is, the slow team took more than two months to accomplish what the fast team knocked off in a week). The actual answer, though, is that there is a much larger difference in team performance than there is in individual performance. It actually didn’t take the slow team ten weeks to do what the best team could do in one week. Rather, it took them two thousand weeks. That’s how great the difference is between the best and the worst.”
“So where should you focus your attention? At the level of the individual, where you might be able to get an improvement of ten times if you can magically make all your employees geniuses? Or at the team level, boosting productivity by an enormous magnitude even if you merely make your worst teams mediocre? Of course, aiming for mediocrity will get you just that. But what if you could make all your teams great?”
The question then becomes “what are the conditions that will help teams perform better?” I recently came across "Not so Agile: 9 ways that companies do Scrum wrong". The article is based on Jeff Sutherland - Teams That Finish Early Accelerate Faster, a paper about a set of common patterns, backed by research, that will help teams improve. The patterns are:
Where I work we use a number of these approaches. But we also still find ourselves slipping back into old habits. Sometimes we still focus more on individuals and less on teams when we think about how to improve things. But the worst one I see is the idea that we there is no problem with over-committing each and every Sprint, that an over-commit represents a stretch goal and that is somehow “good”. We've talked about this in the past - see What Is Wrong With 100% Utilization Thinking?. The principle of “teams that finish early accelerate faster” continues that discussion.
This paper will help you understand the impact these patterns have on how effective your team is. If you review the paper (no ads, more “why”) or the presentation (shorter, but with ads and less “why”) with your team I expect you'll generate ideas that will improve things.