Setting up a development team
Hi! In the scrum guide I didn't find an answer for a quite important question - who should decide about who should be in which team and how the teams should be large - when talking about 100+ developers... Are it developers themselves, who decide? Or should it be done by PO/SM? Thanks for advices.
you are right, the Scrum Guide covers the development, but not the team building. This is a complementary practice and described "elsewhere", e.g. in the book "The enterprise and Scrum" by Ken Schwaber.
The Scaling Scrum approach is actually to bring the 100+ developers in one room and give them the task to build teams of 3-9 people. This supports self organization and puts responsibility where it belongs. You can help them a lot by presenting the Product Backlog and other useful context information.
Definitely not Scrum Master who chooses who should be in the team as he is not a Project Manager.
Product Owner can choose and structure the team composition.
Ideally though the development team self-organise and form the team composition. As an SM, I've pushed it back to the team to form themselves quite many times :-)
It usually is better to get the development team self-organize and form different teams. PO/SM ideally do the tasks but sometimes it is better to leave the decision on the development team itself.
Figuring out the difference between team management and scrum leadership can be delicate, and it sounds as if you've hit on one of the areas where the two sometimes overlap. Organizing a large collection of developers into productive teams isn't easy.
One of the advantages of Scrum is that the team organization isn't something that has to be permanent. Unless the organization insists that each developer commit to one team and never shift, the ability of teams to learn and adapt is a very helpful. At the retrospective for one sprint, the team may realize they need a developer with a different skill set, and reach out to the organization to bring someone in. Or a developer may find a strong interest in another team's project and move to that team.
Managers are responsible for keeping track of the workers and making sure everyone is engaged and productive. Scrum masters can help by encouraging participation and transparency, so teams can learn and adjust as their needs become clearer. Product owners may be able to provide some guidance, but the decisions should rest with the managers, and be informed most strongly by the team's own self-reflected needs.
I hope that was helpful. If your situation is very different from what I described, I'll be interested to hear how you approach it.
I remember this question appearing in my certification exam. In theory, 100+ developers should self-organise and form their own teams. However, based on my experience and in practice, I think this is very difficult to achieve. I've managed software delivery teams of 200+ people scattered across the globe and hoping that they would self-organise and form their own teams didn't seem like the most practical idea. Co-location of teams nowadays is becoming more and more difficult with cost restrictions and customer demands. For a one-time event, it is also very expensive to fly all 200+ people and put them in the same room. At the end of the day, theory has its place in this world and we should know when we should be taking it with a grain of salt.
Agree with RJ. Of course, only developers should self-organise and form their teams. But in reality we are facing with a little problem: it is very hard to guess correct teams at the 1st attempt. Because by Development Team we mean not only developers, but also analysts, designers, testers, etc. And just imagine the group of more than 100 workers who are trying to create teams.
In the book 'Software in 30 days' by Ken Schwaber and Jeff Sutherland , there is a line on page 58 Chapter 5 "The First task for the scrum master is to find developers to form the development team".
I am still confused here. Does scrum master plays any role in forming the development team or am i misinterpreting the line.
A Scrum Master might have a hand in facilitating such things, in so far as the service includes planning Scrum implementations and leading the organization in Scrum adoption.
As @Ian says textbook is Scrum Master facilitates which is what you will find on Scrum Master certification exams. But I haven't actually seen that in action. My experience has been that the Development Manager (or whatever title you use) will be the ones that decide which Developer lands on which team and then all of the Developers on that team will end up reporting to the same Development Manager. I have participated in a "restack" activity where Developers were given the opportunity to change teams based on their skillls and the identified work in a Product Backlog. But even in that case it was all dependent on management approval.
Reality often interferes with teams being truly self-managed. And even though Scrum does not recognize or mention a "manager" role, corporations still want to have management structure. Even scrum.org recognizes that and their Professional Agile Leadership certification provides guidance on how management can actually improve agile implementations.
I have participated in a "restack" activity where Developers were given the opportunity to change teams based on their skillls and the identified work in a Product Backlog. But even in that case it was all dependent on management approval.
And this can still be very motivating to developers; particularly if it offers them a greater level of self-organization than they've had in the past.
I am also aware of cases that allow an even greater level of autonomy.
One option is to give developers guidelines that they should keep within, but then otherwise leave them to choose who is on which team. As long as the guidelines are followed, there is no need for management approval. The guidelines could be things like:
- "Each team has the following competencies…"
- "Two senior developers on each team"
- "Everyone will get a place on a team"
- "Each team must be the same size"
- "If developers are unable to choose teams within these guidelines, the manager will decide"
I also recommend this post by Jurgen Apello on the membership Agility Scale: https://blog.agilityscales.com/team-membership-controlled-or-self-organ…
I believe SM can help in facilitating teams building activity.
PO should share the product vision and explain about product backlog.
Based on the PO explanation, teams should self-organise themselves in the best possible way, of being cross functional to avoid any inter teams dependencies, to achieve Product vision.
In case there is IT manager or Functional Manager available, He/ she may suggest in teams composition based on past experience but let the teams take final decision.
In his book, The Enterprise and Scrum, Ken Schwaber mention two contradicting practices:
First, he answered the legendary question:
How do I organize my people into Scrum teams?
The Product Owner and ScrumMaster are the first people on a Scrum team. They are responsible for selecting the Scrum development team members. To optimize the productivity of the team, the developers are selected based on three variables:
People who have successfully worked together previously
People who understand the product or business domain
People who know how to use the selected technology
The team is also selected based on what constitutes a "done" increment. For instance, if user documentation is part of an increment, the team should have a technical writer.
Then he mentioned a story about Woodgrove Bank, and how they only succeeded when Jack and him let the developers self organize themselves:
This meant that they were to come up with the best team structure and internal processes for developing Teller4U using Scrum.
It's pretty confusing for exam takers, since we all know that there's only one correct answer for the exam, however, in real life there could be multiple answers depending on the situation.
I think Scrum.org should give clarification about how this question should be answered in the exam!!
Nice feedback folks! This will save my day! :)