How should we form scrum teams as our organization adopts scrum?
Deciding how to form teams, and which people should be on which teams is the work of management. Of course there are many ways management might choose to do this. One of the most effective ways I’ve found to figure out roles in a scrum transition is to let people decide for themselves! This may sound shocking (who lets employees or even worse, contractors, decide what role they will fill), but we’ve seen it work very well. The operative word is transformation. The power in scrum comes from its focus on self-organizing teams producing value rather than individuals doing work.
Start with some good training for everyone so people have a shared understanding of what scrum is, what the roles on the team are, and how adopting scrum will help the organization create more value and a happier healthier work environment. I’ll shamelessly recommend Agile Learning Labs’ Certified Scrum Master workshop for this step. 🙂 .
Next we assure everyone that they will still have a job and their salary. This might seem like not a big deal – but think about it. The roles in scrum aren’t a 1 for 1 match with traditional project structures. Maybe it’s good to say that again. The roles in scrum are not a 1 for 1 match to traditional project structures. That’s the point – if this doesn’t get addressed, what often happens is that roles stay the same with new titles and no real transformation takes place.
So after everyone is assured they still have a job and a salary, we can talk about what roles will be needed on the scrum teams. Each team will need a product owner, scrum master, and three to nine development team members.
Product owners are concerned with the product and how it’s doing in the market.
Scrum masters are most concerned about the people and helping the people work together more effectively.
The development team consists of the people who actually create the product. This might include coders, testers, documentation specialists, or people who have whatever skills are needed to create your products. Developers are concerned with what’s getting built – the quality and building the right thing, the technology.
So I ask people: What is their primary concern? What gets them out of bed? Is it guiding the product? Is it guiding people and teams? Or is it building the product? It’s usually fairly obvious to them.
Finally – I ask them to organize themselves into teams of roughly 5-9 that can produce value (potentially shippable product) based on where they see themselves.
I tell them that each one of them has a main job of figuring out where they can produce value and that as a whole group we need to make sure that all the teams can produce value. Then I let them go. It’s a bit chaotic for sure – as people form teams and deal with making adjustments so each team can produce value. The teams choose or request scrum masters from the folks who have self-selected into that role.
Often teams form in much more organic and productive ways than if management had assigned people to teams. This is management putting its money where their mouth is when they talk about the power of self-organization. It sets the stage for people on the teams being accountable for producing value and being valued by the business for their contribution.
It can be a bit nerve racking to do it this way – maybe like jumping into a cold lake or jumping out of a perfectly good airplane – I think you’ll be happy if you go for it.