Our first attempt at self-selection

This year I managed to float an idea I thought would not see the light of day for a while yet: I convinced my domain owner to let us try a team self-selection exercise. In the end, he and the rest of the management team didn’t need much convincing, and we were given the green light to start the process.

We relied heavily on the very comprehensive self-selection toolkit from NOMAD8 and pretty much followed it as suggested, with a couple of customisations to suit our context. The first piece of work was agreeing on our three missions (for three teams) which for various reasons led to some debate and much to-ing and fro-ing. The conversations to clarify the three missions proved really valuable and I think influenced some better decisions than otherwise would have been made if we hadn’t gone through the process.

Missions agreed we sat down and agreed what kind of skills (hats) would be required to deliver each mission end-to-end. We decided to extend this list to include capabilities that we did not necessarily currently have within the team itself (sadly, our organisation is still organised along components/technologies) to create awareness and hopefully improve cross-team communication. Once we had those, I compiled one slide summaries for each mission with the help of each Product Owner, and emailed them together with a modified FAQ to everyone who would be involved.

Before sending off the self-selection pack, we did also try to ensure every team member had had some face time to know about the new process we were trying. Most people heard about it during team retrospectives (when the question around ‘what happens next’ came up), but I did have to have some one-on-ones with certain team members who had missed out on such sessions for whatever reasons. Feedback was that people appreciated this: some people don’t enjoy finding out about stuff for the first time via email!

Once the missions were defined and the packs sent out, it didn’t feel like a lot of preparation was really required for the session itself. On the day I spent some time setting up the room, but otherwise from a facilitation point of view, everything was pretty much covered in the pack. People expressed various levels of nervousness and excitement leading up to the event, but thankfully everyone was happy to take things as it came and see what happened. I did have a detailed walk-through of the plan for the day with my Product Owners to ensure that they were suitably prepped on their role and involvement.

The session itself went really well. There were about 25 attendees so I’d booked the session for two hours. In the end, we only used just over an hour. Levels of engagement were high. We did about four rounds before stopping and there was a lot of good conversation and switching based on needs highlighted in each squad review. Making the Product Owner’s green/red vote on the viability of the team very visible also helped highlight a problem in rounds three and four: no matter how the teams shuffled, we didn’t have enough developers to create three effective teams. This was very visible to all and has subsequently led to the re-consideration of priorities in line with the capacity that we do have.

Feedback on the session in general has been good. The Product Owners were very happy with the outcomes of the session. Various team members said it was the most useful and best facilitated session that we’d ever run. Some did express the view that people generally ended up where their managers wanted them anyway so felt that we may as well have just decided on the teams in advance, but I’d like to believe that, even if people had been asked beforehand to select a particular mission, ultimately they still made their final choice/decision using their feet on the day.

Some take-aways:
1. The pack recommends sending information out at least a week in advance. I think this is very important, if only because it forces the Product Owners to commit to what their mission actually is.
2. Having conversations either one-on-one or with groups of people before sending out formal communications is important. It helps them get used to the idea and allows them to ask questions. Don’t be afraid of not knowing all the answers: quite often the answer is that it depends on what team forms on the day.
3. The pack also says this, but I’ll reinforce, because of all the unknowns due to not knowing how the teams will form, don’t expect to have new teams up and running from the very next day. One of our teams kicked off the following working day (with some team members handing over other work over an agreed duration), but another of our teams will only get going in a couple of weeks.
4. Don’t underestimate the power of physical movement. Ensure your stations are far enough apart that people have to physically move to join a station (and can’t hover somewhere in between). Having the Product Owners stand in their own ‘corner’ and then add a green or red sticky to the squad board after each round was also helpful (in our case all the Product Owners had a say in approving the team composition).
5. My biggest challenge was getting people to quieten down when we needed to end a time-box! Ensure you have some mechanism agreed for this up-front. The usual agile workshop “hand up and mouth shut” works well (if some people know what it means). Someone in the session suggested playing music in the background and stopping it when we needed to evaluate the squads: a bit like musical chairs. I thought that sounded quite fun 🙂

Have you ever tried to run a self-selection exercise before? What was your experience?

Sample Squad

 

Constraints to consider