Earlier this year, while consulting as an Agile Coach, I was involved with an interesting experiment. The experiment asked individuals to self-select into software development teams. Team members would be allowed to choose what products they worked on and who they worked with. The event was called Teamification Day.
I had never done anything like this, so I was excited and also interested to see the process and results. A lot of effort went into preparing for the event. The Agile Practices group – which I was part of – took the lead by designing the event and communicating information.
Each work package (epic or larger) had an assigned Product Owner and dev lead. The PO and dev lead worked together to design a presentation that explained their work package. This would be used on Teamification Day to educate and recruit people to their team.
Each pair also had a board that would later be used to indicate interest in a specific work package and would eventually indicate the final roster for that team. This board contained valuable information, such as:
- Standard constraints: The required makeup of teams (ex. 3-5 devs, 1 PO, 1 Agile Coach)
- Team is able to deliver end-to-end solution
- Where the team would be co-located (Chicago, for example)
- Team information: Name, value stream and work package
- Skills desired: Ex. One FE dev, two BE devs, UI/UX and also specific knowledge if necessary (Elastic Search, Java, Kafka, Nifi, Selenium, etc)
- Team adjustments: After each round, teams would use this space to identify what they still needed or what they have too much of
The Agile Practices group created the boards and then had a couple of dry runs to see how it felt and what issues we thought needed to be addressed. There were a handful of issues and ideas – ranging from ‘will the areas be too chaotic with so many people and so many questions?’ to ‘do we need flags to indicate the team’s location, whether the team is fully formed or not fully formed?’. The goal of this event was to allow roughly 200 people to learn about 25 different teams, ask questions and then choose their own team – so we knew there were going to be obstacles.
On the morning of Teamification Day, there was breakfast – along with excitement and anticipation – in the ballroom. After some short messages from various leaders, the Curiosity Market was opened. The Product Owners and dev leads stood by their booths and pitched their work packages – explaining what they would be working on, why people should be interested and exactly what kind of team they were looking to form. The room sort of resembled a science fair.
Since there were so many teams, several rounds were run and the time slots were staggered – with some presenting and others taking a break – to give everyone an opportunity to get the information they desired. As is typical with many Agile events, the law of two feet was encouraged to allow people to move around and do what made the most sense to them.
Following the Curiosity Market was lunch. The Agile Practices group discussed how the morning played out and went over last minute coordination details for the afternoon. We discussed that despite (what we perceived as) a successful morning, the afternoon would be more complex. Anything could happen as people started choosing teams. However, we had discussed possible scenarios and were armed with techniques to facilitate various situations.
As the self-selecting portion kicked off, some teams were formed quickly, as there were some individuals and groups who had previously discussed where they would like to be. The rule was that anyone could put their name on any team board – even if that team ended up having 15 people who wanted to be on it. After a couple of rounds, most of the teams were squared away, but there were some teams who had too much of one skill and not enough in other areas. The event facilitator asked teams to call out what they needed – for example, ‘we need two front end devs’ or ‘we are short one tester’. At that point, teams would know where the gaps existed and could go discuss and recruit people to help complete the team.
After a little more discussion and pitching from Product Owners, all the teams were formed.
Post team self-selection
Months after the teams self-selected, things seemed to be going very well. Individuals seemed happy with how things turned out and in a recent survey, the self-selection process was called out by many as a positive. There were only a handful of people who did not get one of their top choices and providing the freedom to choose your own destiny was appreciated. Of course, not everything is or was perfect – there were a couple of people who have been traded to help better align teams and when teams moved on to different work packages, the work was not the same, which was a little disappointing for some.
Another interesting idea that has been rolled out are job boards. A job board is a place where teams can advertise that they are looking for a skill and others can view the board to see what team they would like to join. There are certain constraints – for example, people need to be on a team for 3 months before moving – but people will also be allowed to switch teams if they’d like.
Overall, I am grateful to have been a part of this self-selection Teamfication experiment. By most measures that I see and hear, it was a success. It provided the freedom and autonomy for people to choose teams for themselves, which conveyed a message of trust and accountability. Self organization was center stage in this experiment and it proved, to me, that empowering individuals can be a strong force.