Scaling Scrum with LeSS: Lessons Learned

If you are not familiar with LeSS, you may have hard time reading on. If that’s the case, I’d suggest checking out the website first or watching a couple of videos about how LeSS works.

More than couple of years ago, we had to split a big Scrum team of 18 people into two smaller teams. We had been growing rapidly and the team had become far too big to be effective by any Scrum standards. After all, Scrum recommends 5+/-2 people per team to keep things smooth and efficient.

We didn’t want to create some artificial division line between the newly formed teams, based on product specialization or function for a number of reasons – flexibility, knowledge retention and redundancy to name a few. Eventually, we set out to look for ways to scale our Scrum implementation in a way that was going to keep team competencies balanced. 

Why LeSS?

We did some research on the most popular frameworks – LeSS and SAFe. Based on it, we promptly decided to go for LeSS because it seemed like a very straightforward and minimalist framework. It fit our idea of splitting the team without forcing specialization, and it wasn’t going to change too much of what we were already doing at the time. After all, we did not want to introduce “more“ process, and we were looking for something leaner. 

Overview of LeSS

We’ve been using LeSS successfully for a couple of years now and in this post I’ll be sharing some lessons learned and some challenges we faced. As with any methodology or framework, complexity still hides in the need for coordination, communication and ownership. Here are some thoughts of what worked and what did not, based on my experience.

Lesson 1: Backlog Refinement (Grooming) meetings will get messy

Grooming is by far the hardest ritual to pull off properly in any Scrum implementation because it requires good facilitation and an experienced team. But sometimes, when you have close to twenty people in a room trying to estimate a complex story, things are bound to become counterproductive. You need to establish a common understanding and let newer team members get used to estimation before introducing rotation, as LeSS suggests.  Unfortunately, there is no easy way around this – it just takes time and effort.

Here is what could be done:

  • By all means do not rush into introducing rotation – people need time to get used to grooming and you cannot do much to shorten it. It is the price you pay to grow.
  • When eventually you start rotation, make sure you have representatives from both teams, from all key functions and if possible- seniorities. Reducing the meeting to 7-8 people would make it work just fine.
  • Preparing in advance is key. Ask the Product Owner to share stories to groom a couple of days in advance, so everyone can spend some time to prepare and understand all the stories. This also prevents rejection of badly-written stories at the meeting, which you want to avoid anyway, because it’s often preceded by a lengthy and painful discussion. 
  • Introducing a separate regular pre-grooming session for collaboration between top seniors and PO gives venue for discussing strategic ideas and brainstorming. It also helps keep the grooming session focused mostly on stories and their scoring.
  • Strong facilitation is even more important with LeSS. Make sure you have someone experienced to keep the meeting on track, at least initially while you still have everybody-and-their-uncle in the room.

Lesson 2: Planning in two stages has some side-effects

Planning with LeSS is actually more complex as it’s carried out in two sequential sessions. One general, for both teams, and then separate ones for each team.

Every once in a while, an item that got optimistically picked in the first planning session, might not fit during the second (team-specific) planning session. This is mainly because in the second part of the planning team has more time to analyze in detail and decompose the story into tasks. When this happens, the item would pop-out of the sprint backlog of the team in question and this might become a bad surprise for the Product Owner unless communicated well.

Here is what can be done: 

  • Thoughtful preparation for planning always pays off and the team must make sure they know in advance their recent velocity, capacity, any leftovers and dependencies. Having some stories in your mind to pick prior to the planning session helps avoid the issue.
  • The Product Owner must be aware that stories might sometimes pop-out in the second planning when examined in detail and decomposed into tasks. Setting clear priorities for the team will make sure they will leave the right story out if this occurs. Final commitment for the sprint must be done after the team-specific planning sessions to make sure everything fits.

Lesson 3: You will still need some time and effort dedicated to synchronization and communication between teams

To compensate for lost communication bandwidth when you separate teams, you can introduce some additional meetings:

Communities of practice keep specialists from both teams on the same page. (Management 3.0)
  • Overall Retrospective – these are actually recommended in LeSS and you should make sure you don’t skip them after the Team Retrospective. They might feel redundant at first, but they make great venue for teams to address interesting accomplishments and common challenges, or just recap on how their common goals and roadmaps turn out.
  • Regular discussions between Scrum Masters, Team Managers, Product Owners. These short meetings help capture, discuss and handle issues on a higher level for both teams. Team retrospectives and the overall retrospective often generate some items for discussion on this level.
  • Form Communities of Practice (CoPs) – this is another Management 3.0 practice that I highly recommend implementing, especially when scaling Scrum. Communities of Practice cut across projects, teams and initiatives and give the opportunity for practitioners to synchronize, share their knowledge and challenges and develop their expertise further. In our case we’ve been doing regular QA and Dev syncs to keep the respective sub-communities in sync. This resulted in many complex challenges resolved within each domain and has been helping us immensely in reaching our team goals. People committees and social committees are also CoPs worth considering, especially if you want to emphasize on a culture of self-organization and freedom.

Lesson 4: Executing bigger initiatives that span both teams at the same time is still tricky 

LeSS does not recommend introducing coordinators for initiatives, but nevertheless in my experience this works when done in moderation. It helps with complex features and ongoing initiatives that span multiple sprints and even quarters.

Here is what can be done:

  • Assign a reporting person (owner) to emphasise on authority and responsibility to report, drive and deliver on a particular major initiative. This makes sure the initiative doesn’t die off and has someone pushing it forward.
  • Form “virtual” teams committed to specific initiatives. They have their own communication, pace and rhythm, which is separate from the ongoing LeSS cycle, but they still take part in all LeSS rituals.

I know that in a way all of the above might sound like imposing some Waterfall on top of Agile. Even so, you still need to find a way to ensure continuity between sprints and keep the big picture in mind for bigger initiatives. This, of course, could ideally be done by the Product Owner, but if you want to create autonomous teams (and who doesn’t?) it is alright to delegate some of it to team members. Apart from that, using some techniques from traditional project management might often prove beneficial.

In conclusion 

I’d say that LeSS proved to be a success for us as we got a bare-essentials process that allows us to deliver at twice the capacity. We did manage to scale up, and we are still Agile. Our teams can swarm up on a bigger story or even a feature if needed, which provides a great deal of flexibility.

LeSS also helped us maintain proper knowledge distribution between team members. Developer and QA sub-communities exchange knowledge and good ideas naturally flow between teams. Last, but not least, LeSS enabled us to have a common idea about what a Story Point is, which in turn makes our Product Owner’s life much easier, because he can work with a common measure of scope, size and complexity. 

I hope you found this useful and I’ll be happy to know about your experiences when scaling Scrum with LeSS and other frameworks.