At Vistaprint, we strongly believe in developer autonomy, self-organization and empowerment. It involves not only how we work internally – what are the day-to-day processes, what agile ceremonies does the team want and what we work on – but also who do we work with.
And in order to accomplish this, sometimes it’s required to change things that, apparently, are working.
Wait a second… squad?
When we started the Agile transformation at Vistaprint, we adopted the “Spotify engineering” model, with small cross-functional squads that included developers, QA, Scrum Master, Product Owner, … and then, squads were grouped into tribes.
Over time, we’ve been adapting this model, tweaking it so it better represents how we want to work at Vistaprint. And this process is still a work-in-progress: our structure is constantly evolving to be more aligned to the company and to ourselves as individuals.
Why a squad reformation?
Let’s take a look back and see why we went through this process when there was no apparent need to disrupt all squads.
Originally we had four squads, with 4 or 5 people each. But a few people left or changed roles, and that left us with a sub optimal distribution. On top of that, we were bringing a small 2-people squad into the team. So we went from this:
But after a couple of years with stable, mature, productive 4-people teams, there was a growing desire to reorganize ourselves into new squads.
And that was exactly the problem: for more than 2 years (up to four in one case!), squads were so stable that people only got to work with the same few people. And most of us wanted to change our day-to-day colleagues, to explore new ways of working and try new things.
Preparing the squad reformation exercise
We had several informal conversations before doing the reformation, but when we got into the room to reform, we had no idea on how the process would be. We had two hours to both decide how to run the exercise and actually run it.
There was an easy (but undesired) backup outcome in case we didn’t agree on how to redistribute people across squads. And that’s what the leadership presented.
It was a safety net in case we didn’t agree on a different outcome. It involved few changes, and almost no disruption. But no one really wanted that. So we were committed to agree on something better.
We didn’t know how to start, so we did something similar to an ice-breaker. Each of us shared the skills we wanted to learn and areas we wanted to improve.
You could hear ideas from ‘learning more about the Hadoop stack’ to ‘being stronger in pair programming’. We were very impressed by how open everyone was about the skills they were interested in acquiring.
And after that, we looked at each other. What do we do now?
Once we knew what everyone else was looking for, we decided to go around the room again. In this case, we described our strengths.
Some software engineers focused on one or two main skills, while others elaborated a bit more. We discussed both technical and personal skills. It was a powerful activity. Listening to what people can bring to the team was also a very good exercise.
At this point we had visibility on everyone else’s interests, and everyone else’s strengths. But how to move forward?
What happened next was magic. The attendees started discussing how to drive towards a solution. Some suggested matching skills they wanted to learn with skills people had offered to teach. Others suggested describing their desired organization.
I want to be in a squad with Alice, Bob and Carl.
Wow, that was hard! Defining the people you wanted to work with had an immediate counterpart: you were effectively making explicit other people you were less interested in working with. And if you were choosing some people from your old squad but not some other people, they could feel hurt.
But, as mentioned previously, we were mature teams, with a lot of trust built during the years, so everyone felt extremely comfortable with the approach, and so we kept going.
After a while, everyone had defined their ideal squad, and we started to see some patterns. But still, we were missing the last bit. How do we merge everyone’s ideal squads?
So we took a step back, and focused only on pair matches, instead of full squad matches. So if Alice was part of Bob’s ideal squad, and Bob was also part of Alice’s ideal squad, we would try to put them together.
And after looking carefully, we managed to match all pairs but one, into a new squad structure. The squad reformation was done!
We knew we would come out with a new squad distribution but we were not sure how it would look. Also, we didn’t have a defined process, so we had to come up with one during the process itself.
And the outcome was great: we came up with strong and balanced squads. And the most important thing: we had the squads that the developers wanted to have.
It required trust within the team, being honest and making choices explicit. Trade-offs were needed, but putting them on the table helped ease the process.
It also required trust from senior leadership. Breaking high-performing teams had a cost. But they not only accepted it, they encouraged us to experiment and try new approaches.
It paid off. Just few weeks after the reformation, teams were performing as before, and we could see the motivation boost the exercise brought to the team.
Just two weeks after the reformation, we presented it in a Lightning Talk in the Barcelona Software Craftsmanship 2016 conference.
You can see the video below (in Spanish).