Agile coaches David Mole and Sandy Mamoli recently presented a talk to Wellington's Agile Meetup group on their successful experience with team self-formation and a big-bang migration to a Spotify-esque Squad Model at Trade Me, one of New Zealand's largest online brands. You can catch them sharing their story again at Agile 2014 in Orlando later this year.
InfoQ spoke with David and Sandy to find out more.
InfoQ: Can you tell us a little bit about Trade Me as an organisation?
David & Sandy: Trade Me is New Zealand's biggest commerce site; you can think of us as New Zealand’s version of eBay. Trade Me started life as an auction platform 15 years ago and has grown from a small start up to a listed company with over 350 employees in Wellington, Auckland and Christchurch. We're actively involved in Property, Jobs, Motors, Dating, Travel and most recently insurance services too.
InfoQ: What were the issues which led to your need for re-structuring into self-organising teams?
David & Sandy: We reached a point about 2 years ago where we continued to grow but adding new people no longer meant getting more done, if anything we were slowing down. Without realising along the way, we had set up a web of dependencies where every person and project was reliant on someone else, where we had a large amount of handovers between professional groups and where we were constantly waiting for people to become available while they were still busy on other projects. That meant what should have taken a week, could take a year and the harder we tried, the more complicated it got.
InfoQ: What considerations brought you to choose an en-mass migration to Spotify's squad model over the lower-risk formation of self-organising and cross-functional teams in identified problem areas?
David & Sandy: We had two very volatile moving targets, our people and projects. Both were constantly in a state of flux and what we wanted to do was start by pulling people out of a complex matrix and putting them into fixed teams.
We had tried and failed with cross functional teams before (people were part of several teams at once, the teams didn’t include all the skills they needed and a handful of key people formed a bottleneck that the teams couldn't overcome) so this time we wanted to get it right and we were on the lookout for new terminology, when we saw Spotify's white paper we knew this could really work!
We didn’t really have problem areas, we had a company-wide problem with scaling. We had started out as a company with a very agile mindset but had begun to run into problems when our ways of working that had made us so successful with 50 people didn’t scale up to 350. So, there wasn’t really a particular part of Trade Me that needed change but an entire organisation.
InfoQ: What was your experience with getting top-level buy-in for such an ambitious transformation?
David & Sandy: It was tough if we are honest, there never was full buy-in but the great thing is that this is an organisation of trust and people tend to give you enough rope to try something new. Also, as the Head of Projects I (David) already had good relationships and a certain level of influence.
We also started on a small scale, implementing our first squad in a bright spot. This was a very tactical move and something suggested by our Agile Coach, Sandy Mamoli, who knew this would give us the best chance of success. We continued to add new squads, one at a time, in a very controlled manner for the next 6 months or so. This meant each new squad had our attention and we were able to help out where necessary. The slow growth worked really well for us and probably worked better than an upfront big-bang approach which may have led to chaos and not the smooth flow we were looking for.
At some point we realised though that we were going too slow. People started to be impatient and kept asking us when they could be “squadified”. We think they started to feel like second class citizens as they were excluded from something that obviously worked really well. At that point we had also seen the benefits of the approach and were absolutely certain that we wanted this across all of Trade Me so there was really no reason to wait any longer.
InfoQ: What was the initial reaction you received from the existing teams and would-be participants to the news that they would be restructured into self-determined squads?
David & Sandy: It's funny you ask that because everyone seems to go through the same pattern. It seems to follow a path of 'Nice Idea, that could be really cool' but then quickly progresses to 'Woah!!!' when people think we might actually do it. People then tend to throw a million reasons why it won't work, or 'What-If this happens?' scenarios combined with a shocked and slightly stressed look on their face!
Although people tended to come around when they could see that we had both a plan and good facilitation techniques. We wondered whether people reacted to the proposal in a similar way to the well-known stages of dealing with grief, only this time they are dealing with significant change to their daily lives instead. It isn't the same stages but we were able to help people through once we knew what they were. For example we knew it was important to listen to all the 'What-ifs' and give comfort with our plans and diagrams.
InfoQ: Can you please explain your 'squadification' process and how you tested and refined it?
David & Sandy: Scribbling down this diagram which shows our squadification process, really helped us to get our heads around what we needed to do. This is also the diagram we used to run our beta trial in our satellite office in Auckland.
The process starts when the group receive an email invitation which says 'Hey, we're going to self-select!', we always focus on why we are doing it and also on the significant trust that we are placing in people to do this well. Each time we've done this (3 times so far!) we haven't had any negative feedback to the suggestion, or anyone asking to opt out. We're lucky to work with such great people and think we have done a good job explaining too.
On squadification day itself, people need to know what they will be signing up for, so each of the squads has a pre-assigned product owner and they stand up to explain what a squad is for, explaining their 'squad mission' and the kind of things they might do. A project would be too short term and we want to see past forming teams just for specific projects then disbanding them so the focus was long term.
Then we explain the rules, of which there are only a few. The main one is to 'Do what is best for Trade Me', the other ones are that squads need to be co-located, 3-7 people and capable of delivering end-to-end.
When it is time for the self-selection itself ([which we try to initiate] as quickly as possible to maintain people's energy and enthusiasm on the day), we know that time-boxes and cycles are important so we always start with a ten minute timebox where people are asked to self-select. At the end of the first ten minutes, we don't expect any fully formed squads so we carry out a mini-retrospective and just review the current status as a group, so that we know what we need to solve next.
We then re-set the clock for 10 minutes and go again, stopping to check and announce to the group what we have and what is missing. For example, one squad would say we have too many testers and another would say they have no test - so those two would know that they need to talk during the next ten-minute round.
We never know when to wrap up in advance, so we just aim for as many full squads as possible until the energy in the room dissipates. It is surprisingly exhausting to run this process and we find that after a couple of hours together, people start to drift. It's better to wrap up then because we could actually make the outcome worse by continuing (i.e. reduce the overall number of complete squads by continuing to move people around).
InfoQ: What were the main lessons learned in Auckland and how did these shape the final squad-formation plan?
David & Sandy: Visualisation. We had to visualise things better, scribbling names on sticky notes was simply not enough. We had to be able to look at a squad diagram and immediately know if it had all the skills and people that it required for a full squad. We needed to move much quicker between self-selection cycles. We realised that because our visualisation wasnt quite right, it could take a long time to review squads between cycles. Not keeping up the pace definitely brought down people's energy and enthusiasm for the task in hand. Done well, this is a fast moving high energy day (No wonder it is tiring!)
We had to better explain that we had full management buy-in to select our squads in this way. People would whisper questions about what a particular manager may think, they intuitively felt like they were doing something wrong, or going against managerial selection, which wasn't the case at all.
The main lesson learned was that the principle of self-selection did work! We honestly didn’t know this going into the trial, but we went away confident that we could be on to something here.
InfoQ: What sort of sentiment had you gauged from the participants leading up to the squadification day?
David & Sandy: People had LOTS of questions and that was only fair, we were about to ask them to change who they worked with and in most cases adopt a new way of working (Scrum, Kanban or whatever combination of Agile ingredients the new group decided) so we were bombarded with emails, meeting invites, questions in the kitchen (or the bathroom!).
We knew there was a lot of fear and scepticism about it all going wrong, people where honest that they feared getting stuck with a particular person they didn't get on with.
We had lots of requests for more rules and constraints, every squad should have a junior and a senior developer for example. We resisted ALL new rules because each one would cause a ripple effect and make the problem even more difficult to solve. So we let the squads decide themselves what level of junior/senior they needed on a case-by-case basis. We honestly think if we'd given in and added rules at this point, we wouldn't have been nearly as successful as we have.
People also thought we were mad. It just seemed so counterintuitive!
InfoQ: How did the participants react on the day?
David & Sandy: The day itself was fantastic, there is nothing quite like taking a step back to watch a whole technology department self-select. We kept the energy high on the day (again learning from our trial) and this made for an exciting day of twists and turns. Everyone fully bought into the process and we saw fascinating interactions all over the room. Shouting out the number of completed squads became exhilarating as we got closer and closer to our ideal number!
At the end of the day, a lot of people seemed to have won. They were working where they wanted to, with who they wanted to work with. They may have been sceptical before the day but they seemed really positive and after an exhausting day of facilitation, that was just great to see/hear.
InfoQ: What surprised you most from this exercise?
David & Sandy: The main surprise was that none of our what-if scenarios ever happened, not a single one! We were also surprised how much people based their decisions on people; the type of work and products seemed to take a back seat.
We were surprised that this hadn't been done before, given how well it seemed to work. Having been through the process it is hard to understand why everyone doesn’t select in this way and why it seems so counter intuitive.
InfoQ: What metrics and factors were used to gauge the success of the team-formation day? I'm interested to understand how you learned from the experience and how you utilised this information.
David & Sandy: On the day our number one metric was the number of fully skilled squads we could form. We had stated up front that one fully skilled squad was better than many partially skilled squads. We had aimed for 11 full squads and completed the day with 10, this was a huge win and it probably would have been too much of a coincidence if we had the exact number of people to fill all the squads we wanted. As it happened the gaps could drive our future recruitment, which was an important side effect of the day.
One of our 'What-ifs' was what if we end up with people that we don't know what to do with! As it turned out no one fell into this category.
In terms of learning from the experience, this told us that we were 100% right to put so much effort into planning and preparation, making sure the right empty squads were chosen, the right people present and that any anomalies such as specific database people being on multiple squads were thought of in advance.
InfoQ: Was there any dissension with the final outcome and team compositions?
David & Sandy: Not really, almost everyone was pleased with the outcome. Even those who weren't fully happy (some people sacrificed themselves and joined a squad they didn't particularly like for the greater good) understood because they had been directly involved in the conversations and options. Some people who weren't present on the day heard rumours like 'We heard no one wanted to work in _this_ squad,' but that wasn't true and those kind of things quickly disappeared.
InfoQ: How immediate was the process of transitioning existing projects to the new squads and dispanding the legacy structures?
David & Sandy: It took almost three months to transition into the squads that we selected on that day! We had to consider existing projects, people leaving, a month of x-mas holidays and new starters. Some squads were waiting on a new designer being recruited for example, so they couldn't start until months later. That caused a little web of dependencies and the three months was filled with little bursts of new squads starting when a new person arrived and freed up a group of people, it was a bit like when the perfect shape comes down in Tetris and we could fill 3/4 lines at once!
InfoQ: To what extent did the empowerment of squad self-formation carry through to yield self-empowered and self-organising squads?
David & Sandy: The principles from that day certainly still stand today and whilst they have been challenged numerous times since (when we have a new project and the urge is to grab people and start tomorrow) each of our squads has stood strong.
Self-selected squads have been more stable than the teams we selected as managers prior to this. They also appear to be more productive and we have less personality clashes and petty disagreements.
All the squads are now formed and the only emerging problem is one of 'we didn't sign up for this type of work’ where the product has changed or the product owner has moved in a different direction. We made decisions and statements on the day that were for the best given the information we had at the time, inevitably things change and it is right that we question those things.
InfoQ: To what extent do you use intervention, learning, coaching and other support structures to keep the new squads cohesive and value-generating?
David & Sandy: We offer support and coaching to all our squads, although we have 22 squads now and only one full time agile coach. That means we can offer training opportunities and coaching but need to work around this bottleneck by growing our own internal coaches. We have set up a structure which enables people to help and support each other as much as possible. We have an Agile Coaching Guild and offer things like book clubs and suggested reading, whilst we've also tried to pair people up so they always know where they can go for support.
Intervention is interesting, I (David) can think of a few times we've had to dive in and help a squad but in each case the size of the problem was always smaller than it first appeared. These things are inevitable and fall more into the camp of group formation and psychology than Agile or Squads.
InfoQ: In your presentation, you briefly covered the 'emergence' of tribes, guilds and the champions who have also emerged to lead these. Can you tell us a little more about these cross-sections and how you see them evolving and contributing to the richness of communication?
David & Sandy: Our Chapters, Tribes and Guilds were very much part of the overall design and our original decision to fully adopt the Spotify model. One of the key risks to the Spotify model is that squads become isolated and don't communicate with each other, so these support structures are absolutely vital to success.
Our internal 'Agile Champions' who emerged have been a hugely influential factor in the success of this model. We are lucky to have people internally who have a passion for Agile, incredible energy and great people skills and they can really make things happen and laugh in the face of problems which could stump others. We probably have 10 of these people now and new champions emerging.
InfoQ: Does the story stop here or will there be continued refinements to the structure of your squads?
David & Sandy: Oh this is just the start! We'd be kidding ourselves if we thought any different, although we do have to deal with people who initially believed that rolling out our squads would be the end. It can be hard explaining to someone that there is no end!
We have created a social experiment here and each of our squads are a new group of people working closely together on a daily basis and thrown into a situation, sometimes of high stress depending on the type of work. We need to support them, build agile knowledge, grow, deal with people leaving, reduce waste, improve our supporting tools and environment... we could go on, there's a lot!
The good thing is that by now we think that the principles of agile and self-selection have become an integral part of our Trade Me culture.
InfoQ: Where can our readers go to learn more about your continuing experiences with the new teams?
David & Sandy: You can read about our experiences on the Nomad8 blog. In particular we recommend those posts (in chronological order):
Or you can come and hear more when we present at Agile 2014.