LeSS from the Trenches- from a leaders perspective, part 1

There are several frameworks to use when scaling up Scrum or agility such as SAFe, Nexus, or LeSS. Even though these frameworks have been around for some time, it is hard to find stories from the real world. From the trenches. For any other framework than SAFe, that is. In these articles, I wish to describe my practical experience of using Less. My role has been as a leader and as such my perspective is a leader's perspective.

I am not a LeSS expert. I do however have real practical experience with LeSS. I also have twelve years of experience working with scaling up agile frameworks in medium to large-sized organizations. I have used LeSS, SAFe, and self-grown scaling up techniques. I have made mistakes. I have learned. I can relate to mistakes to what LeSS and SAFe explain. What I wish to share are real-life examples of all the mistakes and lessons we learned when starting to use LeSS. As SAFe is popular and many persons know SAFe, I try to make comparisons between the frameworks to highlight differences.

The first part is targeted at you who have heard of LeSS but wish to have a quick overview. The next parts will dive more into the trenches.

Where LeSS comes from

If you have not heard about LeSS previously or find it hard to understand LeSS, it is understandable. LeSS is really, from the beginning, a collection of advice. Pieces of Advice describing what has worked or not worked working having many teams. These thoughts are written down in two books.

The founders Craig Larman and Bas Vodde wished to make one point very clear from the beginning: "LeSS is Scrum". Very few additions or changes have been added to LeSS. Compare that to SAFe. Safe has added new roles such as product management, business owners, system architects. SAFe also adds lots of new terminologies. You have none of that in LeSS. You start with the minimum.

If you wish to simplify a lot you could say that whereas LeSS starts with the bare minimum and advises you to only add where it makes sense SAFe takes the opposite approach. I don't believe that SAFe recommends you to remove anything either when I think of it. They just add more...

The philosophy

Craig and Bas mean that what works and what doesn't work can be different for different organizations. Craig and Bas were reluctant to try making LeSS into a common "works-for-all" framework. The idea is for you to find out what works and what doesn′t. The message in the books is "this didn't work for us but why don't you try it and see if it works for you".

In more advanced terms if you use Shu-Ha-Ri you could say that LeSS is suited for organizations at the Ri-stage and SAFe for those starting to learn (or Shu). Or in Cockburn's words, Level 2/3 is required for LeSS and 1/2 for SAFe. The reason is that in LeSS you need to innovate and alter the rules. Something you do in the "Ha" stage. In SAFe you get full instructions. The "Shu" stage.

There was a large demand for an overall big picture, however. Therefore they wrote the third book "Large-scale Scrum" explaining the basics in the framework. In the book, it is also described how you can organize.

Organization

The organization in LeSS is simple and can be seen below.

You have teams working together picking items from a common backlog, communicating with each other. You have sprint planning, refinement, and retrospective. There are very few differences to what exists in Scrum. Again, that is because LeSS is Scrum.

The only added ceremony is an overall retrospective. This ceremony happens after the team retrospective.

There is only one new role, which is the area product owner. This role is added when the product owner has more teams than the product owner can handle. When this happens you divide teams into an area with an area product owner. The area product owner helps the product owner and is responsible for a filtered number of items from the backlog. Note, you still have one backlog.

LeSS actually describes one more new role which is the Head of Product Group (HPG) which is overall responsible.

Principles

Less describes principles that will help your organization. LeSS has principles on lean thinking, queueing theory, system thinking, relentless improvement, whole product focus, and more. This is basically the same approach as SAFe's ten principles. Each principle is huge. Each principle has numerous books written about them. There are many books. See below for some famous books as a start for anyone interested.

Feature teams

LeSS emphasizes the use of feature teams heavily. If you do not understand the concept of feature teams listen to this talk by Craig Larman. Everything that is not a feature team is "undone" until it can become agile. Meaning, that we allow these parts of the organization to be as they are for now. Again, comparing to SAFe this means we can gradually transform the organization step by step rather than doing a big bang. Sure, in SAFe you can start with one Agile Release Train but that still means adding all procedures coming with SAFe in that train. In LeSS it is ok to have non-agile leftovers. Undone leftovers.

Technical Excellence

Technical excellence is another area described in LeSS. LeSS recognizes that a number of good engineering practices need to be in place in order to realize the idea of feature teams or to have continuous integration. Architecture needs to change to resemble the organizational setup. Conway's law rules.

Management

LeSS recognizes that there is a need for leaders and managers. The role of the manager is to remove impediments at an organizational level, to look at the whole picture to avoid sub-optimization, and to teach and coach. That is to focus on capability improvement. Very simplistic put.

LeSS vs SAFe.

From a simplistic perspective, you can say that where SAFe starts with a full-fledged picture introducing new roles, ceremonies, and very detailed processes, LeSS starts with the minimum needed to scale up. My impression is that SAFe allows you to alter SAFe to your organization's culture, needs, etc. as you get wiser. You should start implementing it by the book, however.

Less instead recommends that you start minimalistic and add on what you need based upon what works or does not work for your organization. If you wish to learn more about LeSS good website is available at less.works.

Implementing Less

As there are no exact and hard rules of how to implement LeSS it is harder to understand. You need to instead understand lean and the agile principles and apply them. I believe that more organizations are tempted to choose SAFe because of this.

In SAFe you get a model that covers all and is packaged in a very nice way. To me, it resembles the Rational Unified Process in many ways. You can choose if you have small project (essential SAFe) or a large project (Portfolio SAFe). Even some of the templates for business cases are more or less exactly the same as existed in RUP.

To introduce LeSS you need to understand the agile principles in depth and experiment. There is no end final state. Something I believe can be scary for many organizations. A typical management's reaction would be "So you say you wish to change the organization and you say it will be better but you can't describe how it will look or what we will change beforehand. Sounds too risky to me."

That was it in a nutshell. To summarize

• LeSS is Scrum
• You add elements of lean, systems thinking, good engineering practices, and other good well-proven practices
• You add overall retrospectives and if needed area product owners
• You don't have to do a big bang. You can have undone elements in your organization
• You start small and you learn what works best for your organization as you go along

I am a big fan of Craig Larman. He gives excellent talks and I have watched several of them both live and on YouTube. If you are thinking of scaling up and understand agile principles, I really do recommend listening to him.

In the next articles, I will describe in practice the challenges and lessons we learned as we worked with LeSS. How did it change the organization's structure, technical excellence, and management?

I will add links hereafter the other articles are written.

Part two - how we organized ourselves

Thanks for reading. If you liked the article I would be very encouraged if you just add a smiley or similar in the comments :)