This chapter is from the book
This chapter is from the book
This chapter is from the book
LeSS
LeSS is Scrum—Large-Scale Scrum (LeSS1) isn’t new and improved Scrum. And it’s not Scrum at the bottom for each team, and something different layered on top. Rather, it’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible. Like Scrum and other truly agile frameworks, LeSS is “barely sufficient methodology” for high-impact reasons.
Scaled Scrum is not a special scaling framework that happens to include Scrum only at the team level. Truly scaled Scrum is Scrum scaled.
...applied to many teams—Cross-functional, cross-component, full-stack feature teams of 3–9 learning-focused people that do it all—from UX to code to videos—to create done items and a shippable product.
...working together—The teams are working together because they have a common goal to deliver one common shippable product at the end of a common Sprint, and each team cares about this because they are a feature team responsible for the whole, not a part.
...on one product—What product? A broad complete end-to-end customer-centric solution that real customers use. It’s not a component, platform, layer, or library.
• Background •
In 2002, when Craig wrote Agile & Iterative Development, many believed that agile development was only for small groups. However, we both (Craig and Bas) became interested in—and got increasing requests—to apply Scrum to large, multi-site, and offshore development. So, since 2005 we have teamed up to work with clients to scale up Scrum. Today, the two LeSS frameworks (smaller LeSS and LeSS Huge) have been adopted in big groups worldwide in disparate domains:
telecom equipment — Ericsson & Nokia Networks1
investment and retail banks — UBS
trading systems — ION Trading
marketing platforms and brand analytics — Vendasta
video conferencing — Cisco
online gaming (betting) — bwin.party
offshore outsourcing — Valtech India2
In terms of large, what’s a typical LeSS adoption case? Perhaps five teams in one or two sites. We’ve been involved in adoptions of that size, of a few hundred people, and up to a LeSS Huge case of well over a thousand people, far too many development sites, tens of millions of lines of C++, with custom hardware.
More LeSS Learning
To help people learn and based on our experiences with clients, in 2008 and 2010 we published two books on scaling agile development with the LeSS frameworks:
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum — explains the thinking, leadership, and organizational design changes.
Practices for Scaling Lean & Agile Development: Large, Multi-site & Offshore Product Development with Large-Scale Scrum — shares hundreds of concrete experiments for LeSS, based on our experience with clients; experiments in product management, architecture, planning, multi-site, offshore, contracts, and more.
This book—Large-Scale Scrum: More with LeSS—is the third in the LeSS series, a prequel and primer. This book synthesizes, clarifies, and highlights what’s most important.
Besides these books, see less.works for online learning resources (including book chapters, articles, and videos), courses, and coaching.
• Experiments, Guides, Rules, Principles •
The first two LeSS books emphasized: There are no such things as best practices in product development. There are only practices that are adequate within a certain context.
Practices are situational; blithely claiming they are “best” disconnects them from motivation and context. They become rituals. And pushing so-called best practices kills a culture of learning, questioning, engagement, and continuous improvement. Why would people challenge best?
Therefore, the earlier LeSS books shared experiments we and our clients have tried, and we encouraged—and encourage—this mindset. But over time we noticed two problems with the only-experiments mindset:
Novice groups made unskillful decisions to their detriment, adopting LeSS in ways not intended, with obvious problems; e.g. groups created Requirement Areas with one team each. Ouch!
Novice groups asked, “Where do we start? What’s most important?” They understandably couldn’t see the key basics.
Based on this feedback we reflected and returned to the Shu-Ha-Ri model of learning: Shu—follow rules to learn basics. Ha—break rules and discover context. Ri—mastery and find your own way. In a Shu-level LeSS adoption, there are a few rules for a barely sufficient framework to kick-start empirical process control and whole-product focus.1 These rules define the two LeSS frameworks that are introduced soon.
To summarize and build on these points, LeSS includes:
Rules—A few rules to get started and form the foundation. They define the key elements of the LeSS frameworks that should be in place to support empirical process control and whole-product focus. e.g. Hold an Overall Retrospective each Sprint.
Guides—A moderate set of guides to effectively adopt the rules and for a subset of experiments; worth trying based on years of experience with LeSS. Guides contain tips. Usually helpful and are an area for continuous improvement; e.g. Three Adoption Principles.
Experiments—Many experiments that are very situational and may not even be worth trying; e.g. Try... Translator on Team.
Principles—At the heart, a set of principles—extracted from experience with LeSS adoptions—that inform the rules, guides, and experiments; e.g. whole-product focus.
A good way to look at LeSS is visualized in the LeSS complete picture:
)
The LeSS complete picture will order the way we introduce LeSS:
LeSS principles, up next
LeSS frameworks (defined by the rules), in the rest of this chapter
LeSS guides, in the following chapters of this book
LeSS experiments, already available in the first two LeSS book
• LeSS Principles •
The LeSS rules define the LeSS framework. But the rules are minimalistic and don’t answer how to apply LeSS in your specific context. The LeSS principles provide the basis for making those decisions.
)
Large-Scale Scrum is Scrum—It isn’t new and improved Scrum. Rather, LeSS is about figuring out how to apply the principles, rules, elements, and purpose of Scrum in a large-scale context, as simply as possible.
Transparency—Based on tangible “done” items, short cycles, working together, common definitions, and driving out fear in the workplace.
More with less—We don’t want more roles because more roles leads to less responsibility to Teams. We don’t want more artifacts because more artifacts leads to a greater distance between Teams and customers. We don’t want more process because that leads to less learning and team ownership of process. Instead we want more responsible Teams by having less (fewer) roles, we want more customer-focused Teams building useful products by having less artifacts, we want more Team ownership of process and more meaningful work by having less defined processes. We want more with less.
Whole-product focus—One Product Backlog, one Product Owner, one shippable product, one Sprint—regardless if 3 or 33 teams. Customers want valuable functionality in a cohesive product, not technical components in separate parts.
Customer-centric—Focus on learning the customers real problems and solving those. Identify value and waste in the eyes of the paying customers. Reduce wait time from their perspective. Increase and strengthen feedback loops with real customers. Everyone understands how their work today directly relates to and benefits paying customers.
Continuous improvement towards perfection—Here’s a perfection goal: Create and deliver a product almost all the time, at almost no cost, with no defects, that delights customers, improves the environment, and makes lives better. Do endless humble and radical improvement experiments toward that goal.
Lean thinking—Create an organizational system whose foundation is managers-as-teachers who apply and teach lean thinking, manage to improve, promote stop-and-fix, and who practice Go See. Add the two pillars of respect for people and continuous challenge-the-status-quo improvement mindset. All towards the goal of perfection.
Systems thinking—See, understand, and optimize the whole system1 (not parts), and use systems modeling to explore system dynamics. Avoid the local sub-optimizations of focusing on the efficiency or productivity of individuals and individual teams. Customers care about the overall concept-to-cash cycle time and flow, not individual steps, and locally optimizing a part almost always sub-optimizes the whole.
Empirical process control—Continually inspect and adapt the product, processes, behaviors, organizational design, and practices to evolve in situationally-appropriate ways. Do that, rather than follow a prescribed set of so-called best practices that ignore context, create ritualistic following, impede learning and change, and squash people’s sense of engagement and ownership.
Queuing theory—Understand how systems with queues behave in the R&D domain, and apply those insights to managing queue sizes, work-in-progress limits, multitasking, work packages, and variability.
• Two Frameworks: LeSS & LeSS Huge •
Large-Scale Scrum has two frameworks:
LeSS. 2–8 Teams
LeSS Huge. 8+ Teams
The word LeSS is overloaded to mean both Large-Scale Scrum in general and the smaller LeSS framework.
The Magic Number Eight
Actually, eight isn’t a magic number, and if your group can successfully apply the smaller LeSS framework with more than eight teams, great! But we haven’t seen that... yet. It’s just an upper-limit empirical observation. And in some cases, such as varied complex goals with multi-site inexperienced foreign-language-only teams, it could be less than eight.
In any event, at some point, (1) the single Product Owner can no longer grasp an overview of the entire product, (2) the Product Owner can’t balance an external and internal focus, and (3) the Product Backlog is so large that it becomes difficult for one person to work with.
When the group hits that tipping point, it may be time to change from the smaller LeSS framework to LeSS Huge. On the other hand, we suggest first trying to get better, smaller, and simpler, before getting huger.
Common Across the Frameworks
The LeSS and LeSS Huge frameworks share common elements:
one Product Owner and one Product Backlog
one common Sprint across all teams
one shippable product increment
The following two sections of this chapter explain the frameworks; the smaller LeSS framework is next, and LeSS Huge starts further on..