We’ve begun experimenting with Large-Scale Scrum, or LeSS, and thus far, it’s been an interesting journey. I eluded to this experiment with LeSS in Two Principles for Scaling Any Agile Approach, and I also gave a bit of background into where we are in our agile evolution. The abridged version is we’re several years into a Lean Startup, XP, and Scrum adoption. Read more here.
To be clear, my thoughts today are simply my initial impressions. We’re six weeks into our experiment with LeSS so we’ve hardly dipped our toe in the water. It’s possible that months from now our perspectives and challenges will change. With that in mind, let’s begin with what’s worked well.
- LeSS feels just like Scrum. I suppose that makes sense. Bas and Craig state, “LeSS is Scrum applied to many teams working on one product.” From a procedural point of view, it was a simple matter of establishing Sprint Planning 1, consolidating our teams’ Sprint Reviews, and establishing the Overall Retrospective. As I’ve stated before, however, Scrum is easy. People are hard. Setting up a few meetings where teams intersect is really just the start. What’s great is how eager our teams are to work together.
The role of managers is clearly explained. Scrum does not tackle where managers belong in an agile shop, but I have my own ideas. Since managers certainly aren’t going away, I’m glad to see that LeSS digs into this topic in their book and on their site. I particularly enjoy how this image frames the relationship between teams, customers, and managers.- A consolidated backlog alone can bring teams closer together. Our teams traditionally have a Product Owner assigned per a Scrum team, and each team has its own backlog. The act of consolidating the backlogs alone has paid dividends toward better cross-team communication. We now have greater visibility into what all our teams are doing and a better view of how our work impacts each other and our customers.
As expected, change is never easy or straight forward. We’ve run into some challenges over the last six weeks:
- The notion of same mission, separate teams has some scratching their head. This especially applies to those who work across all our LeSS teams. Some wish all teams would adopt the same “best practices”–a term I despise. We’ve seen how certain practices have helped many of our teams, and some argue that we should require all LeSS teams to adopt them immediately. It’s been necessary to reiterate that each team figures out for itself how to work together, and it’ll likely look different from one team to the next.
- Silos. Silos everywhere. Just before our LeSS adoption, we drastically changed up team membership. It was unfortunate even though I understand the impetus behind it. Because of this, we’ve had to restore trust within the team and reinforce the fundamentals of a cross-functional team. This has taken time and distracted us from our experiment with LeSS. It’s also been a hindrance as we toy with travelers since this has thus far created yet another silo within our budding teams.
- A consolidated backlog isn’t enough. Feature–not component–teams still need to be formed, and while we’re nearly there, we have a few steps left to take. Because of this, our consolidated backlog can sometimes feel a bit contrived. Additionally, this can sometimes make for a dull or underwhelming Sprint Planning 1 experience. I wish we had taken the opportunity to experiment with self-forming teams at the start of this journey. Doing so may have inspired our organization to take the remaining few steps to becoming true feature teams.
So should you experiment with LeSS? I think so. Thus far, it’s been a great experience for us. If you have your own stories as you experiment with LeSS, I’d love to hear them in the comments below.
Do you want to get notified when new posts are published? Leave your email below.
My learnings with LeSS are simple: It does not work with junior teams, and people will be pushed out of their comfort zone with the increased responsibility teams need to assume. Former POs may feel demoted, becoming SMEs. Make sure that your C-level fully backs LeSS — there is no working version of lip-stick or cargo cult LeSS.
Good learnings, my friend. So what’s convinced you that there can be no cargo cult LeSS?
Hi Tanner, what pain points drove you to try LeSS? What was your setup in terms of number of teams, their size, working on one or more products, the focus for each team
– one feature, multiple features, sharing work on a feature, creating/updating a supporting sw component, etc.? Do you have a feel yet on org/team indicators that you might benefit from trying LeSS – e.g. minimum number of teams, location/colocation, past issues in delivering, reoccurring impediments, etc.)?
Here’s a few, quick details for you, but I think most of them are answered between the two blog posts. If something is missing though, let me know, and I’ll elaborate.
* Our most obvious inspiration for LeSS was better cross-team collaboration.
* We’ve thus far experimented with just two teams as we try out LeSS. Team sizes are 4 and 9.
* All our teams are co-located and are teams whose members are well versed in Scrum.
* There’s a number of questions we hope our experiment will answer, the most important of which is probably “Do we believe LeSS helped us deliver a better product (what about faster?) to our customers and did our teams enjoy the experience?”
I believe that every scaled approach has it plusses and minuses. They all attempt to tackle the problem in different ways. I would encourage everyone not to be dogmatic about a particular flavor that suits us because what suits us is irrelevant. What matters is if it suits the state of the system and the people.
Finally, the customer doesn’t care how we create our product as long as our product benefits them in the right ways. After all, people don’t want a ½” drill. They want a ½” hole. They don’t care about the tool; they care about the outcome.
Sorry, I now just saw your earlier post though the my questions drive into to the details. For one our products, we have now have 5 teams with about 40 scrum team members working in different areas of the same product coordinated loosely by SoS. I’ve have yet to think too deeply on how we would scale if things go the way we hope. Based on current org size, LESS, DAD, and Scrum@scale would in the mix for future investigation rather SAFe.