“Coming together is a beginning. Keeping together is progress. Working together is success.” –Henry Ford

Unless your IT organization still operates in the previous decade, chances are that you hear the term ‘Agile’ at your workplace, more often than you hear your own name.. Surprisingly though, very few teams teams actually talk about the agile manifesto principles. I talked to a few ‘agile experts’ about one particular item from the manifesto, which mentions “self organizing teams”, and they were almost unaware of what it meant.. The manifesto quote I am referring to is:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

While this post is not about self organization in itself, it would almost be meaningless if we don’t understand what it means..

Self Organizing Teams

The most concise explanation about self organizing teams, comes from the official scrum guide, which states

• Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
• No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” 
• Development Teams are structured and empowered by the organization to organize and manage their own work.

In short, self organizing teams are the ones which are capable, trusted and empowered to take their own decisions. Of-course, it is an incremental journey and no team/organization can become self organizing overnight, but all agile teams must strive towards some degree of self-organization.

At my current organization, we recently underwent a big restructuring of the development department. The goal was (is) to organize the people into small ‘agile’ ‘self organizing’ teams, with each having a specific focus area, to deliver value towards. With over 100 people to divide into dozen odd teams, managers had a big task at hand, to make sure all the teams were balanced with happy and motivated employees. That is when someone came up with the (strange at the time) idea of ‘self selected teams’. One month after, and it feels like it was the best way possible to create these new teams.

Self Selected Teams

One pre-requisite to having self-organizing team, is to have a group of people that function well ‘together’. A team which is in the ‘storming’ stage in Tuckman’s model, can never be productive, leave aside self organizing.

Most organizations, (that I have seen), while forming teams, don’t factor in the fact that we human beings are social creatures, and our output depends a lot on who we are working with…. later these organizations spend a lot on team building/bonding exercises (which are great by the way), to make sure people become comfortable with each other. But, why don’t we start from the other end. Why not let the people decide for themselves, who they want to work with. Why not have a team of friends, rather than make a team and then try and make them friends.. Why not have people decide what product/technology excites them the most, rather than others trying to judge what they are good at… That is what ‘self-selection’ is all about.

So, for a formal definition, Self-selection is a, guided and monitored, iterative process where people are allowed to choose the teams they want to be part of.

The process of Self-Selection

Prepare: Once an organization decides to try self-selection, a lot of preparation needs to be done, before the actual exercise. The target teams need to be well defined, with answers to at-least the following questions for each team

• What is the mission of the team
• Who will be the manager for the team
• Short/Medium/Long term concrete goals
• Product owner(s) responsible for the team
• Constraints
  • Max/min size
  • Expected competence mix (Seniority mix, competences required etc)

These facts about each team, must be advertised well in advance, to give people enough time to think/discuss about their priorities and decide where they fit best. Encourage ‘over the coffee’ conversations within the organization, to let people talk to their friends, to convince them to move to the same team.

Answer Queries: Once the information about the teams has been made public, lots of questions will come up. A lot of them about the teams, and lot more about the self selection process itself. So, along with the team information, managers must make it absolutely clear as to why they are doing this self selection exercise. It must be communicated that the idea is to have self organizing teams, and a first step in that is to let people work on what they want to, and who the want with.

Some of the people in our organization actually questioned if this exercise was due to the failure of the managers to come up with the new team structure, when the fact was, that the managers were already ready with a fallback traditional plan, in the worst case scenario of this self selection failing.

Execute: On the pre-decided self selection day, gather the organization together and have a board/wall area for each team ready, with the mission statement, and constraints for the team. Give one more chance to people to ask any last minute questions, and then let each member put up their name on one of the team’s board (using sticky notes for e.g.). At this stage, don’t ask any questions, such as why someone is selecting a particular team and definitely don’t suggest that someone would be better off in another team. Managers are there to answer queries, but not question anything.

Iterate: If, after the first iteration managers feel that some of the teams violate the constraints (size/competence), they may talk to various members (privately to try and tell them the importance of these constraints, and run the exercise again after a few days. Managers, for e.g., might explain how having a lot of senior resources in one team would lead to a weak another team, which will then not be able to fulfill its mission. At any discussion, make sure to keep telling the resources that ultimately it will be their decision, but guide them to think towards what is good for the company. That is why the definition of self selection mentions it being a  “guided and monitored” process.

Advertise: Once everyone (or most) are satisfied with the outcome, advertise the teams to the whole organization. While these teams too will need time to turn into self-organizing teams, hopefully they will reach there faster.

Risks/Pitfalls

While we were lucky to have a successful self-selection exercise, there does exist some risk that the process would fail in providing a functioning team model. In most cases, this would reflect a larger organizational problem, such as not having enough competence to fill all the target teams, lack of trust among employees towards management/product organization, or  ill-defined target teams. If, even after multiple iterations, you are not able to come up with a satisfactory team model, try and address the root cause, before trying the exercise again.

And as with everything, including ‘agile’, your organization might just not be ready yet, to take the plunge into self-selection. For e.g. if all the members of the organization are completely new, and don’t know each other, self selection would anyways be random, so it may not be a bad idea to form teams using ‘traditional’ methods… 🙂

So, guide your way to self organizing teams, starting with self selection

Posted on: 4th May 2017, by : AdityaBhushan