Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Using Self-Selection to Create Teams

Using Self-Selection to Create Teams

Leia em Português

This item in japanese

At one company self-selection was applied to redistribute people over teams. It provided the opportunity for developers to get involved in strategic decisions and understand the needs of the business. Using self-selection they learned that if you give people the power to take difficult and informed decisions, they will become motivated, no matter how tough the decision is.

Self-selection is described in the book Creating Great Teams - How Self-Selection Lets People Excel by Sandy Mamoli and David Mole. Earlier, InfoQ interviewed Mamoli and Mole and asked them to describe self-selection:

Mamoli: Self-selection is a way of letting people choose which team to work in. It is a facilitated process of letting people self-organize into small, cross-functional teams. It is the fastest and most efficient way to form stable teams and is based on a belief that people are at their happiest and most productive if they can choose what they work on and who they work with.

Mole: Quite simply, it is an alternative to the most familiar way of selecting teams in most businesses which is for several managers to come together and decide how teams should be made up. In defining a process and talking about the benefits of self-selection, we think we have not only provided a viable alternative but that when businesses try this way of selecting teams, they will see the incredible benefits and never go back.

Serena Caruso and Antonia Greensides, both Scrum masters at cr360/UL-EHSS, spoke about empowering teams to self-select at Agile Cambridge 2017. InfoQ is covering this conference with Q&As, summaries, and articles.

InfoQ interviewed Caruso and Greensides about how they used self-selection to create teams and what they learned along the way.

InfoQ: What made you decide to use self-selection for defining teams?

Serena Caruso: Due to department expansion and the need to increase the number of development teams, we were going through the process of deciding team allocation through numerous meetings with technical leaders and management. There was some pre-allocation of people into teams and for the rest it felt like picking sports team buddies at school; no one was feeling too comfortable with that.

Antonia Greensides: When we got asked to suggest an alternative solution, we considered using a basis on personality profiling but the approaches didn’t feel particularly in line with our agile principles. We figured "why reinvent the wheel?" and that someone somewhere must have approached this differently, so we started to do some research, looking into facilitation books and tried & tested techniques for team forming, until we found "Creating Great Teams" by Sandy Mamoli and David Mole.

InfoQ: How did you get management to buy in?

Greensides: Before even starting the book, we approached a development manager and advised that we’d found a method which we agreed would be a great way to form agile teams, empowering them from their inception, could we possibly consider trying this, or should we drop it right away?

Thankfully, the manager was prepared to consider alternate approaches and asked us to prepare a proposal to enable a decision to be made as to whether this could be a practical approach for us to try.

We both read the whole book, went through some referenced case studies, created a short PowerPoint and presented it to key influencers. We talked about the process a lot and followed up each conversation by sending a copy of the PowerPoint. As expected, there were lots of responses along the lines of "it sounds great in theory, but how are you going to ensure that it is a success?".

Caruso: To convince management, we had to guarantee the workshop would be designed so that business constraints would get addressed.

The "worst case scenario" was one of our strongest arguments; if agreement was not reached in the workshop, the "worst case scenario" was that we would have gained a good knowledge of what people want and how they work together, and it will become obvious to everyone the difficulty of making everyone happy and the need for a top-down selection approach.

While waiting for the thumbs up we didn’t keep twiddling our thumbs, we went as far as we could to get ready (from preparing the teams, preparing a list of FAQs, printing pictures and needed material), so when the business pressure to split the teams into more efficient units became palpable we made it happen within a week.

InfoQ: What did you do to introduce self-selection to the product owners and the teams?

Caruso: To get the product owners on board we ran the same pitch that was used for management, as it emphasized the way we were going to address business constraints, within the self-organised nature of the framework.

Greensides: Whilst the idea was being proposed to management, we were also floating the idea with the teams we work with – if they all hated the idea, there was no point pursuing it further. Thankfully we got lots of great feedback and willingness to try a new approach.

Caruso: Teams were quick to get on board as the alternatives were obvious: blind top-down management decisions versus a chance to decide your future work whilst getting the opportunity to understand and see with your own eyes why working in the team you had in mind might not be the best strategy for the business. Developers saw in the self-selection a way to be treated as adults, to be involved in real strategic decisions and understand the needs of the business.

InfoQ: How did the self-selection session go?

Greensides: We had done a lot of preparation and had read about how other organisations handled the challenges, but once the event started, we had no idea what would happen. I’ll admit it was a scary time for us.

The level of energy in the room was great until we faced the first stall. We realised that we had done lots of preparation to handle noise and arguments, but little to handle silence.

Caruso: The next move was our biggest mistake, management - yes, that’s right, we didn’t follow the book’s advice to keep managers out of the room - took the bold decision to chase the stall resolution suggesting that one of the developers should move from one of the teams to another team. Retrospectively this was a useful decision to get the ball rolling but it could have been handled differently, and it’s still remembered by the teams as a downside of the workshop.

Greensides: The workshop took around two hours to complete and we ended up with the desired result of redistributed teams. People found the exercise exciting, not because it meant a free choice for everyone, but because there was full transparency of why difficult decisions needed to be made.

InfoQ: What have you learned from doing self-selection?

Caruso: Follow the advice of those who have done it before! As mentioned, we shouldn’t have given management the temptation to jump in and we should have kept them out of the room.

If we decided today to run this event again, we would have a better plan to unblock stalls, and we would share it with the teams in advance.

We learnt that if you give people the power to take difficult and informed decisions, they will take them and they will come out motivated by that no matter how tough the decision was.

Greensides: When you find an alternative way of working, that’s different to the norm, even if you’re worried it might be difficult to make it happen, just go for it!

What’s the worst that could happen?

Rate this Article