Self-Selecting Teams: Does Your Group Mature Enough?
I have heard about the concept of a group that gathers and decides what to work on and whom to work with, while using minimal predefined constraints (such as team size). I always thought that a team that is being built that way is actually born as a self-organized team. I knew it, but I never had the opportunity to apply it. Well, it is not completely true — I did have the opportunity, but I didn’t have the courage.
Unfortunately, last month we had deep cutoffs in our group as our main product was put aside. The 4 Scrum teams we had were not relevant anymore. We practically had to re-build ourselves around new products.
Our heads were down, our motivation was low, we had a vague visibility about our future, we were sorry about the people that we had to let go. This was the down side. On the other side, we were highly matured in our agile practices (the Scrum framework, Kanban and XP techniques), we were a cohesive group, we are innovative and highly skilled on the technology side, and we know how to get things done as a group.
I had a full trust in this group and in its ability to re-invent itself. I thought this would be the perfect opportunity to let the people re-organize themselves around new products. And so we did.
Self-Selection in a Nutshell
Self-selection is a multi-round process by which a group comes together, share product details, self-select into teams, and iterate until they have formed cross-functional teams that can deliver end-to-end.
How to Start
First step for me was to get educated on the topic. I read posts on the subject. Fortunately, I have ran into a great post by Amber King and decided to contact Amber via email. We have exchanged a few emails which gave me some tools and gave me the confidence to proceed (thank you Amber!). I have also contacted an Agile coach that I highly appreciate (Danko) which gave me the final push.
With this knowledge in hand I have started to talk with my Agile Guild forum (a working-group dedicated for Agile adoption and Kaizen). The feedbacks were skepticism and suspicious on the ability to make it happen. They raised questions such as: what if all the engineers would select the same product? what if the people won’t create balanced teams? what if no one would like to cooperate?
Perfectly expected and reasonable reactions. The way I chose to tackle that was by bringing examples from the past where we had similar doubts:
- Estimating tasks as a team: what if the team won’t cooperate and would like the relevant specialist to estimate alone? how the junior engineers be able to estimate?
- Managers do not assign tasks: what if the engineer won’t choose the right task for her? what if 2 people will fight for the same task?
After we have talked it out in the Agile Guild forum, we were ready to approach the wider group.
We have gathered the group for 3 back-to-back 45 minutes sessions (15 min break in between). The sessions were held by stakeholders of the new potential products.
We have prepared 2 white boards, on each:
- The product name
- Empty space for the Scrum Master name: we decided we want to let the team the freedom to re-select Scrum Masters
- Empty space for the Scrum Product Owner name: in one of the products we had local Product Manager that agreed to become Scrum Product Owner. On the other product, we didn’t have anyone.
- Empty space for the Scrum team members.
- List of skills required for developing the product: this wasn’t a prerequisite to become a team member, just for awareness which skill set would have to be learnt.
On top of that, there was a circle with the title “I do not have a team” and sticky notes of all the people names.
We have gathered the group for 2 hours for the self-selecting team process, according to the below agenda:
- Products overview (30 min): products overview refresh
- Process introduction (15 min): explaining the “game”. We need to gather around 2 products. Only 2 rules apply: 2 teams in the size of 5–9, team should be able to deliver end-to-end (cross-functional).
- Self-select round #1 (15 min)
- Break (15 min)
- Self-select round #2 (15 min)
- Selecting Scrum Masters and Scrum team name (10 min)
- Self-select Guild (10 min): one of the sessions in day 1 was about innovation that required working-group to brainstorm it, hackathon it and finally POC it (Proof Of Concept). Therefore, we opened up a Guild for people to volunteer (in parallel to their role as Scrum team members).
- Next steps (10 min): high level review of the next steps, such as when and what would be the starting point of the teams.
The bottom line is that 2 cross-functional teams were created successfully, there was no management command-and-control approach to solve their conflicts throughout the process, there were no sticky notes left in the “I do not have a team” circle.
It was a pretty amazing experience to see how the people formed the 2 teams. A few anecdotes from the process:
- The session that took the longest was selecting the team name. I was very amused by that.
- After the cutoffs, only 2 Scrum Masters left. Both of them wanted to be part of the same Scrum team (they were interested in the same product and technology). The Scrum Masters asked the group whether it would be acceptable if a person on one team would serve as a Scrum Master of the other team. The group voted and rejected it.
The next step was for the Scrum Masters to solve the conflict, resulting one of the Scrum Masters stepping aside, respecting the other Scrum Master for her longer experience in the role. I was proud of them.
Although this was not an easy action for the Scrum Master to do, I bet the she feels better then a case where a manager would have forced her to take that decision.
- The other team remained with no Scrum Master. The team selected a Scrum Master by itself.
- After round #1, the teams violated the “end-to-end delivery” rule — on one of the teams there were no people with skills of testing complex deployment (required for the product end-to-end delivery). I have raised that point to the group and requested the group to solve it. The technical leader of the testing domain stepped forward and moved his name to the other group. This was an humble move. All appreciate it, especially the other testing engineer that remained in the original team. Again, I was so proud.
- During the process the teams already started to talk on their next steps, how they will educate themselves, who should they approach next, etc. It was without any management intervention.
In the day after, the people started to push things forward with no leadership involvement. It was amazing to see — finally a true self-organized team. Wow!
Bring It All Together
It was an empowering experience for all of us. All the things we were afraid of, didn’t really happen. On the contrary, the people showed maturity and respect for each other along the process, even during conflicts.
Self-selecting teams is definitely one of the best ways to form self-organized teams. Agile is about people, not about processes, not about tools. Invest your energy in the human aspect. Trust your people and good things would happen.