Team Lego is one of the five teams currently working at Liip Zurich. All team members work together on one, long standing project. Over the last year the team has grown and changed. In the end, we were 10 people working together as one single Scrum team. It worked really well – until it didn't.

Very slowly over time things stopped going as smoothly as they used to. The team couldn't finish their sprints and the velocity was going down. The sentence most often heard at the Daily Scrum was: “I don't know what's up with this ticket, person X is working on it” – a sign of “Gärtlidenken” as it is called in Switzerland. Information wasn't flowing as it should, even though we used the ‘Walk the Board' approach to keep Daily Standup meetings short and focused. Other Scrum meetings were long and inefficient and any further growth of the team was entirely out of the question.

This interesting blog entry about the numbers behind Jeff Bezos' two pizza rule for team sizes suggests that the problems the team were facing were possibly due to its size. Communication between all the people involved was complicated and it's impossible to know what's going on everywhere all the time. People focussing solely on the one task they picked is a logical move to push this problem out of sight. Yet, it is counterproductive for self-organising Scrum teams. It decomposes a team back to a group of people which happen to work next to each other on similar tasks rather than working together at achieving a shared goal.

Even though team Lego cannot be considered a very large team, problems were just around the corner. At 10 people, we were probably only beginning to see the problems that a larger team could bring. However, it's always better to act before the horizon's problems arrive at your door.

Just do it

But how does one go about splitting a scrum team that a) works on the same project and touches the same code every day, b) has only one Product Owner and c) likes working together? Creating two separate Scrum teams surely is a bad idea. It would decouple the teams and create too much overhead on the process side. Our setup required a more integrative approach that linked subteams more closely to each other and supported the work done on a single project, with one Product Owner, one client and – in our case – one Scrum Master, essentially a version of the Scrum process to support a multi team structure.

I discovered that LeSS (Large Scale Scrum) provides exactly that: it's a way to scale a one-team Scrum process to multiple teams. By limiting certain meetings to only representatives of subteams and introducing overall retrospective and coordination meetings it provides a lightweight scaling framework for the traditional Scrum process. Too much process overhead is prevented and teams are forced to self organise and make information flow because not everyone can participate in every meeting. Meetings are more effective and efficient, e.g. participants will be more active in meetings because they cannot rely on the rest of the team to do so. Plannings are shorter and retrospectives are more focused. It all sounded like a good approach to solve at least some of my team's problems.

The actual implementation was very simple, “just do it” really. We decided to give ourselves one sprint to figure things out and then start at the beginning of the next sprint with the new setup according to the LeSS framework. We made some alterations to the meeting setup described in LeSS. The team wanted to keep the weekly estimation meeting big because they felt that the value of getting everyone's input outweighed the inefficiency of a large meeting. Planning on the other hand, was done with two representatives of each subteam because the issues have been estimated already and it's just a matter of selecting the right amount. Retrospectives were held separately so that the subteams can improve and grow together as teams. LeSS suggests to have an overall retrospective together with the client and representatives of the subteams to talk about improvements concerning coordination issues. We didn't feel the need yet but are planning on doing that regularly every couple of sprints or as the need arises.

The first official act of each subteam was a small retrospective to talk about their respective working agreements and team names: Team Y and Team Duplo were born! Eventually we even changed the layout of our team working area and moved desks around to support pairing and collaboration within each team.

What we learned

After the first two sprints the change is already quite obvious. The velocity went up and so did the happiness of the team. The Daily Scrums are very fast and effective – and actually about developers sharing relevant information. Hardly ever does one team member not know what the others are doing, it feels like the “shared responsibility” for a sprint is back. There was a lot of positive feedback from my teams e.g. the developers find it much easier to judge if all the stories in the sprint will be finished with small sprints, there is less coordination cost within the subteams of only four people.

Overall, as the Scrum Master, I have the impression that the teams are a lot closer to the self organising Scrum Team ideal than before. There certainly are new challenges to face, like coordination between subteams (in architectural decisions for example), equal division of support work for the project is tricky, sickness and holiday obviously have a much higher impact on the sprints in a small team. During Christmas time and beginning of the new year we even decided to go back to being one team because there simply weren't enough people around for the subteams to work. Because of the small team size (4 developers, one Product Owner and one Scrum Master) a lot of pair programming is done to get around bottlenecks in the “Review” and “Test” lane on the Scrum boards.

The team agreed to treat the implementation of LeSS as an experiment and go back to being one big team if it doesn't work out for us. Nevertheless, I am confident that LeSS was the right choice for my team and the framework will help us to thrive and become even better at agile software development. We'll figure stuff out as we go along, inspect regularly and adapt if necessary.