Radical Restructures and Self-Organising Teams at TradeMe

Responsible for 2/3rds of New Zealand’s local internet traffic and with 3.4 million members (3/4 of the local population), TradeMe is New Zealand’s second largest internet company. So strong that eBay can’t edge into their space. Most amazing of all is their ability to sell 3000 chickens on the website each day!

20140711-085636-32196057.jpg

Despite using Agile project management and all the latest technology to build their platforms in a customer centric manner, they still face all the problems of any other internet based business does, in terms of developing their software teams.

The Self-Organising Organisation – Total Squadification at TradeMe

On Wednesday I heard from David Mole @molio and Sandy Mamoli @smamol who described their story and the steps they took to scale their teams using a self organising approach.

TradeMe we’re starting new stories to create features regularly but not shipping at the rate they expected

Last years they were in a situation that might be familiar to some of us. Despite their best estimates and efforts, they struggled to release incremental changes on a regular basis. Deployment wasn’t an issue, they had two deployments a day but team members were being stretched across multiple teams and dependencies and bottlenecks were developing.

Coupled with the odd “I need x by tomorrow” feature that would appear form their CEO, the core original developers were being pulled from teams to work on a specific new feature. Entire new teams were hired to help them do it. This method of growth meant an expert was involved, but that the team went through Tuckman’s phases on a regular basis.

Portfolio cards on the wall showed all the projects going on but still new features were being prioritised and there were bottlenecks with testing, design and acceptance.

Management brought us these “just get it done” jobs and they took someone from the roots of our organisation with knowledge to the top of this new project. If we were playing Jenga – our team was starting to look like this. ~ David

20140711-091248-33168373.jpg
Clearly, dictating ‘who works on what and how’ wasn’t working, but what could?

Their FedEx Hackathon days provided inspiration for a solution

FedEx day: A 24 hour build to push out something cool. FedEx days were about getting stuff done in a fun way. Enjoying working with your teammates on something cool. And of course the question arose: why can’t it be FedEx day every day?

If we were privy to a FedEx day we’d see:

  • All participants wanted to be part of a cross functional team.
  • Teams were small. The biggest had 6 members.
  • Nobody is multitasking.
  • Nobody was worrying about being idle.

Much like a great team building day.

Could squads be the answer and could they scale it?
It was Scrum at its finest and it got them thinking of Squads. Small stable teams who work sequentially on one thing. The evils of multitasking never cuts in!

Others had led the way but TradeMe needed to do it on a much larger scale

Spotify have written an amazing white paper and selection of accompanying video presentation about how they structure their development team. Have a look at the white paper tribes, squads, chapters and guilds from Spotify.

20140711-085638-32198012.jpg
Of course fear of change kicked in. There’s a big difference between being agile and doing agile. They were adamant that the process shouldn’t be at the detriment of creativity. So rather than tackling the most resistant part of the organisation which might seem like a good move, they decided to take 20 of the most shining team members and polish them to a diamond.

Then they’d bring others along quickly!

Total Squdification, a pilot and then all in!

After meticulous preparation, in a single day they brought the group of twenty together and asked them to self organise into squads.

Product Owners pitched the steam of work that each squad would work on and despite their fears, the team behaved like trusted professionals and self selected three squads. Fully skilled and with all the team members required. Ready to work with people they enjoyed working with on a project they were interested in.

With a successful pilot as proof of concept, they they implemented Total Squadification across the entire 100 plus member team. Creating 10 of their required 11 squads in a single day.

Sandy has a great write up on the process here and a Team self selection kit to help others wanting to implement a similar model.
It’s a spectacular feat that had many pitfalls along the way. A single blog post wouldn’t do the intricacies of their preparation justice.

It’s also the results that excite me.

Self organising teams upped productivity, morale, retention and business results

When Sandy and David began their squadification day, they asked that the team think not only of what is right for the but also what’s best for TradMe. Thinking of their needs and that of the business has meant that six months in and all metrics are up and continue to rise.

Understanding that people know themselves best and that they know themselves better than their manager, was proven. The squads are still intact and working well. The process has also identified the projects no one wants to touch, which has helped them recruit specialist for those projects.

Could this work in your organisation?

On of the greatest benefits I see of self organising is that beyond getting to work with people you prefer to work with on things you prefer the culture changes. I think these type of changes would occur:

  • Not being told what to work on allows teams to follow their passion.
  • Members will feel more inclined to speak up about their ideas for improvements.
  • They will think of the team and the company more than their individual goals.
  • If squadification day became regular, or if trading windows were opened like in football for people to shift squads, then the idea of guilds and chapters would prosper.
  • Chapters of designers would meet regularly to share insights and techniques. Guilds of a specific industry or sector would share knowledge and ideas for how to make each squad function better.

All and all it was an insightful evening and I’m still thinking through this and it’s ramifications on job structure and the sharing economy. A blog post to come soon.

So to wrap up, could this work in your organisation? Are there team members and projects you’d love to work on or instigate? Are there team members that might not make the cut, or some you’d like to buy in from other teams? Let me know in the comments.

The Locomotive Revolution and Agile Project Management

I was watching a program last night on the evolution of the train, from the first steam trains to the current Shinkansen and AGVs. It was a great story of evolutionary steps to get us to today. Yet one stood out beyond the others. Revolutionary.

Bluebell Railway

A post shared by Nick Allen (@nickwallen) on

Right before the invention of Stephenson’s Rocket the current train (sorry) of thought was: the most efficient way to move goods and passengers on tracks from one point to the next is the cable car. You would hook the carriages up to steam engines constructed at regular intervals along the track and reel in the cable to bring them up. Then uncouple, ready for connecting to the next engine. Stephenson suggested the engine could in fact travel in front of the carriages pulling them along. Revolutionary.

As I watched I couldn’t help but see correlations to Agile and Scrum. The fix mounted engines gave waterfall progression to targets and the locomotive was Agile. Exploring this metaphor a bit more I now have a far greater empathy for those that have troubles adjusting to an agile project management style. It’s revolutionary.

Fixed steam engines

  1. There were fixed costs for each mile of track and steam engine.
  2. Destinations (results) were defined from the start.
  3. If one steam engine breaks down you could not complete the journey.

The locomotive

  1. Costs would vary with the length of the journey.
  2. Destinations could change. The train could even switch tracks (pivot).
  3. The locomotive was independent.

This shift in focus is polar. Switching from focusing on cost savings to revenue creation is a big change in mindset. Yet taking the jump from emphasising defined costs and outcome to flexibility and incremental value puts clients and users at the forefront of projects.

This places organisations in an even better position to give value in return for value.