This blog is part of a series of previews from my upcoming book Coaching Agile Organisations

In the first part of this blog series, I explained how to identify the organizational elements to include in your product definition. In this blog, I explain how you can refine your product definition to organize into effective cross-functional teams.

Some elements are more equal than others.

Below you can see a simplified view of the organizational elements at one of my customers.

We discovered that some organizational elements are required more than others to develop product features. The more often a particular element is required, the stronger the dependency. We visualised the strength of the dependencies with a heat map—see the figure below for a anonymised simplified example. 

The y-axis shows product features. The x-axis shows the organizational elements. A green area indicates an element that is needed to deliver the feature.

The elements that heat up the most indicate the strength of the dependency—these are the hotspots. Note that the WEB element is needed in 28% of the time to develop product features, the APP 20% of the time, while Legal is required only 7%.

NOTE: Avoid focusing too much on the percentages, this is not an exact science but rather a guide to help you move forward. Next to percentages I also successfully used different scales to estimate the strength of the dependencies like: Seldom, Now and Then, Frequent.

When all the teams can pick up any work that comes in and deliver it completely to done, you have maximum adaptability. That would mean that each team has the skills to cover the whole heat map. Unfortunately, this was not the case for us. There were just too many technologies and domain knowledge for the teams to comprehend. Also, there is value in team specialisation. The solution was for teams to specialise in the customer domain first, and then to learn about the other product domains as needed.

Learning can take many months or even years, and in the meantime, we needed to determine how to start. Which organisational elements should the teams cover first and which shall we add later? This decision depends upon the strength and type of the dependencies.

Find the balance between adaptability and speed 

When a team can work on all components but only one feature, a team covers a complete row, as drawn in the figure below. Such a team has no external dependencies; hence they probably deliver fast. On the other hand, when a team covers all features but only one component, a team covers a complete column in the heatmap. Such a team can work on all feature-parts; hence they can adapt to all work that comes in, but cannot deliver end-to-end. 

Therefore, the size of the heat map area that a team covers strongly determines its

  • feature delivery speed
  • flexibility to pick up work from the product backlog.

Our challenge was to find the optimal balance between speed and adaptability in our 11 team context, and that depended upon several variables:

  • The teams’ cognitive capacity. When teams specialise in a customer domain they can still work on customer features without needing to understand the other customer domains of the product.
  • The type of dependencies between the elements. This helps the teams determine which organizational elements to cover first and which later.

Specialise in the Customer Domain

Our product was a large insurance system. We used interviews and questionnaires to determine where users spend most of their time when using the product. It turned out that there were a couple of main groups of users. (For this blog, I just use the 2 groups Claims and Evaluation. and call them red and yellow.) Some users mostly used the red-colored features—red area— while the other group primarily used the yellow-colored features—yellow area. The orange features are used by both sets of users—they overlap or intersect both red and yellow areas. 

The red and yellow areas let the teams specialize in a customer domain—see Requirement Areas in LeSS (less.works) and Value Area Scrum pattern (scrumbook.org). This reduces the cognitive demand on the teams.

The next step was to find the most significant heat map area that the teams could cover. 

The type of dependencies between the elements

We used the following rules to decide which elements to include from the beginning and which to add later.

  • Rule 1 – Contain reciprocal dependencies within one Value Area: The work of one team is input for another team and vice-versa, and there is uncertainty about how to accomplish the task, which makes frequent alignment necessary
  • Rule 2 – Ensure sequential dependencies between Value Areas with iterative planning: A team is dependent upon the work done by another team. Applicable to work with low uncertainty and predictable work.
  • Rule 3 – Manage pooled dependencies across Teams and Value Areas with simple coordination rules: For example, the sharing of a single test environment, or dependency of a person with a scarce skill.

Below you can see an example result for the red Value Area.

The Web, App, Siebel, Portal components are used often together and their interdependencies are reciprocal. The teams in the red area decided that they woud need to cover at least these elements.

Furthermore, you can see that the area has a pooled interdependency with Legal, and that it is a relatively strong dependency. of 14% The weakest interdependency is with Sales Force. We choose not to include Sales Force initially and only add it when the teams mastered the other elements. Legal was also not included because it was a pooled dependency.

The yellow Value Area below has a different set of dependencies.

The teams decided that they needed to cover at least the APP, Sales Force, Siebel and WEB components

For this area, Legal is not needed at all. And there is a weak sequential dependency on Portal. We decided to not include Portal in the first step. In the exceptional case that a feature needed a change in Portal the teams would coordinate with the red-area to get it done. We also used these as opportunities to learn more about Portal.

How to handle the features in the intersecting orange area? A solution is to decide based on the feature itself.

For example, F10 could be picked up by either the red or yellow area. F18 require only APP and can be picked up by the yellow area. The only complicated feature is F11. It requires Sales Force and Portal which neither the red or yellow area possess. So, how to handle this one? Well…., remember the golden rule of Scrum Mastership: “Always ask the team.”

Final Result

The product definition includes all elements, but we choose to not include Legal skills in any of the teams from the start. Why? Because it is a pooled and weak dependency. Also, the teams felt they were not yet able to cover more skills right from the start. Instead, Legal became the next activity to include in their Definition Of Done.

In the unfrequent case when a feature requiring Legal skills would appear on top of the Product Backlog, we would plan for that by working together with Legal in refinement events and during the Sprint.

At Sprint Planning, the team that selected that feature would then coordinate to work together with someone from Legal to get the feature done. Preferably, the Legal person(s) would also use the opportunity to teach the team so that they understood a little bit more about Legal at the end of the Sprint. When a team keeps selecting to work on features with a Legal part, eventually they learn enough to add Legal to their Definition Of Done. Bas Vodde calls this accidental specialization.

NOTE Not all teams need to know everything about all element in the Product Definition right from the start. Teams can have their own speciality as long as all teams as a group can pick up all element from the top of the Product Backlog.

The first ever LeSS conference was held in Amsterdam on August 30 and 31. An amazing 186 participants from Australia, Japan, the USA, Finland, Singapore, Switzerland and many more joined us for 2 days of sharing, learning and self-management. 

We, the organisers, did not want it to be a commercial conference, in the sense that there would be booths and sponsors influencing the speaker list and so on. We wanted it to be about practitioners sharing real world insights about LeSS adoption. And about letting the world know that there is a way to Scale Scrum and keep its values. We also wanted people to experience LeSS in person.

For the practitioners, we introduced an Experience track with all kinds of case studies on LeSS and LeSS huge adoptions. 

For experiencing LeSS in person, we introduced an experiments track. We did 3 main experiments.

  1. Having a team based conference;
  2. Having a Open Space parallel to all other sessions;
  3. Forming into communities. 

Furthermore, we did not plan for breaks, only for lunch; did not have a program printed; and we did not have a single person who was in charge. I remember that the people of the venue were searching for the one person to make all decisions, but this person was not there. We all made decisions and leadership emerged.

It was fun for us, confusing for some and insightful for all.

Different kind of conference

So, the LeSS conference was a little bit different to a ‘traditional conference

Traditional conferencesLeSS conference
Program printed and stableProgram only online and changing.
Drinks, beer and wine costs extraDrinks, beer and wine included.
Price over Euro 1000Price Euro 250
Organisers guess what people need and create appropriate program with tracks and timelines.People need to decide for themselves and decide what works for them
People work as individualsPeople work in teams
Mainly consultants doing talksMainly practitioner doing talks
There is 1 person in the leadOrganisers use situational leadership
You expect to be entertained and sit backYou are encouraged to actively participate and take ownership of your learning.
Make moneyNeeded to add money out of pocket 🙁
1 t-shirt3 t-shirts

Team experiment results

The teams-based conference experiment is considered a success. We now know that we are going to repeat this at the next LeSS conference in London 2017. A lot of people told me that they really enjoyed working with the team; getting to know people and socialising was good, and especially the discussions after the sessions.

“…people in my team went to the same talk but had very different views on what was said…the discussions we had gave some great insights…”

Of-course not everybody enjoyed the team experiment, but then again you cannot please everybody all the time 🙂

Community experiment results

The community experiment is considered a success also. We now know that we are not repeating that one :). But I am actually happy with the results. A number of new LeSS communities started in Berlin, The Netherlands and also online using Slack and our LinkedIn group is growing rapidly. @Viktor is having a busy time accepting all the requests.

What’s next

We are already planning for the next LeSS conference in 2017; it will be in London. We are also already thinking about new experiments to do. So, if you have suggestions the coming year, please share them with us.

Oh, yes, we do not want to loose any money next year and will aim for break even.

Hope to see you in London next year.

Patrick Kasper from ti&m interviewed Cesario Ramos on Large Scale Scrum (LeSS). In this interview Cesario answers some common questions that people have about LeSS. Like for example “The slogan of LeSS is: “more with LeSS” – what does this mean?”.

The original results of this interview can be found here

You can find a copy the interview below.

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.

Scaling Scrum & Agile has become a very popular topic over the last ten years. You can tell by the number of papers, talks, trainings and certification programs around it. Agile has become its own industry, as more and more enterprises want the benefits that Agile can promise.

Over the last twenty years we have been rather successful at getting Scrum to work with single Scrum Teams. Nowadays, we want to use Scrum with tens or even hundreds of teams, and an overly simplified approach to scaling might introduce big problems. 

Read the full article .