Craig Larman gave a keynote presentation about Large-Scale Scrum (LeSS) at the Agile Eastern Europe 2015 conference. InfoQ did an interview with Larman about LeSS and what makes it different from other scaling frameworks and using empirical process control to increase organizational agility.
Larman also explained how organizations can work with feature teams, and gave examples of how teams and stakeholders can be in direct contact with their customers and users and can work together to ship their product every sprint.
InfoQ: Can you briefly describe the Large-Scale Scrum (LeSS) framework for the InfoQ readers?
Larman: LeSS, or Large-Scale Scrum, is scaled Scrum. It is about applying the principles and ideas of Scrum to many teams working together on one product. These include empirical process control, shippable (and normally, shipping) product every Sprint (which heightens transparency, creates a strong feedback loop, and allows early delivery of value), and self-managing teams -- including self-management between the teams that are working together on one product.
As a general learning resource, readers can find out all about LeSS at less.works. There’s videos, graphical introductions to LeSS, case studies, and a lot more.
InfoQ: What is it that make LeSS different from other large-scale agile approaches like SAFe and DAD?
Larman: LeSS isn’t “Scrum contained within each team, with something different on top.” It seems that in some scaling approaches, to sort of quote Michael James, “Some scaling frameworks contain Scrum like a fire fighter contains a brushfire.” Rather, it is figuring out how to apply the principles and elements of Scrum that encourage empirical process control, transparency, self-managing teams, systems optimization, and so forth, when there are many teams on one product, in a Scrum-consistent way at scale.
A second key element is that LeSS is quite simple. There is very little defined within LeSS. And that turns out to be extremely important. Why’s that? I have a background in the Rational Unified Process (RUP) and came to see (during the 1990s) that a framework (like the RUP) with lots of prescription and definition really doesn’t work well in terms of adoption. One reason is that product groups are far too different; there are so many contextual elements and forces. A highly-defined-process-recipe approach doesn’t really work; it isn’t situational enough. Another reason is that strongly-prescriptive frameworks inhibit learning and adaptation, an absolutely key element in empirical process control. Another issue with frameworks that define lots of “answers” is that the people, including and perhaps especially the senior managers, sort of feel, “Well, we’ve bought this solution to our problems. We don’t need to deeply understand our root cause issues and system, and learn how to improve them in our unique way. Instead, we can just let the new adopted process recipe and the new hired expert coaches be the apparent solution to our organization design problems.” But that doesn’t lead to good things.
So LeSS, like Scrum, contains very few elements. And that isn’t a weakness or oversight. This is very intentional, recognizing that because of the need for strong empirical process control and learning, and the vast array of situationally different groups, a one-size-fits-all or detailed prescriptive framework, doesn’t really address the root issues. So there’s more learning and adaptation with less defined processes, and that’s a good thing. Hence the slogan, “More with LeSS.”
But here’s a very interesting insight and key point: Since “less prescription” seems like a good idea, the logical conclusion is to have essentially no definitions, details, or prescription. For example, in the Learning Organization movement, there’s just the principles of “systems thinking”, “personal mastery”, and so forth. Those are great! But, if you go to a big traditional telecom infrastructure equipment group and just say to them, “Hey folks! Transform! Systems thinking! Personal mastery!”, well, nothing will really change. Why’s that? Because this organization is in a Shu-context or phase of change. They need a certain minimal amount of concrete guidance for something to do.
That’s something I came to see in my career: a change system can be overspecified or underspecified, when dealing with a Shu-context organization. There’s a kind of sweet spot of “barely enough concrete guidance to make a real change, and no more.” And we feel and observe, and many others have as well, that Scrum is very much in that sweet spot. It contains just enough concrete structure in a status-quo system to kick-start a change that generates transparency and empirical process control. And LeSS is like that, for large-scale groups: barely enough concrete guidance to kickstart a system with real transparency and empirical process control. And vast empty space (not much is defined) for the situationally-specific learning and adaptation that must take place in each unique group.
Another differentiator of LeSS to some approaches is a strong whole-product focus. For example, there is only one Product Backlog shared by all the teams, and only one overall Product Owner, and all the teams work together in one Sprint to deliver one shippable product each Sprint. This is important for systems optimization, transparency, and focusing on the overall product. In contrast, if each team had their own so-called “Product” Backlog, there is much reduced transparency, increased local optimization, and other forms of fragmentation.
In addition to what I’ve answered here, readers may wish to read the “Why LeSS?” page at the less.works site.
InfoQ: You mentioned that LeSS includes empirical process control. Can you explain how organizations can use it to increase their agility?
Larman: First, to be clear on the meaning: empirical process control (EPC) implies a meta-process framework that does not specify many (or any) specific techniques, processes, or practices. Rather, it emphasizes transparency, inspection, and adaptation as the dominant theme.
For an organization to use EPC, the first step is subtractive. The organization has to give up the belief in some grand solution to their problems, some purchased system that they just have to install and follow. They have to give up the belief in and addiction to prescribed defined processes as the answer in domains such as product development that are inherently complex and variable, with high degrees of learning necessary.
And to use EPC, the next step is additive. The people will eventually have to add learning and adaptation over following a defined process recipe, as a core value and driver.
Another subtractive element is to remove the impediments to transparency, such as rewards or subtle punishments related to revealing what is truly going on, rather than a culture of “follow the plan.” I call it a culture of “managing variability rather than hiding variability.” Only when the barriers to transparency are removed can EPC flourish.
When you have successfully introduced EPC, then what have you got? Per definition, it is an organization that is constantly experimenting with learning and adapting the organizational system in response to feedback. Group structures, processes, techniques, sites, roles, and responsibilities are all open for revision and experimental change when the overarching mechanism is a learning organization based on EPC. That’s real agility within the outer loop of the organizational design surrounding and intersecting with the group adopting LeSS.
And of course at the inner loop of the LeSS group doing Sprints, this organizational agility means that the group can change direction at a lower cost and with less time, because the structures and processes are not baked into the organization.
So then the LeSS group can turn on a dime, for a dime. That’s agility.
InfoQ: In your keynote at Agile Eastern Europe you suggested to work with feature teams instead of using component teams. Can you elaborate why?
Larman: First, to define our terms, a component team is a team that works on a subset of code, a component. And associated with component teams is private code. So for example, a team of five programmers who work on the UI layer, and a group of six programmers who work on server-side subsystem-X, and so forth.
Before analyzing any further, I want to make clear that component teams aren’t “good” or “bad.” Goodness or badness in an organizational design depends on what the group wants to optimize the system for. For example, a military defense group can deliberately decide to optimize an organizational design (for product development) for maximum secrecy, or maximum ignorance of “the whole.” Single-function teams and silos with lots of handoff, where each team only does a part of the work, support that optimizing goal. And one can make valid arguments for when that’s appropriate.
But usually, product groups want to optimize the system to reduce concept-to-cash cycle time. Or organizational agility. Or at least they say they do! But the interesting thing is that when one analyzes their current design with respect to that goal, it is often inconsistent.
For example, if a group is organized into component teams, a key point to see is that a complete end-to-end customer requirement will usually span multiple components, such as “front end and back end.” But of course in large-scale development it isn’t just 2 components, it may be 5 or 10 components. So in that case, how must the work be organized? Let’s start with end-to-end requirements analysis. Who will do? It can’t be one of the component teams, as we might not even know which component teams will be involved, and even if we did, it’s sort of arbitrary which would do it. So instead we stick a “requirements analysis” group in front of the component teams that do this work and create a document to hand off to the component teams. Who’s going to do the end-to-end testing? Which of the five component teams? It isn’t clear. So we stick a testing group after the component teams to do that. In fact, it is more complex than that, but I’ve simplified the analysis. But the key point is that the choice of component teams as a constraint in the design then creates a sequential life-cycle process, with silos of single-function teams handing off work to other groups, with weak feedback loops, more WIP, and more information scatter.
Now this structure is associated with more schedule overruns and cost overruns than feature teams. If people actually want to optimize the component-team organizational system for reduced cycle time, this model is not consistent with that. Similarly, if you introduce lots of change into this system, the cost or overhead of change is higher than in a feature team model. So if a goal is to optimize for agility, it is not consistent with that goal.
I want to stress again that this is not a question of good or bad. It is a question of asking if the organizational design is consistent with the intended system optimization.
But does this mean we are saying to only have feature teams in LeSS, and no component teams? No.
LeSS includes the concept of Principles and Thinking Tools, which are a foundation of LeSS. These include: Systems Thinking, Lean Thinking, Queueing Theory, and False Dichotomies. People who take an idea or guideline, like “prefer feature teams to component teams if you want to reduce cycle time or increase agility” and mutate that statement into the incorrect statement, “In LeSS, you can only have feature teams” are demonstrating the false dichotomies thinking mistake. We recommend a more nuanced insight than superficial “A, not B”, or “A good, B bad” statements.
For more information on this big subject, folks can read about feature teams and component teams.
InfoQ: Can you give some examples of how product owners, teams, and stakeholders work together on a daily base to be able to ship every sprint using a LeSS approach?
Larman: Because LeSS emphasizes a whole-product focus, and there is only one Product Backlog shared by all teams (not a per-team so-called “Product” Backlog), there is only one overall Product Owner.
So part of this question becomes, “how can one Product Owner work with all the teams, to ship every Sprint?”
One key point in LeSS is that the Product Owner is a “real” Product Owner; it isn’t another name for business analyst or project manager. She is, for example, the Product Manager responsible for the product and its ROI. And so this real Product Owner has a significant outward focus to customers, competitors, and so on. But since the Product Owner also has some inward focus towards the teams, how can she avoid becoming overloaded?
One key answer is in LeSS is that the Product Owner focuses on direction and prioritization (or “ordering” in Scrum) but not on details and clarification. As far as possible, in LeSS, all discovery of details and clarifying items is done by the teams (normal Scrum cross-functional cross-component teams of multi-skilled people) directly with real customers and users.
So in Product Backlog refinement (PBR), which is a key time-consuming activity to get items “ready” for upcoming Sprints, the Product Owner doesn’t have to be deeply involved in the details. She may, for example in LeSS, participate in a once-per-Sprint 3-hour overall PBR meeting with some representatives from all the teams, focusing on broad direction and prioritization, and light-weight analysis together. But the deep-dive refinement of items is done in separate (or multi-team) PBR meeting afterwards, in which the teams do most of the detailed refinement in direct collaboration with customers and users.
In this way the Product Owner is not a bottleneck or level of indirection between the teams and the real users. Rather, she is a matchmaker who helps the teams and users directly connect. This leads to many benefits in terms of reduced handoff and information scatter, increased co-creation of teams and users, and so forth, and… it reduces the effort that the Product Owner has to be involved.
Coming back to the original question, another way that people work together to ship every Sprint in LeSS is via continuous integration. Now, I’ve learned over the years that almost no one seems to know what continuous integration means. I go to a new client and ask, “Are you doing continuous integration?” And do you know what they answer? “Oh yes, we have a build server!” But that’s got very little to do with continuous integration.
Let me share with you the surprising meaning of continuous integration: to integrate continuously.
And that’s got very little to do with build servers. Some group can have build servers out the whazoo, but if, for example, developers are checking out code and keeping it checked out for long durations (such as several hours) before merging it back with everyone else’s code, then there is delayed integration. Or of developers are working on separate branches, there is delayed integration.
So in LeSS we have to have real continuous integration, a change in developer behavior. For example, that the check out and merge-with-everyone-else cycle time is as short as possible, such as each five-minute unit-TDD cycle. And that all the teams are avoiding branches at working together on “master” or “head of trunk” together.
That’s critical in LeSS to enabling the ability to ship every Sprint. And this leads to more “coordinating in code” rather than in “coordinating in planning”. It moves people to more of a “pull over push” model of working.
Another aspect of this question is coordination around architecture. In LeSS we recommend communities for cross-team concerns. So for example, we recommend a design/architecture community of members from regular feature teams that come together each Sprint or as necessary, to do agile modeling together for example, to coordinate about broad design design issues.
And finally, dialing in to the specific question of planning the current Sprint to create and ship something at the end of the Sprint, before Sprint Planning One the one Product Owner decides the order of items to offer all the teams. Then in Sprint Planning One, which is one common meeting for all the teams together (or with representatives from all teams), she lays out her offer of items to all the teams (such as putting cards on the table), and then stands back and lets the teams self organize to decide what items they are going to volunteer for. It’s quite simple.
And then each team does their own Sprint Planning Two, which is essentially the same as in one-team Scrum. However, if there is lots of coordination between teams, some may to this meeting together in the same room to increase talking.
For a more complete answer, readers may find the detailed explanation of the LeSS framework useful.
InfoQ: Do you have examples of how organizations have made it possible for their teams to work directly with real customers and users?
Larman: Sure, for example a recent group I’ve worked with for a LeSS adoption is at JP Morgan. A general description of the story is covered in this InfoQ article. Specifically on your question, the key point is that the traditional groups that act as levels of indirection between the teams and the users are removed. In this case, the business analyst and project manager groups were removed, and for example, the ex-BAs then joined regular feature teams and started to become multi-skilled workers. Then in PBR meetings each Sprint, the hands-on users (such as bank trade-handling analysts) come into face-to-face meetings with one or more teams.
How do organizations make that possible? By higher management agreeing to change the organizational design to support this, and then by changes of behavior encouraged by the ScrumMasters and Product Owner to connect teams and users.
InfoQ: Are there any new new developments around LeSS that might be interesting for the InfOQ readers?
Larman: We published the first two LeSS books in 2008 and 2010. They were “ha”-level books (in the Shu-ha-ri metaphor) of 600 experiments that may or may not be appropriate in some context.
Since that time, there’s been an explosion of interest in LeSS, and so we’ve tried to make it easier for people to adopt, and to support it better. So we’re very soon about to publish the third LeSS book, which is more of a Shu-level prequel and overview, and as an on-line complement to the book, the less.works site.
About the Interviewee
Craig Larman is the co-creator (with Bas Vodde) of Large-Scale Scrum (LeSS), and an organizational-design consultant for enterprise adoptions and very large-scale product development with LeSS. In addition to being one of the first Certified Scrum Trainers, since 2004, he has helped groups with LeSS adoptions, such as J.P. Morgan, Ericsson, UBS, Xerox, bwin.party, BAML, ION Trading, Valtech India, and more. He is the co- author (with Bas Vodde) of the upcoming book Large-Scale Scrum: More with LeSS, and the two existing LeSS books, Scaling Lean & Agile Development: Thinking & Organizational Tools and Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development with Large-Scale Scrum.
