Notes on LeSS
LeSS, as in Large Scale Scrum.
I recently attended a LeSS training by Bas Vodde. Herewith, some notes and thoughts on LeSS.
For context, I’ve been using agile and Scrum practices and processes for close to eight years now. I’ve been in agile teams as an individual contributor and have also setup and grown teams with Scrum and Kanban as the organizing tools. In particular, I was part of a sizable LeSS implementation at J.P. Morgan in 2013–2016.
What is LeSS
LeSS is a framework to scale Scrum beyond a team. Here are the key ideas, as I understand them:
- Like Scrum, there’s a Product Owner and a Product Backlog.
- Multiple teams share this product backlog and work on it in iterations called Sprints.
- Like Scrum, teams are cross-functional units of 5 to 8 people.
- Any team is able to work on any item in the Backlog.
- All teams engage in cross-team, shared Sprint Planning, Backlog Refinement and Retrospectives.
There are two flavours of LeSS: LeSS and LeSS Huge. LeSS provides structure for groups of less than 8 teams. LeSS Huge adds a few changes that support organizations of more than 8 teams.
At the risk of over-simplifying, LeSS Huge partitions the product into Product Areas. Each area has its own backlog that is linked to the overall product backlog. Teams use LeSS within each product area.
The big question
In their own words, LeSS is not multiple Scrum teams but multiple team Scrum. The emphasis is on getting all the teams to collaborate and work together in contrast to creating separate swimlanes for each team. LeSS calls for maximizing dependencies between teams. LeSS argues that dependencies are not necessarily bad; what is bad are asynchronous dependencies which lead to integration phases and staggered delivery of a fully working product increment.
This is an idea that I remain deeply skeptical of. My experience suggests that it is hard to scale synchronous collaboration linearly with number of teams and scope of product. In fact, connectivity theory tells us that communication pathways (and hence collaboration points) grow as ~n^2. The natural response to taming this exponential growth is to reduce the scope of a product. However, LeSS explicitly argues against this. It calls for a product definition that is as broad and expansive in scope as possible. For large companies, i.e. precisely the kind of companies that are looking to scale Scrum, this translates into a company-wide or at least division-wide (area) product backlog. A shared backlog of such broad scope in turn calls for expertise across a very large domain requiring a very diverse set of business knowledge & technical skills in every single development team.
LeSS argues that humans can and do acquire new knowledge & skills. There’s no arguing this point and more on it later. However, there’s at least two fundamental constraints to knowledge & skill acquisition.
- Time: While a competent person can acquire a new skill, it takes time to get proficient at that skill. Time that may not be available to a company operating in a competitive market, i.e. most companies.
- Interest: While a competent person can acquire a new skill, they may not be interested in doing so! They may prefer to spend time becoming a master at a few skills rather than becoming proficient at several skills, especially if the skills demanded from a broad product scope do not align with their interest.
While engineers appreciate the opportunity to learn new skills, the above constraints place an upper limit on doing so.
Moreover, it has been widely recognized that providing autonomy, mastery and purpose is essential to instilling and sustaining motivation. But the broader the product remit, the more diluted are these three characteristics and thus, the harder it is to keep engineers motivated.
Taken together, I believe this fundamentally curtails the ability of an organization to deliver on a broadly scoped product backlog, one of the key hypotheses of LeSS Huge.
Some thought-provoking nuggets
An advantage of instructor-led group trainings are the discussions that happen. There were a few in particular that I wish to share.
On scientific management
LeSS places a great deal of emphasis on moving away from scientific management aka Taylorism. In particular, LeSS advocates against two ideas that emerge from scientific management:
- Separating the Thinkers & Planners from Doers: This idea manifests itself in Software Engineering as centralized architecture teams creating detailed design specifications for engineering teams to merely implement. We all know how that turns out in reality! Bas pointed out that this separation is also counter to the very first line of the Agile Manifesto which states, “We are discovering better ways of developing software by doing it and helping others do it.”
- Matching skills to task: This idea manifests itself as companies hiring for particular skills instead of aptitude & ability to learn. While this may be necessary in certain situations, the industry sadly defaults to this pattern. Cue job descriptions that list N years of X experience required.
On feature teams
Bas shared a thoughtful trick to know whether what you have is a feature team or not: does the team speak the same language as the customer? If they do, then you have a feature team. If they don’t, you’ll usually find a translation layer in between, often called Business Analysts.
On perfection vision
It is important for leadership to establish & communicate a perfection vision, a vision of what a perfect endstate looks like. The idea isn’t that we need to hit this endstate. Instead, having such a vision helps us in decision making: does a particular decision move us towards that perfect endstate or not? The better you communicate this vision, the easier it is for your teams to make the right trade-offs, thus federating decision making as much as possible.
On sprint lengths
Sprint lengths should be long enough to deliver a valuable product increment and short enough to reduce time to receiving feedback & maximize learning on that increment. Bas also suggested that fixed sprint lengths (e.g. 2 weeks) in Scrum serve a similar constraining function as WIP limits in Kanban. Something to ponder.
On organizational decisions
If you think of people as nodes in a system, an outcome of systems thinking is that it’s the feedback loops between the nodes/people that influence, effect, and drive decisions. In other words, decisions are made not by people but by the relationships between them.
Personal Takeaway
I remain unconvinced that LeSS works at scale. In other words, LeSS is fine; LeSS Huge isn’t.
Do let me know on Twitter if you agree or disagree!