More with LeSS: An Interview with Cesario Ramos
Have you heard of the Large Scale Scrum (LeSS) framework, but aren't entirely sure what it is? Are you a Scrum Master who wants to take his knowledge of one-team Scrum to the next level and learn about scaling agile development to multiple teams? Cesario Ramos, Lean & Agile coach as well as certified LeSS trainer, shares his knowledge in an interview.
Large-Scale Scrum (LeSS) is a framework for scaling agile development to multiple teams. LeSS builds on top of the Scrum principles such as empiricism, cross-functional self-managing teams and provides a framework for applying that at scale. It provides simple structural rules and guidelines on how to adopt Scrum in large product development.
Someone who's without a doubt an expert on the topic is Cesario Ramos.
Cesario Ramos is an independent product development consultant and founder of AgiliX, a small network organization that guides agile improvements throughout Europe. He works as a Lean & Agile product development coach on large scale and small scale Agile adoption and as a certified LeSS trainer, professional Scrum trainer from Scrum.org and Qualified Innovation Games® Instructor. He enjoys helping people improve their ways of managing and developing software products.
Today, he shares his experiences and knowledge about LeSS on the ti&m Blog.
You led the Scaling Agile Night in Zürich last month. How was the response of the participants? Is Switzerland ready for LeSS?
There were 40 to 50 people at this meetup that was organised by swissICT. I did a very interactive session for about two hours and the energy was great. I got some very good feedback that it was fast paced and though provoking. Afterwards, we went for beers and had some great discussions as well.
The slogan of LeSS is: “more with LeSS” - what does this mean?
More with LeSS means that in LeSS we build our method up and not tailor it down.
What I often see my customers doing is what I call copy-paste scaling. Copy-paste scaling is scaling Scrum by copy-pasting Scrum Teams; adding more Product Owners, more Product Backlogs, more Scrum Masters, and more Development Teams. To coordinate this growth, organisations add extra layers of coordination, extra processes, special roles like ‘Feature Owners’, and additional artefacts. This leads to unnecessary complexity in your organisation, poor team-customer collaboration and teams losing focus on customer value.
In LeSS, you do not select all the things you might need from a big menu of ‘answers', but rather use empirical process control so that people learn, improve and add to their processes based on experience. This approach leads to less prescription, more learning and simpler organisations.
Where other scaled agile frameworks promise packaged solutions – LeSS offers hard work and an experimental mind-set based on deep agile and lean principles. Why should one go with LeSS?
People want to buy the “magic box”. Once you open it up, all questions are answered and everyone will live happily ever after.
Unfortunately, product development and organisational scaling are complex problems to solve. Therefore, there are no pre-cooked solutions because every organisation is unique. Sorry, there is no elevator to success, you have to take the stairs.
If you want to optimize your organisation for shortest lead time - getting customer value done as quickly as possible -, organisational agility and learning, LeSS is worth considering.
LeSS addresses the root causes in your development organisation by eliminating local optimizations and moving away from a focus on resource utilization. Typically, there is a lot of local optimization happening in organisations where the focus on the product and the customer is completely lost. LeSS addresses this by minimizing single function groups, specialized teams and single specialists.
LeSS - just like Scrum - creates the opportunity for people to see problems in their work, to solve those problems and to take action to implement the solutions. This will be harder and take longer than packaged ‘solutions’, but when you go through it you will see much better and long lasting results.
You often say: LeSS is for scaling development and descaling the organisation. Can you elaborate?
In LeSS, the majority of the teams are feature teams. Feature teams are multi-disciplinary, cross-component and self-managing teams that have a whole product focus and work on customer centric features. Once you organise with feature teams, you will find that a lot of the overhead coordination, special roles and processes are no longer needed. This extra work is introduced when you work with component teams. Component teams are teams that work on a part of a customer feature - their component - for example the front-end or the back-end of a web application. More often than not, a customer feature requires work from multiple component teams. The dependencies between these component teams and their planning needs to be coordinated. This coordination is often done by special roles such as project managers and require additional planning meetings and artefacts. With feature teams, this unnecessary coordination, planning and artefacts are not needed anymore, hence you descale.
There is a conflict between being more prescriptive and leaving the ownership to the teams. How did you solve that?
People will improve their processes and practices if they own them. Ownership comes when the processes are created by the people themselves. Therefore, too much prescription and the people will not take ownership. On the other hand, if there’s too little prescription anything can happen. Therefore, the question becomes: how can we find the balance between prescriptiveness and laxity?
Just like Scrum, LeSS finds this balance by having a minimal framework that creates transparency about the process, product and organisation. With this transparency, the people can inspect what is going on and take appropriate action to improve their processes and practices themselves.
How should one build up teams in a scaled environment? (Feature Teams)
In large development groups you typically have teams that work on their own component for years and have become specialists in their area. There is not much understanding of other components within those teams. Typically, these teams locally optimise their component work and do not work on customer centric features.
In LeSS, the majority of the teams are feature teams. Moving to feature teams means that people will be working across components. This requires learning new components, new technology and sharing your knowledge with your team members. It takes time, patience and learning but it will lead to increased performance and agility in the organisation.
Growing a feature team is done along two scales. One scale is about the activities that a team can perform. Does the team write code only? Or does it also do functional testing, analysis and design? The second scale is about work scope. Does the team focus on a single component? Or does it focus on a sub-system, an application or the whole product?
At the two extremes we have on the high end, the ideal feature team that solves the customer problem by co-creation with its customers. On the low end, we have a component team that only works on a small module and writes code. In between these two extremes is a lot of space for growth.
In LeSS, we have a simple tool called “Feature Team Adoption Map” that you can use to plan your feature team adoption. The adoption is about expanding the team activities as well as the scope of the team along these two axis.
Who has already adopted LeSS and what have been the outcomes?
LeSS has been adopted in a wide range of industries and companies all over the world. Ranging from system developers like Nokia and Thales to financial institutions like JP Morgan and BMW. You can find a lot of case studies on the less.works website.
Who should look at the LeSS framework?
Development companies that need to scale Scrum to large development groups should consider LeSS. If you are developing long-lived products, with multiple teams, across multiple sites then LeSS can be an opportunity for you. If Agile has failed to deliver on all those promises and expectations you had, then LeSS is an opportunity for you too.
Because LeSS is an organisational design, it requires top-down leading to adopt and therefore it is very much of interest to the leadership.
How will a company change with LeSS and how long does it take?
In LeSS we suggest a deep and narrow adoption approach over a broad and shallow approach. This means that you work to change a group of up to 9 teams per adoption step. Once this group is making progress you can change a second group and so on. You can expect to experience the first business benefits within 6 months.
One thing to realise is that you are never finished. The goal is to become a learning organisation. LeSS, just like Scrum, creates the opportunity for people to see problems in their work, to solve those problems and to take action to forever improve.
Not a day goes by without new mobile payment apps popping up or the Original Equipment Manufacturers, also called OEMs, launching their own mobile wallets (Apple Pay, Samsung Pay, Android Pay) in additional countries. Especially Switzerland plays an interesting role by focusing on the payment solution TWINT to solve the local mobile payment needs. However, regardless of the payment app and underlying technology, all solutions need to balance usability and security in order to justify a valid business case.Mehr erfahren
Autonome Fahrzeuge // Die autonomen Postautos haben keinen Fahrer und können dank ihrer leistungsfähigen Sensoren problemlos navigieren. Zum ersten Mal testet ein Unternehmen diese Technologie in der Schweiz im öffentlichen Raum.Mehr erfahren
Heutzutage gilt agile Softwareentwicklung als Erfolgsfaktor bei besonders innovativen und zeitkritischen Projekten durch ihre schnelle Reaktionsfähigkeit auf Veränderungen im Markt. Wie aber ist es möglich, die Software-Architektur so zu gestalten, dass der vermeintliche Widerspruch Nachhaltigkeit versus Agilität, nicht nur elegant gelöst wird, sondern sogar noch zu einer besseren Architektur führt.Mehr erfahren
Banks spend a vast amount of time researching and collecting data about clients, but often lack the bigger picture of connecting these separate data piles from various systems. Data alone is worthless, but connected and turned into information using an identity database, new possibilities such as reducing the cost per client, increasing quality of service and anticipating a client's actions are possible.Mehr erfahren