Case Study: Australia Post

Inspired by our squadification event, Australia Post set out to try self-selection for themselves. 60 people were asked to figure out who should be in which team and choose who they wanted to work with. Read our interview with Andy Kelk, Australia Post's Head of Technology for Digital Mailbox, who made it happen!

Andy, thank you for talking to us. Can you tell us about your own background, what role you had at the company and how long you had been there?

I’m a developer by trade and moved into team leadership roles when I was working at the REA Group. I got my first taste of agile and what it meant when I was working there – we went through a big transformation over a few years – and I never wanted to go back to doing things any other way.

By the time I got to Australia Post, I had moved into a technology lead role for a particular product line (the digital mailbox) – I was looking after delivery, infrastructure, security and so on. I’d been there for about 2 or 3 months by the time I first read your article on squadification at TradeMe.

Before you did it

Why did you choose to use self-selection?

Both Mark Richards and myself read the article you’d posted and we loved it. The beauty of having people decide what they wanted to do was empowering – it fits with my way of working which is to put people at the centre of what we do.

We’d already been through two rounds of re-jigging teams to make them fit with the work and each time it had been a bunch of leads in a room with post-it notes putting people into boxes. That really seemed to dehumanise the process. People just became convenient ways of filling gaps in a team rather than... people. Added to that, the teams that had been decreed by the leads never seemed to stick. A few of them bonded and worked well but others would fracture and people would drift back to where they’d been before. There had to be reasons why that was – people weren’t bought into the teams that they’d been placed into or their roles in those teams.

It was also something a bit different and daring and I wanted to show people that we’re willing to take risks and not just do the same-old same-old and hope that things changed.

What was the state of play with your teams and people at the time?

We had a very functionally-aligned organisation with a mobile team, a web team, a systems/infra team, a backend team, a testing team and a client integration team. We wanted to shift to having cross-functional teams who could deliver across all of those disciplines and be aligned to the two main external-facing users of the system – consumers of documents and providers of documents.

When I’d arrived the challenge was described to me that they needed “more disciplined” agile. Which, I have to admit, confused me at first. On digging further, it was clear that what was missing was transparency and visibility of the work being done. There was also a lack of proper team engagement – they were really just groups of people working on the same general area rather than pulling together as teams. With some exceptions. For example, the role of an iteration manager/scrum master was seen as an administrator – someone who organised when the showcase would be, got everyone’s updates for the reporting, made sure Jira/Rally were up to date. There was no real concept of having a coach who actively nurtured their teams. So it was clear that focusing on building teams who engaged with each other and who wanted to work together towards a common goal was an important ingredient.

What did you think would happen?

I was always optimistic about it. I think that people tend to be pretty resourceful and can solve problems without needing “managing”. After all, they’ve managed to get themselves into the job, they’ve run their own lives, they’ve proved they are capable. So I didn’t worry about it not working. I knew that I’d have to convince people of it – both those alongside me and those in the teams.

Did you have any specific fears or worries?

I didn’t. But I gathered a whole raft of them from the people I worked with. And, of course, we had to be able to allay those fears. I was really careful to talk about this early on in front of the whole group. I wanted everyone to be involved as inputs to the planning so they didn’t feel that this was being done to them. I didn’t want a big ta-dah moment where we revealed the plan and, by the way, we’re doing this tomorrow. So I talked about it very honestly to the teams – this is something we’re thinking of doing; it might work; it might not; but I’d like us to try it. I pointed them to your article and that certainly helped a lot of people see into the logic. Then I asked everyone to write down their hopes and fears on post-its and stick them up on the wall. Those post-its were then the inputs for the work that the leadership team did over the following couple of weeks.

The ones I can remember: is this musical chairs? (i.e. when the music stops, is there a seat for me); what about skill X (we only had one person doing that one); what if we can’t come to an agreement; how can we continue to have collaboration across functional areas (we introduced the concept of chapters to deal with this); how does this work for the web dev team (they were offshore).

What would you have done if it didn’t work? What was your worst case scenario?

I was always very clear that we’d try this and if it didn’t work then we’d try again at something else. We’d had a *lot* of change over the previous few months (product had launched, GM had left, new leaders had started, SAFe had been adopted, teams had changed two or three times, etc). While we wanted to try and stabilise things we also knew that it wouldn’t be a disaster if this change didn’t stick.

How much preparation was involved?

A lot! There were lots of moving parts to consider. We’d set ourselves a high bar because it was part of a broader series of changes – functional to cross-functional, technology challenges (trying to fix the deployment pipeline, rebuilding a monolithic system), integration with other parts of the enterprise and so on.

There was a core group of my leadership team who each took different areas of concern (e.g., chapters, mechanics of the day, etc) and worked on them. Then we got together two or three times a week to track progress. We had a kanban wall to do that. We had to make sure that the teams were comfortable but we also needed buy-in from the rest of the business unit – there were senior product stakeholders who had a lot invested in having delivery teams who weren’t completely incapacitated! So a lot of wrangling behind the scenes. We’d actually set ourselves a deadline to do this by a certain date because we were reaching the end of our Potentially Shippable Increment (PSI) and we wanted the new teams in place for the start of the next PSI. But with public holidays (Easter) getting in the way, we realised we just didn’t have enough time to get it done. So one of the compromises we took was lengthening the existing PSI by one sprint to give us extra time. We also decided to scale back from a full-scale adoption to having one of the new teams spin up immediately and keep the other teams in their old way of working.

One thing we dropped the ball on was the photos of people. We’d arranged to get all the photos from people’s ID cards as their avatars on the day. However, it wasn’t until the morning that someone (me) thought to cross-check the list of photos with the list of attendees. And we were short by a few. Which would have been a bad look if people turned up to find they weren’t accounted for. Given the sensitivities around musical chairs, that could have been a bad start! Instead we printed out their names and arranged to take photos for them.

What did you find to be the most persuasive argument when people didn’t think self selection was the way forward?

“Is it any worse than what we’ve done before?” – was probably a strong one. We didn’t have a stellar track record of setting up long lasting teams. But also talking about wanting to build a high-trust environment and this was a good demonstration of commitment to it. And using your example as social proof certainly helped!

During Self Selection

How many people and teams were involved?

We had 5 development-flavoured teams, 1 infrastructure-flavoured team, 1 operations team. Each was around 8 to 9 people. So around 50 to 60 people.

Were the teams pre-selected?

We knew what flavour of teams we’d have – three focused on consumers of mail, two on providers of mail; we also knew we needed separate infrastructure and operations teams. My original goal had been to have infrastructure and operations integrate into each team but there were some organisational and technical constraints that prevented that happening straight away.

We had pre-selected the iteration managers and product owners as the kernel of each team. We’d managed to get five Iteration Managers (Scrum Masters) and 5 Product Owners for the development-flavoured teams. We put them together in a room and did a speed-dating event. Each Iteration Manager sat with each Product Owner for a couple of minutes and talked about what was important to them. We then asked them to nominate pairings. It was a brave move from the 10 people involved – kudos to them for going along with it. We managed to come out with some good pairings – for example, a technical Iteration Manager paired with a very commercial Product Owner, a non-technical Iteration Manager and a technical Product Owner.

Beyond knowing who the Product Owners and Iteration Managers would be and the flavour of team (consumer or provider) we didn’t know much about the team. We didn’t know what work they’d do as the product roadmap wasn’t yet in a state of maturity to know what would be upcoming. My goal was to have teams focused around a particular value stream (payments, ingestion, reading experience, etc) but we weren’t there yet.

We didn’t even give the teams names because we wanted that to be part of the team formation activities – choosing a name they liked. But I was adamant that I didn’t want the teams to be “consumer 1”, “consumer 2”, “consumer 3” because that introduced a hierarchy (who wants to be in team 3 when you can be in team 1?). So we picked 5 colours for the teams. That was their identity for the day.

What constraints did you place on the people involved?

The main one was that the teams had to be 7 plus or minus 2. So no teams bigger than 9 or smaller than 5. The other was encouraging them to “do what’s best for APDM”. So while we wanted people to have free will and to choose what they wanted to do, the ultimate goal of the organisation was still what we all needed to meet.

What did you notice about the level of buy-in into the process when people arrived and when they were taking part?

On the whole, the buy-in was amazing. People were really engaged with the process and they actively participated in conversations at each of the team areas.

We did have one team who checked out and didn’t participate. That was part of a larger organisational issue around the structure of the work they did and where they fitted into the broader enterprise. It was unfortunate that this issue coincided with the self-selection day. However, it didn’t impact on the rest of the teams being able to form.

The energy definitely dropped after the first two goes at getting the teams formed. Once it became clear that very little change was happening between goes, we gave people a final five minutes to solve anything before we took it offline.

Was there anything left over at the end of the self selection event which required follow up?

We had a couple of skill gaps that we knew we’d have to fill. They were specialist areas that needed to be spread across all of the teams. I gave the control of those issues to each of the teams involved to work on. They did that over the next Potentially Shippable Increment (PSI) before the new teams actually started working together. We also had one person who hadn’t been there on the day who we had to find a home for.

We then asked each of the teams to meet weekly and to start forming. So they drew up social contracts, came up with a team name, had coffees and breakfasts together, we funded a few rounds of drinks, etc. The one team who started working together immediately had to do that at the same time as starting to deliver.

What surprised you most about the process or the outcome?

How quickly we got through it. I’d budgeted an entire day for it and we were done by lunchtime. Which was great. I was really pleased (though not surprised) to see some people making unexpected choices. E.g. one of our team who was doing Android work selected into a completely different development role (still Java, but not Android). That was cool – because that wouldn’t have happened in the old Post-it world.

After you did it

What did you learn?

Make sure you have photos of everyone :-)

Also, don’t underestimate the amount of wrangling to get everyone backing you up properly.

The final thing was that we had an 8 week gap between the teams selecting and starting to work together. That was hard because we had a few people leave in the interim and so we had to constantly re-evaluate whether the teams we were moving to would still work. We tried to resist the temptation to go from 5 teams to 4, for instance. And where people were coming into the environment or changing teams giving them the opportunity to direct that process and not fall back on old behaviours of moving people to “where they’re needed”. It’s a constant challenge to remind people of that mindset shift.

Was it a success?

I think it was. But I didn’t have the chance to stay long enough to really see outcomes. The new teams were really just getting going by the time I left.

Did you notice anything about the teams that self selected that day? For example, did they stay together longer, or did they storm faster than usual?

There was definitely more engagement amongst the majority of those teams than there were before. That’s not to say that everything worked perfectly. However, of 5 teams I would say 3 were streets ahead of where they had been; 2 still had some challenges. What was immediately noticeable was the difference in the PSI planning sessions. Where before there had been a huge amount of wrangling of dependencies and cross-team conversations, you suddenly had lots of small, focused groups looking at their own particular work. You could see the teams who had started to jel already. One team in particular had an amazing culture and vibe between the members – they were, not surprisingly, also one of the most productive when measured subjectively by the program-wide showcases.

Did you notice any changes to your metrics or measures after the self selection event?

Unfortunately I wasn’t there long enough to see those.

Has self selection had any adverse affects?

Self-selection in itself, no. However, the cross-functional move certainly had a few. But we knew they would happen and the only way to solve them was for them to happen. If anything, I’d say that self-selection helped us solve some of the problems that moving to cross-functional teams presented. It certainly gave people the confidence that I was serious about us being a bottom-up, learning organisation where decisions were made by the people closest to the problem.

What would you say to someone who is debating whether to use elements of self-selection?

Do it.

Trust in the people in your team and listen to them. Talk about it a lot before you do it. Look to others who have done it as proof and learn from them.

Do you know anyone else who has since tried self selection?

I don’t. Although, since I have talked about it at a few events I’ve had people get in touch and say they’re interested in doing similar things. So there’s definitely interest from people out there.

A big thank you to Andy for sharing his experiences. Andy has also written about his experiences on his blog.