Empowering self-organising teams with self-selection

We’ve just allowed our teams to decide what they’re going to work on and who they’re going to work with. It was a big step but a necessary one and I want to tell you why.

Background

Over the last six months, we’ve been going on a journey to switch from component teams to building true cross-functional teams. We know that this is the right way to run our delivery organisation. We need to move away from separate teams looking after our core backend platform and our client applications – the strength of a self-organising, cross-functional team is well documented. Going into our first release planning session in December, we attempted to set up feature teams by having our team leads decide what skills were needed for each team and putting people into those teams. We went through team formation activities, built identities, named the teams and formed social contracts. But slowly, yet inexorably, those teams disintegrated and people re-aligned to their previous component identities.

The reasons the initial feature teams didn’t stick are many and varied but the problem was in no small part because of a lack of buy in from the people who’d been placed into new teams. Going into our second release planning session we went through another round of team choosing with the leads in a room and post-its on a wall. It really doesn’t make me feel comfortable – horse trading people between teams and second-guessing where a good fit might be. If there’s one thing I’ve learned throughout my career it’s that you can never predict accurately how another person will react to a change or fit in to a particular environment.

Squadification

Meanwhile, I was introduced to an article by Sandy Marmoli about a “squadification” day run by TradeMe in New Zealand. I immediately loved the concept but also never considered we’d ever get to do something so radical. When the time came to think about our third release planning session and the need to cement stable cross-functional teams the idea resurfaced. Perhaps this really could work – it’s different, it’s confronting but it might just work.

Preparation

The first step was to sell the idea to the leadership team. Everyone who was introduced to it had the same initial reaction as me – “sounds great, but really?”. The challenge for us was to work out the mechanics of running it in our world – what are the skills we need in each team? how will the work flow between teams? how will people react to such a change? what are the technology challenges we’ll face and how do we solve them? Over a three week period we held many workshops with a broad leadership group to design our structure, address the challenges and plan for the event that we came to call the “team fair”.

We worked up to the wire and just days before the fair we were dealing with existential questions about whether we were even going in the right direction. But by the day before we had all agreed on the principles, we had our product owners and iteration managers in place and we were ready to open up the selection to the teams. (We’d changed a little from TradeMe’s example by having iteration managers in place before the event – we know that our IMs have a big job to do to nurture and grow our teams and we wanted them to be in the frame as early as possible).

On the day

The day of the team fair arrived with preparations to our space well underway – each team had a corner where they could organise and visualise the progress they were making. There was some real creativity in the preparations and the PO/IM pairs put a lot of thought into how best to represent their team during the day. One of our teams even added some additional “madskillz” that each team member could nominate as their contribution to the team.

After a brief welcome and scene-setting talk, all the team members were invited to collect their photo (or have one taken if we didn’t have one ready-made) and were briefed on the process for the day. We walked through the mindset that we expected each team member to have during the day – one of the key statements reminds people that we’re all here to do what’s best for APDM.

Pitching and selecting

Once everyone had regrouped, the product owners and iteration managers had a couple of minutes each to pitch their team in front of the whole group – what flavours of features they would play, what cultural values their team stood for and a little about themselves. Our planned approach to rolling out the feature teams is to stand one up immediately and use it as a pilot to solve issues while the other teams continue largely in their existing component groups. For that reason we couldn’t say which features each team would be playing next; although this made it harder for people to distinguish between teams, it also helped avoid mad rushes of people wanting to gravitate around the “cool” features.

With the initial pitches complete, we sent all the teams off to circulate, meet the teams and assign their picture to a team. This went surprisingly smoothly with lots of constructive conversations and people considering both their own interests and those of APDM. While we knew that people might be uncomfortable in leaving teams they’d worked in for some time, we were excited to see people really engage with the process and explore new possibilities. We saw some people ending up in teams that we’d never expected them to even consider – in my mind that’s a real vindication of taking this approach.

Each team had a sheet of paper representing their team – the only two roles pre-determined were the product owner and iteration manager. All other team member positions were up for grabs. Importantly we didn’t set out boundaries for number of testers or number of developers with a certain skill – just a set of skills that were needed and a boundary on the number of people in the team in total. This gets people away from the mindset of being the iOS dev in the team or the tester for the team – instead it encourages them to think of themselves as a real team who have a number of varied skillsets to solve the problems they’ll be working on.

Review and playback

After 10 minutes, we asked each team to review where they were and what gaps they had. The main criteria to cover were the numbers in their team (we’d set a maximum of 9 per team) and coverage of all the required skills. Going into the day, each team had come up with a list of the key skills they needed in their teams (“hats”). They now needed to confirm whether they were comfortable with their ability for someone in the team to wear that hat. Each team then visualised their coverage. One useful visual tool was a traffic light matrix of the skills; another team used a graph of confidence from 0 to 100% for each hat.

Rinse and repeat

After the first iteration, we’d actually filled about 80% of the teams to completion; we had one major anomaly with coverage of systems and environments and a few less severe gaps in our development teams. After each team had played back to the entire group, we had time for another go round before lunch; that iteration didn’t solve our systems problem and left us with two development teams oversubscribed (by one person each) and one team undersubscribed with a number of missing skills. At this point it looked like one more iteration and some negotiations around systems might get us to where we needed to be.

After a break, we got everyone back in to attempt to solve the outstanding problems; at this point we started to deviate from our plan and took a longer timebox to try and wrangle some of the more stubborn problems. After about 45 minutes for the third iteration, we hadn’t seen any further movements and we were left with the same situation as at the end of iteration two. At this point, going into a further iteration didn’t make sense so we stepped in and gave the teams a prompt – either they could take an extra five minutes to solve it amongst themselves or we’d take it away and solve it outside of the room. Very quickly we came to a resolution on one of the oversubscribed and the undersubscribed teams by one person electing to move. We left the other oversubscribed team as one to take away and negotiate further with. We also needed to move to a separate, smaller session to come to a resolution on our systems and environment coverage.

Lessons learned and observations

So what did we learn through the experience and what would I do differently next time? Firstly, we learned that people will move in groups and will tend to follow their friends – even when they could be a better fit in another team. However, we also learned that people are generally willing to separate out if they’re given the space to communicate freely. The other lesson was that strong preparation and admin support has huge value. We had printed out photos of the whole organisation but left it to the last minute to confirm that everyone attending had a photo. We dodged this one by taking photos on the day but we could have been left with a delicate situation where some people turned up only to find they didn’t have a photo. The other big realisation for us was the benefit of having the iteration managers and the product owners paired up and ready to present together. This formed a stronger team kernel which other people gravitated towards.

Overall, the event worked well and the teams really bought into the idea and the process. We’re now in our team formation stage with a view to having all teams up and running in around 8 weeks. I plan to write a follow up post to review once the dust has settled and our new teams are in action.

Update: if you want to run your own self selection, Sandy has published a kit with all the materials you need.

Archives