Today while browsing through tweets I stumbled upon very interesting reading How to Form Teams in Large-Scale Scrum? A Story of Self-Designing Teams. I wish I read it a couple of months ago, before trying self-designing in my teams.
Idea
Last year in November a need for a new product team in my department emerged. It was almost impossible to hire developers for whole new team quickly: I select people carefully, everything must be perfect (technical skills, cultural fit, chemistry, etc.), everyone who is interviewing candidate should say Yes! Moreover to tell the truth, the pool of highly skilled candidates was not very big back then. So the only way to speedup new product’s development was to reorganize my department and make 3 teams out of 2 (and make one team fully dedicated to new product).
And guess what? I decided to let guys select by themselves what team do they want to work in.
Setup
I took some time preparing for self-designing session. First I consulted with my manager, together we thought about various scenarios and risks we might face. We talked over possible reaction and results. Then together with Product Owners we defined what these three teams would be responsible for. I asked guys to prepare short presentations about their products’ upcoming features and challenges. I even made a personal survey asking my friends-developers outside work how would they feel if one day their manager came and asked to form teams by themselves. I got all positive feedback and support from everyone I talked about this experiment.
How it went
Everything started as in Craig’s and Ahmad’s article. I invited all participants in one room for 2 and a half hours. Overall there were 17 attendees: 12 team members, 3 Product Owners, my manager and myself.
I presented the idea of this whole session and the desirable output: to form 3 teams in 2 hours by themselves, with SM and QA named in each team. In addition they could take a possibility to hire up to 3 new developers with any skills they considered missing.
Then I shortly introduced what product each team would be responsible for in order to get the idea of what skills would be needed in each team. I spent some time explaining the reasoning why we needed a team dedicated for new product. This was followed by short presentations from each Product Owner. After the introduction part I left the room and promised to come back in 2 hours.
What happened after I left was exactly the same as in this article’s cycle one - everyone chose his current team. So at the end we had two old-new teams with same members as it was before the session and new product taken by one of them. That was their decision.
Somehow guys took this experiment exactly the opposite way I expected. They seemed stressed, some of them were even angry and blamed me of not doing my job and putting my responsibilities on them. Overall the atmosphere was unpleasant.
We ended up the session by declaring the decision made by team members: two teams, same compositions, slightly different ownership of products.
What was wrong
The first and in my opinion the strongest mistake - I left guys to form teams without any facilitator. Now as I read this article I see how it is important to have someone to run the session, to guide and coach. I think if there were facilitator it wouldn’t end up after the first cycle.
The second drawback - this session came as a surprise for everyone. I should have prepared people for such change in advance, let them live with this idea for a couple of days, let them think carefully what they really want to do. It is always hard to push yourself out of the comfort zone. Changing team and product you work on for several years is tough. You should have strong will and desire to improve in order to embrace changes. And you have to be ready for that.
Despite this unsuccessful experiment I still think that teams may be enabled for such kind of decisions. I’ll definitely repeat this someday in the future when there is a need to reorganize.