Last week, I participated 3-day LeSS practitioner course by Bas Vodde.

Why LeSS for me?

Agile software development, XP and Scrum gave me a number of fundamental answers in how to improve my profession. Scrum is a simple and truly great framework for delivering working software. On top of Scrum, in the past years I’ve learned many practices, which fit really well with Scrum and help me solve many common challenges.

Nevertheless, throughout all these years, some fundamental questions remained: How does Scrum fit in large companies with strong hierarchical structures, and theory X way of thinking? Is the ultimate goal to Scrumise the whole company and everything will be great? Is this achievable, and does it make any sense?

I have seen some really nice examples where Scrum is applied throughout whole organisation in a certain way, like Bol.com in The Netherlands. The reason why it worked in this, and other organisations have not much to do with Scrum, but already existing context and culture. This organisation embraced the fundamental Agile values and principles, and throughout continuous improvement they’ve naturally managed to be very effective with Scrum.

I have myself experienced LeSS approach in a scaled product development within a traditional organisation. LeSS gives me a frame of reference for what I’ve already experienced.

By far the most other organisations still have Taylorism culture, large structures, functional silos and many management layers for delivering products and services. The way of thinking and many practices, such as individual objectives and performance reviews conflict with Agile principles, such as self-managing teams.

These organisations often say they also apply the Agile methodology, whatever that means. In reality, one or multiple teams may have applied Scrum practices in software delivery (a bit of analysis, programming and testing). Obviously, software delivery is a small part of everything that needs to be done in value creation. We have to include other disciplines also. Besides, many products are delivered by multiple teams. In some cases, hundreds or even thousands of developers could be working on a single product.

Scaling is a hot topic today. Majority of Agile community hates this topic. Me too. Nevertheless, the problem is not the topic, but approaches that came along with the topic. As already mentioned, the fact is that many products require many teams to work on, simply because of complexity of components, hardware, software, different configurations, etc. As already mentioned, delivering working software is not really same as getting value out of products. Yes, many of these products are needlessly complex or could also be delivered and managed by one team of max 9 people. But try to imagine envisioning, making and operating a Mars rover with only 9 people.

So, how do you work with multiple teams on a single product and how do you improve a product / service delivery in large organisations that already have many teams?

We already have several scaling frameworks, why another one?

Unfortunately, frameworks like SAFe® and DAD, have moved away from certain Agile principles in order to compromise with existing reality of large organisations. It is true, one cannot just simply introduce Agile principles and values in large organisations, unless structure and culture is also fundamentally changed. Since we know how difficult this is, these frameworks have adjusted Scrum and many practices in order to make a fit with existing structures and culture.

Is this still Agile software development? No, it is not, but it sells really good and they might bring some improvement. Their message is rather attractive: You can also do Agile, while retaining your existing structure and culture.

At the end, it is the customer and competition who decides if your Agile flavour is an effective one. At the end, anything we call Agile is just a mean to an end right!? How fast do you actually deliver constantly changing requests? How good is the overall quality? How much value do you actually deliver compared to cost of ownership? And do you continuously improve or only getting bigger and slower? How engaged and happy are your employees?

There is a reason why extremely successful companies don’t embrace these frameworks. It does not make any sense to them once you discover how much value you actually deliver. I like Agile way of working because it transforms the way we work, while delivering tremendous results, and not merely a slightly faster delivery.

So, LeSS and LeSS huge frameworks do not compromise Agile values?

No, they do not. Just like Scrum, LeSS helps you implement Agile principles and values. The only essential difference with Scrum are a few minimal additions to make it work in multiple teams product development. It is a single-team Scrum scaled up without making compromises.

What I’ve learned in the course and from books, is that LeSS is also an organisation design framework. LeSS adoption means an actual change in organisational structure and culture. I’ve learned a large number of tools to help in this transition. The promise of LeSS is that you can truly introduce Agile principles and values in large organisations by changing the fundamental principles and structure an organisation is based on.

Therefore, don’t expect an adoption of few months or a year and you are done. Depending on your context, the change could take many years. Fortunately, you don’t have to wait this long to see results.

Why would anyone want to go through this change?

A simple answer could be survival. Nowadays, whole industries are taken over by companies with a number of empowered and fully self-managed teams that deliver ingenuous solutions in weeks and also a great service.

A much better reason for such change is people or, as we so lovingly call them, resources. Companies should be people who collaborate for a meaningful purpose. And not merely a group of human resources who exchange effort (in reality it is more their time) for salary and hopefully a bonus, without really knowing or believing in the purpose.

Some highlights from course

The following list is my interpretations of messages I found the most interesting:

• Taylorism: It is going to take another 50-100 years to get rid of it.
• Everyone wants improvement, also traditional management.
• Don’t scale Scrum teams in Scrum of Scrums or something, but scale development teams into scaled up Scrum.
• Agile development is about shortest possible feedback loop. Functional teams have much longer feedback loops compared to cross-functional teams.
• Continuous improvement happens with 3 ingredients: fast feedback, proper listening to feedback, and practice makes perfect (have stable teams working on a product).
• Don’t isolate development teams from outside (customer, users, stakeholders) for the sake of more productivity. They will be less productive.
• In a LeSS adoption, you must deal with existing organisational structure.
• Portfolio and program management are not needed when LeSS is adopted.
• Watch the ball, not the players. Watch end results, not individual performance.
• Software development is a knowledge creation process, not a code output process.
• Traditional organisations have many Business Analysts, probably because teams lack domain knowledge.
• Encourage domain specialisation instead of technical specialisation of teams.
• Let go of idea that somebody is actually in control in large organisations, and that things happen for a reason.
• Dependencies are much easier to solve if they happen at the same time.
• Definition of Done is a very powerful tool to identify how far feature teams can go, and what can be improved.
• If your Product Owner is not really a Product Owner, you might want to call him a Temporary Fake Product Owner. 🙂
• Having a Product Owner who is 100% involved with teams, does not make any sense. In a scaled situation, teams could do product backlog clarification without Product Owner’s involvement. She will still do prioritisation.
• The main challenge in organisational redesign is the change from Theory X to Theory Y type of practices in organisations.
• Metrics: it is much more important to know how to use metrics, who sets them, and why we use them, instead of defining the proper metrics.
• Find out if a manager holds on to his role or to his skills. The second one is more likely to embrace LeSS.
• Encourage communities of practice across multiple teams, strong collaboration and direct communication between teams. E.g. architects could facilitate architecture community of practice, but decision making is still done by teams.
• Scaled or not, the best tools are still post-its and whiteboards.

I loved the course given by Bas Vodde. It was definitely worth travelling to Singapore.