LeSS without Scrum

About this Publication

LeSS without Scrum provides an experience where we apply LeSS organization design elements for large-scale Agile adoption without first implementing Scrum teams. This illustrates an organization-first approach, in contrast to the more common team-first approach. The proper organization design provides the solid foundation for the further coaching and amplifies its effectiveness.


The usual approach to scale Scrum in my experience is to start with one team as pilot then scale. This experience report provides a different approach. We focused on organization design first, without having proper Scrum implementation at a team level. We used the main design elements from LeSS, but kept team level in tact. Then, we created demand to help some teams move toward self-organization. We used the same approach in two different product units from the same company. The two units represented cases of different sizes, as cases of LeSS and LeSS Huge respectively.

The proper team structure following LeSS gave all teams a solid foundation to perform. All teams were able to work with stakeholders and deliver value on sprint basis. The teams with effective coaching performed better in terms of self-organization and continuous improvement. This indicates that organization design is a first-order factor for change, and combining it with effective coaching would create the best results.

2.      Background

As a practitioner, I got deeply involved in one of the first LeSS adoptions in Nokia Networks back to 2006-2007. In fact, there was no name as LeSS yet. Many experiments we did became part of the first two LeSS books [1, 2] by Craig Larman and Bas Vodde.

This experience is from two product units of the same telecom company in China during 2015-2016. I worked as a consultant to help their large-scale Agile adoption. The telecom company is huge, having tens thousands of people on product development. They are organized in business units and product units, which is usually hundreds to thousands of people. They had a big Agile movement a few years ago, but was not considered success. Though, they had implemented “iteration” and “continuous integration”. Their “iteration” was a small waterfall at best, and their “continuous integration” was more on daily build and test automation than developer practice of continuously integrating their work.

In the middle of 2015 when I was hired as external consultant to help their large-scale Agile adoption, my contact had some candidate product units in mind, but there was no decision from any of them that LeSS or LeSS-like approach was the way to go. Therefore, my contact and I did a few LeSS sessions to raise the awareness and build the proper understanding about what this means. It came with no surprise that they realized that the change was bigger than their initially anticipated. In fact, no product unit expressed that they would jump in immediately after the initial workshop, and all hesitated. Many of them never actually took the next step. Eventually, two of them decided to move ahead, which became the two cases in this experience report.

2.1      Why we didn’t start with one Scrum team

It is very common to pilot Scrum in project, as project team is cross-functional and end-to-end by nature. With the traditional matrix structure, the project team is not a real team, but a group consisting of people who focus on their respective specialty areas, such as front-end development, testing, etc. Even though it is possible to align everyone towards common goal and take shared responsibility without the permanent organizational change (i.e. change reporting line), the alignment is fragile. Considering all other challenges such as lack of capability in collaboration and engineering, the lack of motivation due to missing structural support makes it even more difficult to succeed. In my experience, a lot of teams faltered after some time. Some organizations move further by changing the organization structure, while others regress to the status quo.

Figure 1. How Team Design and Coaching Jointly Affect Team Performance

This is best illustrated by Richard Hackman’s work. In his classical book “Leading Teams” [3], the relations as shown in figure 1 among team performance, team design and coaching are insightful. In short, well-designed structure and effective coaching together create best effects, but organization design is first-order factor.

In Scrum, the ScrumMaster is responsible for providing effective coaching. In my experience, the initial ScrumMasters in most organizations are just starting to learn about coaching. When organizational structure does not support this, the complexity in needed change is overwhelming to them. The concept of coaching is foreign to my client, and it is hard for them to imagine a self-organizing team without an appointed leader. The chance of success would be very low if we pilot one Scrum team in existing organizational structure (without organizational redesign) and let an inexperienced ScrumMaster coach the team towards self-organization. Therefore, we took a different approach to focus first on establishing proper structure, and later increasing the coaching capability.

Another reason came from this particular assignment, as my consulting was supposed to create experience for my client in applying LeSS on their large-scale Agile adoption. Organization redesign is necessary in LeSS adoption. Most organizations try to avoid organization structural change, as they see it risky. And it is indeed, particularly when it involves hundreds even thousands of people. In fact, LeSS is aware of this risk, and explicitly suggests to make incremental change in very large scale, which is the case of LeSS Huge. However, it does require that in the “smaller” large scale, which involves approximately 50 people or less, to establish the complete LeSS structure at the start.

2.2      Product unit

One of the initial critical decisions in adopting LeSS is to define what the product is. In my client company, the development of almost all products are spread into multiple product units, which are organizational entities. Even though the product unit is responsible for a final product to the end customers, it usually has dependency to other units such as platforms or network management.

For example, Base Station as a final product to telecom operators such as China Mobile is built upon an internal platform, and dependent on network management. There are at least three product units involved to deliver the complete value - Base Station (not including platform), Platform (support multiple products, and Base Station is one of them), Network management (support multiple products, and Base Station is one of them). This is still a simplified view, while in reality, there are often many platforms involved.

In LeSS, “the definition of product should be as broad and end-user/customer centric as is practical.” [4] As we could only influence the head and management of product units in practicality, we decided to focus on “products” developed by product units.

The two product units we worked with happened to represent different sizes, one approximately 40 people and the other approximately 120 people, thus, providing cases of LeSS and LeSS Huge respectively. We first started with LeSS case in late 2015, then LeSS Huge case in 2016. There was some overlapping period when I worked with both units at the same time.

3.      Less case

3.1      Initial workshop

The product unit in this case develops a platform consisting of approximately 40 people. The platform offers functionalities such as extended OS (Operating System), communication, patching, etc. As they are in a lower layer, they have little dependency with other product units, but other units depend on them. The requirements to them are not directly customer requirements, but part of the solution defined by upper application layers, which could be another platform or the final product.

The initial workshop happened in August of 2015. The decision to have organizational structure change happened in late 2015, 3-4 months after the workshop. Meanwhile, we had a few deep discussions with the management team. This is usually the case as the organizational change is risky and involves much personnel change. Change starts before it starts.

3.2      Work design

The work design was around the creation of product backlog. The main changes are summarized in the figure 2.

Figure 2. Work Redesign

Collecting all the work and putting them into one prioritized backlog responsible by one owner was the key in organizing the work. Whether this backlog should be owned by one PO or multiple POs was another choice to make. We followed the LeSS rule to have one PO which is good for the product wholeness and transparency. In order to get it work in practice, i.e. not overloading PO, it is necessary for PO to focus on prioritization while have team make clarification as directly as possible with customers. We will elaborate more in 3.5 Sprint practices.

3.3      Team design

Before adopting LeSS, there were 4 development teams responsible for different domains, and one testing team. We reorganized them into 6 teams via a self-designing team workshop. We would like to create cross-functional feature teams out of functional feature/component teams.

Management and I worked out some constraints, and the initial list was as below.

  • Team size is 5-7 people
  • Team is cross-functional, consisting of developers and testers
  • Team is feature oriented, being able to complete end-to-end feature within the platform
  • Team is generic, being able to take any item from the shared product backlog

Regarding the last point, we were concerned if every team was generic without specialization, even though it provided the most flexibility, it raised the biggest challenge in keeping the sufficient productivity in the short term. There were 4 domains, and there would be 6 teams. We tried to balance these two factors, and eventually changed it to each team being able to work in at least 2 domains, while each domain having at least 3 capable teams. This refined constraint made each team still possible to have some level of specialization for efficiency, but meanwhile enabled the whole unit to follow one priority.

Then we moved on to design the agenda for the self-designing team workshop. We referred to some ideas shared in this article [6], and made a rough agenda like this:

  1. Opening (unit head highlights the motivation behind this)
  2. Volunteer for team leaders (see 4 ScrumMaster vs. Team Leader)
  3. Self-designing team cycle 1 (with initial list of constraints)
  4. Self-designing team cycle 2 (with refined list of constraints)
  5. Self-designing team cycle 3 (fixing “bugs” - unmet constraints)
  6. Create team resume and present to the whole group
  7. Wrap-up (participants share their feeling and comments at their will)

Each cycle ended up with a setup of 6 teams. In cycle 2, it started by asking participants to come up with additional constraints that would help form teams better. As they already saw one concrete setup from cycle 1, it was a lot easier. For example, they noticed that some teams fully consisted of senior people, while others only junior people. When this was raised, a short open discussion ensued and we did a consensus checking to refine the list by adding a constraint about seniority of the members in each team. In cycle 3, it started by asking the whole group to raise “bugs” for teams created out of cycle 2. Then, they self-organized to fulfill the remaining unmet constraints.

The whole workshop took 2.5 hours, and the outcome was 6 new teams created, as well as the charged energy to get started. The before and after state is summarized in the figure 3.

Figure 3. Team Redesign

3.4      ScrumMaster vs. Team Leader

One challenge for my client to adopt LeSS, more precisely Scrum, was introducing ScrumMaster role. ScrumMaster is a coach, while coach as a role is inexistent in traditional organizations. Meanwhile, a Team Leader role is commonplace and traditional organizations hold a Team Leader accountable for team performance. This contrasts to team accountability in Scrum and LeSS.

As it was clear that we could not reach the agreement on this, we decided to keep Team Leader role and define accountability a bit vaguely - shared by both Team Leader and team. This was not optimal, but that was our starting point. Later, we educated Team Leaders about coaching self-organizing teams, and created demand so that I was pulled to help some teams, which moved further than others in terms of self-organization. Some Team Leaders developed themselves into more ScrumMaster/Coach roles, but still kept their share of accountability for team results. As possible path forward, accountability might be removed from the Team Leader and given completely to the team some day.

3.5      Sprint practices

With proper organization structure in place, we pretty much implemented LeSS Sprint practices.

3.5.1  Backlog refinement & Sprint planning

As we had one PO and one product backlog for the six teams in the whole platform, we started with overall backlog refinement, which worked as mini-planning about how to do the further refinement among teams. PO and team representatives worked together to decide which items would be refined by which teams. We decided for some items to be done by some teams, while leaving other items open thus refined by multiple candidate teams. The final decision of which teams working on which items would be made in sprint planning.

Sprint planning happened jointly in a big common space. The participants included PO, all teams, and stakeholders such as SMEs, application developers (as the users of the platform), as well as support people. The jointness eased a lot the participation of all parties, as the item mapping between teams and stakeholders is n-to-n. For teams, they could meet various stakeholders relevant to those items they would develop in the same time and space; for stakeholders, they could meet various teams relevant to those items they requested in the same time and space. This joint sprint planning acted as an important enabler for teams to clarify the requirements directly with users and stakeholders.

Sprint planning part 1 is for understanding what to build. It started by having PO roughly presenting the product backlog and candidate items for the coming sprint. Teams would together decide which items were picked up by which teams. PO made sure that high priority items were distributed to multiple teams for risk mitigation. The decision for some items was already made during backlog refinement, and the decision for other items was made here. After the selection was done, teams in parallel clarified details and discussed about acceptance criteria directly with users and stakeholders. When there was a lack of clarity about item scope, PO was pulled into the discussion.

Sprint planning part 2 is for understanding how to build. It continued in the same big space. As teams selected different items from product backlog, they could split and do part 2 separately. However, they would benefit from doing part 2 in shared space, because it increased likelihood that they identified needs for coordination across teams. It was common to hear some team simply shouting that “we would need to make big change on component X in the next sprint, would any team want to have a joint discussion about the basic design?”, then other teams responded.

During planning part 1 or part 2, it is likely that some teams found that they could not take as many items as they initially thought, while other teams might be able to take more. As all teams were present, it was easy to adjust through self-organization among teams and PO.

3.5.2  Sprint review

In the beginning, we thought about inviting the same users and stakeholders to joint sprint review. It turned out that they were not very interested, as the platform mostly provides APIs and services. The learning and feedback already happened while they were being used - the integration with application. Thus, we switched our focus to ensure learning and feedback at sprint review to during the sprint. Eventually, we expanded our DoD to capture this. This further prompted us to ask “when would the application use this feature?” during sprint planning as one aspect of readiness. When learning and feedback happened during the sprint for specific items, we simply shared the learning, discussed about their implications and updated product backlog accordingly during sprint review.

3.5.3  Daily Scrum and cross-team coordination

It was not a hard sell to have a daily Scrum, even though some Team Leaders were still thinking of it as status reporting. Every time I visited them, I observed their daily Scrum and tried to ask powerful questions such as “what is our sprint goal?”, “what are most important risks for us to achieve our goal?”, “what slows us down?”, “what are most important tasks for us to achieve our goal?”, “how shall we adapt?”, etc. By letting team think of those by themselves and discuss about those together to make decisions on how to move forward, it opened up Team Leaders’ view on alternative ways of leading teams. Some of them got interested in coaching and started to learn about asking powerful questions. I focused on helping those who would like to grow into coaching type of Team Leaders.

Surprising or not? There had never emerged a need for SoS (scrum of scrums). Out of backlog refinement and joint sprint planning, teams usually had good idea about which teams they need to keep close communication during the sprint. They set up channels to coordinate in a decentralized way, which is in line with LeSS rule on cross-team coordination. One example was simply to have someone join other team’s daily Scrum.

Component guardians were introduced after moving to feature team. Initially, there was strict review process for teams to submit the design & code so that component guardians would review them before proceeding further. Soon, it was clear that it slowed down the development. We adapted through two ways, one was increasing the frequency of those reviews as well as promoting the small batch and frequent submission; the other was increasing the capability of people to have at least one member qualified for ensuring quality in its own team.

The whole group sitting together in one space certainly helped the cross-team coordination too. As well as the Community of Testing helped discover coordination needs among “testers”, who are interested in honing testing skills. This demonstrated two key points regarding LeSS view on coordination - using multiple channels to coordinate, and focusing on identifying the coordination needs.

3.5.4  Sprint retrospective and continuous improvement

We have already talked about some inspection and adaptation around processes such as review by component guardian, integration with application, etc. We experimented various ways and adapted based on the real experience and feedback. The processes were evolving, which is the essence of continuous improvement.

From the first Sprint, we introduced team level retrospectives. As Team Leaders were still accountable for team performance, the point of entry was to convince them that it would ease their job when team members contributed to the improvement. I facilitated retrospectives for all teams at least once, which demonstrated the difference that effective facilitation could make. Some Team Leaders became interested in facilitative way of leading teams, then, I worked with them more.

We started with one overall retrospective before the first sprint, with the whole group present. The reflection was done for the last release of 2-3 months. And we kept this rhythm of having overall retrospective with everybody. For overall retrospective in every sprint, only Team Leaders, PO and managers attended. We discussed about whether to involve team representatives and decided to start without them firstly, because retrospective was not even a normal way of working at the team level, and we would like to involve team members step by step in continuous improvement. At first, the organizational improvement was driven by Team Leaders and management together.

One focus in continuous improvement was to shorten the time from done product increment to shippable product increment meeting product level release criteria, as this reflects the agility. This had been a regular topic for quite a few sprints. Through systematically removing impediments and expanding DoD, it was decreased from roughly 2-week to 3-day in half-a-year.

Overall, there had been significant improvement on cycle time and productivity. The quality in terms of external  defects was low before the change, and it was kept at low level.


The product unit in this case develops a network security product, consisting of approximately 120 people. The product has two parts - web and equipment. There were 3 groups, one doing web interface in Beijing, and the other two doing the work in equipment in Hangzhou. Many features cut through web interface and equipment. The size of organization exceeded LeSS, and it was a case of LeSS Huge.

4.1      Requirement Area

RA (Requirement Area) [5] is the most important scaling technique in LeSS Huge, in response to the complexity for one PO to manage, regarding product backlog, number of teams, etc. Product unit is split into Requirement Areas, each consisting of several feature teams. Product backlog is split into Area backlogs, each containing all items in the area. Within each RA is essentially a LeSS adoption.

The critical decision in LeSS Huge adoption is the formation of RAs as grouping for both work and people. We considered to form 3 RAs for those 3 groups, but in essence, there were only 2 RAs, as both areas include web interface. Ideally, we would have dismissed Beijing group and moved people to join 2 real RAs. Due to the location difference, we decided to form 2 RAs and one development area. Those 2 RAs, on one hand, treated the development area as their external dependency; on the other hand, made use of CLI (Command Line Interface) for independent verification as much as possible.

Once we decided the RAs, it worked the same as LeSS case within each area. Usually, LeSS Huge adoption happens evolutionary with RA by RA. As we had only two real RAs in place, we decided to do this at once and supported both areas to make the transformation.

Another interesting decision was whether we would couple RA with line organization. RA is a tradeoff between the flexibility and the need for specialization. RA assumes that the workload from high value items in one area is stable during a relatively long period, say, one year rather than a couple of sprints. However, this was not the case. Release by release, each release roughly 3-6 months, we saw fluctuation in the high value workload. It was too painful to move teams in reporting lines with such high frequency, thus, we decided to decouple line organization from RA. To accommodate the fluctuation, we targeted to form one team in each area to be able to work for both RAs. [7].

4.2      PO team

There was one APO (Area Product Owner) and one area backlog for each area. One overall PO, two APOs and program managers, who remained as interface towards outside, together formed PO team for the whole product.

The overall PO was one of the most senior people in the organization, who had the capability to work with multiple stakeholders and make tough prioritization decisions. However, we were not able to find APOs with the similar level of experience in the organization, which clearly showed the weakness in its product management. With the vision that APOs eventually need to work directly with stakeholders and make tough decisions on their own, the overall PO acted as teacher and coach for APOs to not only help them get the job done, but also build their capability.

4.3      Feature teams within RA

There were two main changes in terms of team structure within RA. One was to get testers integrated into feature teams permanently; the other was to make all teams share one product backlog.

Before the change, testers were loosely connected to development teams, and they were subject to change over releases. After the change, testers were integrated with teams and expected to stay together over releases.

Before the change, each development team worked on a certain specialty sub-area within the area, and essentially followed the priority within its sub-area. After the change, each feature team (development team with testers permanently integrated) worked on the whole area, and followed one shared priority within the whole area. [8].

We chose a different approach than the first LeSS case. In the first case, the team redesign enabled new teams to work across domains and follow one priority. In this case, we did not reform the teams, except the permanent integration of testers. The key was to create the flexibility by removing the constraint that one team could only take items in one sub-area. Considering that the skill difference among those sub-areas was not big, we thought that it would be feasible to let the existing teams expand their work scope with the support from other teams having the speciality, thus, decided to keep those teams.

4.4      Dependency

Regarding Sprint practices, most activities happened inside RA, thus, working almost the same as the first LeSS case. As this case was a real product, rather than a platform, it posed more complexity in terms of dependency. The product depended on network management and platforms, which were done by other product units. It was not practical to extend feature team across product units. Thus, we had to resort to other ways of managing dependency. As SAFe was used widely in many product units of the company, we essentially did PI (Program Increment) sync to manage dependency across product units, while adopting feature teams to remove dependency within product unit. While we were able to sync the relevant work into the same Sprint, the integration was done as continuously as possible within the same Sprint. However, out of sync across product units still happened quite often, as the underlying limitation came from the big structure - those product units essentially develop some kind of components.

Overall, this LeSS Huge case was still at early stage when I left, but the approach of organization design proceeding sprint practices was solid.


The experience had strong resonance on Richard Hackman’s finding about proper team design outweighing effective coaching as factors to influence team performance. LeSS’s strong focus on organization design reflects the same. Organization first approach provides an alternative way to the normal approach of piloting under existing structure.

It would be better if we had agreed on a vision of effective coaching for teams. This lack of agreement at organizational level limited how far we would go in terms of self-organizing teams, as it was left by chance to individual team leaders.

At tactical level, here is a summary for what we learned.

  • Use an incremental approach to expand domain specialization for more flexibility
  • Take a transitional path from traditional Team Leader to ScrumMaster/Coach
  • Enable self-organization across teams via joint Scrum events.
  • Enable one PO vs. multiple teams by getting teams on requirement clarification and feedback.

In a way, this experience report is not a full story. It ignores what happened before we got involved. For external consultant, the consent on organization redesign could be taken as prerequisite. However, for internal people, I would suggest to apply the art of the possible till the tipping point where it would be feasible to redesign the organization.

6.      Acknowledgements

I would like to thank my contact Guangjing Chen from the client company. We worked very closely during the whole journey, had lots of deep discussions about how to help those two product units move forward, and shared many great insights.

I would like to give my deep appreciation on the great help that Chris Edwards, my shepherd, has given me in writing this experience report.



[1] Craig Larman and Bas Vodde, “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum”, Addison Wesley Professional, 1st edition, 2008

[2] Craig Larman and Bas Vodde, “Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum”, Addison-Wesley Professional, 1st edition, 2010

[3] Richard Hackman, “Leading Teams: Setting the Stage for Great Performances”, Harvard Business Review Press, 1st edition, 2002







Copyright 2017 is held by the author.

About the Author

No bio currently available.