In this post, I will explore what makes a good Development Team in Scrum from an organizational perspective.
Great teams
When it comes to structuring the Development Team, the Scrum Guide tells us that the team is “cross-functional, with all of the skills as a team necessary to create a product increment” and that the team should be structured to “organize and manage their own work”. Finally, we learn that the team should have between 3 and 9 developers, to be able to contain all the skills required while not increasing management complexity beyond the level self-organization can casually deal with.
Over the past few years, I have helped some clients to improve their teams’ setup and structure, and found that there are more criteria that the Scrum Guide only hints at but never mentioned explicitly.
Have few dependencies
While Scrum expects the team to be able to provide the product increment on their own, corporate reality often sees products with a scope much larger than what a single team can produce in reasonable time.
You may have read about scaling approaches like LeSS, and their call for feature teams. Rare is the product, though, where splitting into features is possible the moment your start with Scrum.
To alleviate the situation, I look for a setup where inter-team dependencies are as few as possible. In an ideal case, this means that the team has one team to receive input from and one more team to deliver output to.
For work to flow, the team has to be independent from other teams. Define your teams so that their scope covers a large, uninterrupted piece of the value chain, and integrate technical concerns as much as possible.
That way, you will reduce the number of handovers both in planning and in the actual work done.
Stay together
In a corporate environment, projects start and stop all the time. Project managers vie for resources, eyes on the deadline, not on the social effects. For team members, this means that today’s colleague may be gone tomorrow – so each of them looks out for their own piece of work first and foremost.
When introducing Scrum in such an environment, I emphasize the twin values of stability and reliability.
It takes a stable environment for employees to benefit from investing in the team’s success rather than their own achievements. Team members learn to trust each other over time and start to co-operate. In a stable teams, members can learn each other’s abilities and preferences – and that’s what it takes to get better.
Reliability, meanwhile, means that team members are on the team, period. Splitting people between projects eats up time beyond the numbers in your spreadsheet, as it introduces interruptions in the form of urgent requests from outside projects.
Now, any corporation worth the name will have a complex resource distribution in place already, and you will be hard pressed to change it all at once. What to do?
Allot people to the product as much as possible, and encourage them to block fixed slots of time for working on the product. If necessary, suggest they turn off phones, chat and mail clients; empower them to postpone dealing with incoming requests till team time is over.
That way, their team can learn rely on them, and teamwork improves.
Learn from each other
Remember what the Scrum Guide said? “Teams organize and manage their own work.”
It takes a certain level of experience to do that, and I have frequently heard managers or Scrum Masters complain that their team is not yet ready for this level of freedom – and next coordinate the work themselves, trampling the sprouts of self-organization.
So, it takes experience for the team to self-organize, and it takes laissez-faire.
The best teams I worked with did not consist of veterans only, though, since less experienced team members bring two crucial factors to the team: By embracing their curiosity, they challenge long-standing practices; by working with several of their more senior colleagues, they foster communication.
So, when building a team, I look for a good mix of old hands and new to make learning happen and self-organization possible, while still having all the skills to actually build the product.
Make work flow
This concludes my thoughts about criteria to watch out for when building great teams:
reliabilty, stability, experience, cross-functionality and independence.
So, when you are next thinking about how to improve your team, just think “Teams R SEXI”, and you are well on your way:
Reliable
Stable
Experienced adequately
X-functional and
Independent
Mind, though, that these criteria are strongly skewed towards the organizational perspective and pay no heed to the more mushy, social criteria that are well worth considering as well.
What criteria do you apply to find your teams? Did you go at it from an entirely different angle?
I am looking forward to your comments.
