- One-Team Scrum
- LeSS
- LeSS Framework
- LeSS Huge Framework
- Onwards
This chapter is from the book
This chapter is from the book
This chapter is from the book
LeSS Framework
• LeSS Framework Summary •
)
The smaller LeSS framework is for one (and only one) Product Owner who owns the product, and who manages one Product Backlog worked on by teams in one common Sprint, optimizing for the whole product. The LeSS framework elements are about the same as one-team Scrum:
Roles—One Product Owner, two to eight Teams, a Scrum Master for one to three Teams. Crucially, these Teams are feature teams—true cross-functional and cross-component full-stack teams that work together in a shared code environment, each doing everything to create done items.
Artifacts—One potentially shippable product increment, one Product Backlog, and a separate Sprint Backlog for each Team.
Events—One common Sprint for the whole product; it includes all teams and ends in one potentially shippable product increment. Details are explained in the upcoming stories, and in separate chapters.
Rules & Guides—Rules for a barely sufficient scaling framework for empirical process control and whole-product focus. Guides may help.
• LeSS Stories •
Learning LeSS—One way to learn is by reading in-depth exposition, and readers preferring that can comfortably skip ahead to the introduction to LeSS Huge (p. 33), and then on to following chapters. Others who like stories, keep on reading.
Simple stories—These stories don’t explore the complexities of large-scale development—from politics to prioritization—that we experience when consulting. Later chapters unpack those boxes. Here are intentionally plain and simple stories just to introduce the basics of a LeSS Sprint. If you want thrilling dialog and drama, read a Lean book.
Rules & guides—In the stories you will notice that the margins refer to related LeSS rules and guides, to clarify and make connections.
Two perspectives—Following are two related stories focusing separately on two key perspectives, to introduce some flows more simply:
The flow of teams through a LeSS Sprint.
The flow of customer-centric items (features).
• LeSS Story: Flow of Teams •
This story focuses on the flow of teams through a Sprint, rather than the flow of items. In reality the majority of time in the Sprint is working on development tasks, not meetings. However, this story emphasizes meetings and interactions, as the goal is an understanding of how multiple teams work together during LeSS events, and how they coordinate day by day.
Mark walks into the room where his team (Trade) works and sees Mira1, who says, “Good morning! Just a reminder, we’re the team representatives for this Sprint, and Sprint Planning One starts in 10 minutes.” “Right,” says Mark, “Meet you in the big room.”
Sprint Planning One
It’s time for a common Sprint Planning One. Around the big room are 10 team representatives from the five teams in this product group. They all work on their flagship product for trading bonds and derivatives. Sam, the Scrum Master of teams Trade and Margin, is also there. He’s planning to observe and coach as needed.
Many Sprints earlier, everyone from all the teams attended Sprint Planning One. That was more useful when the group was not very good at getting items clear and ready, nor at creating broad knowledge across the teams. Back then, Sprint Planning One was used to answer a lot of major questions that everyone needed to hear. But lately that’s been much improved, and so now the group is experimenting with using rotating representatives, in what has become a simple and quick meeting with only a few minor questions that tend to pop up. If the new approach doesn’t work well, it will probably be raised in an Overall Retrospective, and another experiment for Sprint Planning will be created.
Paolo walks in and says “Hi!” He’s the Product Owner and also the lead product manager.1 Paolo lays out 22 cards on a table and says, “Here’s the big themes: German market, order management, and some regulatory reports. I’ve laid them out in my priority order. I think everyone here understands why these are the priorities, since we’ve been discussing this a lot in Product Backlog refinement. But please ask again, if it’s not clear.”
)
Mira and Mark walk over to the table (along with the other representatives) and pick two cards for items related to German-market bonds. Over the last two Sprints their team clarified these items in detail, in single-team Product Backlog refinement (PBR) workshops.
And they pick two more items related to order management that both Team Trade and Team Margin understand quite well. Both teams worked together in multi-team PBR workshops on these items. Why? The teams wanted to decide as late as possible the choice of team-to-item, during some future Sprint Planning. This increases the group’s agility—easily responding to change—and their broader whole-product knowledge fosters self-organized coordination.
A minute later, Mary from Team Margin, on scanning another team’s cards, asks their representatives, “Do you mind if we do that report? We did something very similar last Sprint and I bet we can get it done quickly. Could you swap for this German-market item?” They agree.
)
After a few minutes, the teams finish choosing and swapping based on their interests, strengths, and desire to group related items for focus.
Sam (the Scrum Master) says, “I notice that Team Margin has the top four priority items. Could that become a problem?” A quick discussion ensues in which the group realizes there’s a chance that one of the highest-priority items for the product could get dropped if things don’t go smoothly for Team Margin. They decide to distribute a few of the highest-priority items across more teams (constrained by which teams know which items), making it more likely that top items will get done.
The representatives have chosen a total of 18 cards, leaving four lowest priority items on the table. Paolo looks over the unchosen item cards, picks up two of them, and says, “These two are pretty important to me this Sprint. Maybe I should have given them a higher priority to begin with, but I didn’t, and now I’d like to change my mind. Let’s find a way to swap them with some items you’ve already chosen. And of course, if a team gets lucky and finishes early, please pick up the unchosen items.”
After that’s resolved, Paolo says, “Okay, let’s spend some time wrapping up lingering questions. As you know, I’ve been focusing more on figuring out prioritization, and most of you know these item details a lot better than me, but let’s see what we can do together to clear up minor stuff.”
In parallel, Mira, Mark, and the others think hard about final minor points to clear up for their items, and write some questions on flip-chart papers on the walls around the room. Paolo roams around to different areas, discussing. Everyone mingles and contributes. After about 30 minutes, all the minor questions that could be answered have been.
The group forms a standing circle to wrap up. No one raises any coordination topics, so eventually Sam says, “I notice that Teams Trade and Margin and NotDerivative have picked up strongly related order-management items.” Mira says, “Hey, let’s get Trade, Margin, and NotDerivative together for a multi-team Sprint Planning Two. We’ve got opportunities to work together.” That’s agreed. The meeting ends.
Team and Multi-Team Sprint Planning Two
After a break, two of the five teams hold their own single-team Sprint Planning Two meetings to create their own Sprint Backlogs, designing and planning their work for the Sprint.
In contrast, Teams Trade, Margin, and NotDerivative hold a multi-team Sprint Planning Two together in a big room, since they are implementing strongly related items—which were also previously clarified together in multi-team PBR—and they foresee value in working closely.
They talk together in a 10-minute session to set the stage, identifying shared work (common tasks) and design issues. Then they start the clock for a timeboxed 30-minute design session, agreeing to visualize: more sketching on the whiteboard, less talking without drawing. During this time, more shared work is also discovered and written on the board.
Ding! After 30 minutes lots of unexplored details remain, but the teams move on anyway. Each team heads to a different corner of the big room where each starts its own focused Sprint Planning Two, talking more about detailed design issues and creating their own Sprint Backlog with cards. Further coordination is handled by an advanced variation of the just talk technique in LeSS: just scream.
During the talking, the teams realize the need for an in-depth multi-team Design Workshop. They agree to hold one later that day.
Multi-Team Design Workshop
After Sprint Planning and another break, Mira and Mark from Team Trade, and a few people from Team Margin and Team NotDerivative hold a timeboxed one-hour multi-team Design Workshop for a deeper dive into a common and consistent design for their work. Around a large whiteboard they sketch and talk together towards some clarity and agreement on a design approach and common technical tasks. Fortunately, the conclusions don’t seriously impact their existing Sprint plans, but they feel uncomfortable with their process, recognizing they could have predicted the need to resolve these big design questions earlier.
Development Activities Supporting Coordination and Continuous Delivery
After Sprint Planning, the teams dive into developing items, with an emphasis on communicating in code. All the teams are integrating continuously. The continuous integration of all code across all teams creates the opportunity to cooperate by checking who else made changes in the component being worked on. That’s useful, because the group uses integration as a way to inform and support their coordination.
For example, early during the second day of the Sprint, Mark, a developer on Team Trade, pulls the latest version locally and quickly checks the latest changes related to the component they are working on now. He discovers changes related to code added by Maximilian from Team Margin. He knows that team is working on a strongly related item, so he is not especially surprised. Since the code has communicated that now there’s a need to coordinate and who he needs to talk with, he immediately visits Team Margin down the hall. They just talk about how to work together to benefit from one another’s work.
For the item that Team Trade is developing, and in fact for every item in every team, they have written the automated acceptance tests before starting to develop the solution code. Thus, in addition to integrating the code continuously, they’re also integrating the automated tests. These acceptance tests are run frequently by team members, and so when any of them fails, the teams are immediately signaled to coordinate. The code is telling them, “Hey! There’s a problem! You need to talk and work it out.”
Naturally, another major benefit of the group’s practice of integrating continuously, automated testing, and stopping-and-fixing whenever the build breaks, is that their product is more or less continuously ready to deliver into production. There’s no separate integration team or testing team that would add delay, handoff, and complexity.
Overall Retrospective
On the second day of the Sprint, Sam and the other Scrum Masters, the Product Owner Paolo, a site manager, and a representative from most of the teams, all get together for a maximum 90-minutes Overall Retrospective related to the last Sprint.
Why didn’t they hold this Overall Retrospective before this new Sprint started? They could have, but they normally end a Sprint on a Friday and start a new one on Monday (in contrast to Sam’s suggestion that they try a Wednesday–Thursday boundary). And on the last Friday, they held both the Sprint Review and the team-level Retrospectives. After that they didn’t have the energy to hold an engaged Overall Retrospective at the end of the day. So they’ve opted for an early next Sprint. Sam privately thinks this delay is not a great idea—he’d rather they started Sprint Planning a little later after this meeting—but he wants the group to discover that for themselves.
They focus on a system-wide issue and improvement: how to coordinate, share information, and solve problems across the entire group during the Sprint? Previously they have tried Scrum-of-Scrum meetings and didn’t find them very effective. Sam explains the technique of Open Space, and they agree to try it this Sprint.
Activities for Coordination
The fourth day demonstrates a variety of coordination ideas in LeSS:
In LeSS, each Team holds a Daily Scrum as usual. To support coordination between Teams Trade and Margin, Mira goes as a scout to observe Team Margin’s Daily Scrum and then returns and updates her team on what she learned. And someone from Team Margin does the opposite.
As agreed in the Overall Retrospective, the group holds a 45-minute Open Space meeting for coordination and learning, preceded by drinks and snacks. Sam acts as facilitator to teach the group how to hold an Open Space meeting. Everyone is welcome, but most teams decide to send only a few representatives. Mira and Mark from Team Trade join in. The group plans to try an Open Space once a week.
The Test community, with volunteers from most teams, gets together for a half-hour to hear Mary’s proposal to try a new automated acceptance-testing tool. They enthusiastically agree, and Mary volunteers her Team Margin to do the actual experimental work next Sprint, since they are really interested in learning this.
Mira is a member of the Design/Architecture community. There’s no design workshop needed this Sprint related to overall architecture, but she wants to hold a half-day spike in the next Sprint for a new technology. She posts her idea on the community collaboration tool, and suggests the community do the spike together with mob programming to increase their shared learning.
The build system seems to have a weird bug. Time to stop and fix! This Sprint, Team Trade is responsible for it, and it’s one of Mark’s secondary specialties, so he volunteers to fix it and asks another team member to pair up with him to help his colleague learn more about it.
Later, Mira and a few other team members visit the customer support and training group, who work closely with hands-on users. Her team has finished their first item and they want to get early feedback from people closer to customers. One of the trainers is free and he plays with the new feature. Team Trade leaves with a few ideas to make it better.
Later in the day Mark and the rest of Team Trade are doing tasks for their second item. Mark has just completed a 10-minute TDD cycle and has clean stable code after a micro-change. Once again—about every 10 minutes—he pushes the tiny change to the central shared repository (to “head of trunk”), to integrate continuously with his team and all others. He glances over to their big visible red-green screen on the wall and sees that the build system is passing all the tests for the entire group.
Overall Product Backlog Refinement
On the fifth day, Mark and Mira join an overall PBR workshop, with representatives from each team, and Paolo, the Product Owner. Paolo starts by sharing his current thinking on product direction and where to go next in the short term and, most importantly, why. To help them understand his reasoning, he reviews his prioritization model with the group, that factors in profit impact, customer impact, business risk, technical risk, cost of delay, and more.
Paolo asks for feedback and ideas from the group for upcoming direction, and the group discusses what items to refine next. Although he knows that he’ll make the final priority calls, Paolo works hard to engage the teams in understanding his thinking, and also to learn from their thinking. He wants the teams to also be involved in owning the product.
The group then splits a few big new items, doing lightweight clarification (more will follow later), and planning poker estimation as a way to learn more about the items—rather than to create estimates.
The representatives from three teams (including Trade and Margin) decide to later do multi-team PBR together for some items to increase their shared understanding and because they are strongly related. And representatives from two other teams choose items to focus on separately in team PBR sessions.
Multi-Team PBR and Team PBR
On the sixth day, everyone in three of the teams gets together for a multi-team PBR workshop in the big room.
Although their main business is creating and selling their trading solution, the company has a small group of bond traders that use it, with relatively small positions that keep them engaged but without high risk. This way the company has better insight into market trends as well as some expert users that can easily talk with the development teams.
Tanya and Ted are the traders who told Paolo about a trend that led to the items being refined in the multi-team PBR session. So they both join, as experts to help the teams learn and clarify the new items.
The other two teams, in discussion with some other traders, hold separate PBR workshops to complete clarification of some items already under refinement and to start on some new ones. Also, one of the company’s three lawyers specializing in financial regulations and compliance joins one of these teams to help them in clarification.
As a last step in the PBR meetings, people take photos of everything on the walls and whiteboards. They add those to the wiki pages that are used to record everything for each item. Plus they update and clean up the text and tables in the wiki pages that were quickly added during discussions.
A Chat About Team-Level Backlogs and Product Owners
After the multi-team PBR workshop, Mike (who just joined the company) sees Sam by the coffee machine and walks over to talk. Mike says, “Hey Sam. I’m interested in your opinion on something. In the refinement workshop we just finished, of course I noticed that we were working directly with some of the traders to clarify together. But isn’t that inefficient? In my last company, every team had its own Product Owner who did the story writing, wireframes, and specifications, and then gave them to us to implement. Then we could just focus on the programming. And each team had its own Product Backlog that the team’s Product Owner prioritized. But I don’t see that here. Why is it different?”
Sam says, “Interesting questions. Do you mind if I ask you a few questions to explore this?”
“Sure, go ahead.”
“Let’s first consider one Product Backlog versus many team-level backlogs. Suppose each team had its own backlog. How easy and effective is it for one truly overall Product Owner to have an overview? And how much knowledge will a team have of the requirements and designs of items in a different team’s backlog?”
Mike replies, “I can answer that pretty clearly from my last company. Not much.”
Sam continues. “Now suppose there are eight teams and eight team backlogs. What if, from the higher company or product perspective, for some reason, the items in two of the eight team backlogs are actually by far the most important or highest priority. Maybe there’s some change in the market so that this situation comes up. So some questions for you: Can the six teams working in the lower-priority backlogs easily shift to start working on the high-priority items in the other two backlogs? And is it likely that the group will even see this problem, given that they are locked in to each team having their own backlog and local priorities?”
Mike answers, “Our teams at my old place only worked on their own team item backlog. They couldn’t shift to others. But why would they want to? Isn’t that inefficient?”
Sam responds, “Well, from a company perspective, the teams are only working ‘efficiently’ on low-priority stuff because of their narrow knowledge created by each focusing in a different team backlog and because the overall priority and overview isn’t visible. Let me ask you some questions: Does that seem inflexible or flexible—agile? And does that optimize people working on the highest-impact stuff from the company perspective?”
Mike pauses, “Oh! I think I get it. It’s actually not being agile, even though our group said they were doing agile. We weren’t responsive to the highest-value changes overall. And my old team Product Owner said she was prioritizing for highest value in our team backlog. But now I see that my team was just busy efficiently working on what could be low-value stuff when you look at it from a higher level.”
Sam says, “Exactly. So that’s one of several reasons why we have one Product Backlog here, and no team backlogs, even though there are many teams. In short, it supports whole-product focus, system optimization, and agility. And of course it’s simpler, and it’s easy to see what’s going across the group.”
“Also,” Mike comments, “I noticed it was much harder in my prior company for all the teams to really work together at the same time, since we were working on very different goals in asynchronous Sprints. Here it feels like all the teams have more of a common focus and direction in one Sprint together.”
“Exactly!” Sam replies, then continues.
“Here’s another question: If there’s only one Product Backlog and one real Product Owner who prioritizes it, but each team still had its own so-called Product Owner who per definition is not prioritizing a team backlog—since there isn’t one—then what do they do all day long? “
Mike replies, “Well, in my last company it was the job of the team-level Product Owner to talk to the users and write the stories for the team, so they could focus on efficiently programming while the team Product Owner worked on gathering and writing requirements.”
Sam asks, “Mike, before you learned about Scrum terms such as ‘Product Owner’, what would you have called middlemen in between the developers and real customers—the ones collecting requirements and then giving them to developers?”
“I joined my last company before we adopted Scrum there.” Mike answers, “And back in the day, there was a group of business analysts who did that. After we adopted Scrum, we were asked to call them the Product Owners.”
“Today in your PBR workshop,” Sam asks, “Did you talk with the traders who were there?”
“Let me think back.” Mike replies, “Yeah, I was talking with Tanya about her idea to analyze trading Russian corporate bonds. It seemed a little confusing so I asked her, why? She explained it was because of concerns around money laundering in offshore accounts. Now, she didn’t know that we’ve been recently working on some other features that integrate with new EU and USA regulatory databases to assess this. So I proposed to her a different approach, which I think—and she agrees—will better solve the problem.
“Now that I think about it,” he reflects, “that probably wouldn’t have happened in my last company, since we rarely talked directly with users.”
More Development
Minute by minute and day by day the teams develop code, integrating continuously combined with full test automation. They stop and fix when the build breaks, working towards their perfection goal of having a done shippable product they can continuously deliver to customers. Therefore, when the Sprint is nearly over and the teams are preparing to join the Sprint Review, there’s no late mad rush of effort to integrate and test a big batch of code—it’s been integrated and tested all along.
Sprint Review
Finally it’s the last day and time for an all-together Sprint Review. Who’s there? Paolo (the Product Owner, lead product manager), all the internal bond traders, a few trainers and customer service representatives, a few people from Sales, and four users from external clients who pay lower annual rates in exchange for participating regularly in these reviews. Also, there’s all the team members.
)
Because there are many items to explore, the group starts with a one-hour bazaar—something like a science fair—with many devices set up in the room, each available for exploring different sets of items. Some team members stay at fixed areas to collect feedback while everyone else uses and discusses the new features.
)
After an hour, the group comes together to discuss the questions and feedback, in a session led by Paolo. After that, they discuss future direction. Paolo shares what’s going on in the market and with competitors, and his thoughts on where to go next, and asks for advice.
Team Retrospectives
After a break, Team Trade (and all other teams) hold separate team-level Sprint Retrospectives. They decide that holding a multi-team Design Workshop with Team Margin after Sprint Planning (rather than earlier) was far from ideal in this case, because major issues were left unexplored until the last minute—issues which could have seriously blocked or complicated development. So for the next Sprint they decide that during their PBR sessions they will strive to identify items that have major design issues worth discussing with other teams. And if so, hold a multi-team Design Workshop as soon as possible.
The End
Sprint done! Sam invites Team Trade to join Mira and him at the Belgian-beer pub down the street—Mira’s favorite—to celebrate her birthday.
Summary
Some key points from the story:
it emphasized flow of people and teams through a Sprint in LeSS
it connected story elements to specific LeSS guides and rules
for a reader who knows Scrum, the events should be familiar
the story shows whole-product focus, even with many teams
the activities emphasized team-based learning and coordination
develop items by integrating continuously so that communicating in code supports decentralized coordination and just talking, in addition to continuous delivery
teams clarify directly with users and customers, to reduce handoff and increase understanding, empathy, and ownership
• LeSS Story: Flow of Items •
This story focuses more on the flow of items (features) through part of a Sprint, primarily during refinement and development.
Portia wraps up her meeting with the government regulator and heads to the airport, and home. She’s another product manager; she helps Paolo, and specializes in regulatory and audit trends.1
Later, Portia meets with Paolo. Writing on cards, she summarizes the new rules that are going to impact their product, and what clients she thinks are going to want certain features first. Paolo points to the five cards and asks, “So this covers all the work, as far as you know?” Portia smiles and says, “This is regulatory. It’s never finished or clear.”
)
Paolo asks, “Can you put these in the Product Backlog for me, unordered at the bottom for now?”
“Sure.”
A week later Paolo tells Portia, “Soon, I want to start delivering some parts of the big regulatory requirement for bond derivatives. In the next Sprint’s Product Backlog refinement workshops, I’m going to ask for some teams to focus on that. You know the most about it, so please be at the overall PBR and at whatever team refinement workshops where they want you. Also, can you set up a wiki page with links to the new regulatory docs, to share with the teams?”
“Already done,” answers Portia.
Overall PBR
Paolo kicks off a quick overall PBR workshop, “We’ve got lots of work around new regulations. Soon we need to deliver related items because of a legal deadline end of fiscal year. We’ll know better after some splitting and estimation, but I wouldn’t be surprised if it ultimately involves three or more of the teams for implementation, and lots of time.”
The group splits the new giant item into only a few large parts, to learn major elements. More splitting will happen later in a single-team or multi-team PBR session. Portia heads to the whiteboard; on the left side she writes “regulations for bond derivatives.” Then in conversation with the group, they sketch a tree diagram with four arms representing a splitting into four major sub-items. But they don’t go any deeper—they’re avoiding over-analysis.
Next, the group creates four cards for the new items, and everyone together estimates them with planning poker and relative-size points, baselining the points against existing well-known items in the Product Backlog. Their main goal is not to create estimates but to surface questions and drive more discussion, which they do with Portia.
Next, Paolo asks, “So Portia, of these four big ones, which one first?”
She points to the second card. “Over-the-counter exotic bond derivatives.”
Paolo says, “We need to start delivering some of that as soon as possible. It’s moving way up the Product Backlog. So I’d like one team to take a bite into this, next Sprint. Who’s interested?”
Team Trade volunteers.
Finally, team members from three other teams decide to hold a multi-team PBR workshop for related items.
Team PBR: Biting In
The next day Team Trade holds a team PBR workshop with Portia. They have only one of the four giant items to focus on: New regulations for over-the-counter (OTC) exotic bond derivatives. Sam (their Scrum Master) is also there. Portia says, “This is a gigantic complex item, in an area that frankly nobody is really clear about. It’s going to take us a long time to split this up, really understand it, and specify it well.”
Sam asks, “Do we really need to understand all of it? And will all that analysis teach us more, or could it actually delay our learning?”
He reviews with them the idea of Take a Bite: to just split off one tiny fragment, really understand that, and implement it quickly. Sam concludes, “You know, diagrams don’t crash and documents don’t run.”
With Portia, the team splits off one tiny bite of a thin customer-centric end-to-end item.
From now on they will focus on that tiny bite, clarifying and implementing it. Only after implementation and feedback will they return much later to more splitting and refinement. Using specification by example Portia and Team Trade spend the rest of the day chewing on their bite.
Multi-Team PBR: Rotation Refinement
One outcome of overall PBR was the decision to take a bite with Team Trade. Another was the decision for three teams to hold a multi-team PBR workshop for related items, to increase learning and the agility of multiple teams knowing and thinking about the same items.
In addition to everyone from the three teams, the internal traders Tanya, Ted, and Travis join to help the teams start clarifying about a dozen new items.
To start, they form three temporary mixed groups with people from each team. The mixed groups start clarifying different items in separate areas in the room, each with a whiteboard, big wall space, laptop, and projector. Tanya is with one group, Ted another, and Travis, the third.
Then they do rotation refinement: After 30 minutes, a timer goes ding! One group walks over to the other’s area, and vice versa, but Tanya, Ted, and Travis don’t move. The timer is restarted, the traders explain the current results to the incoming groups, and they continue clarifying.
)
Figure 2.1 multi-team PBR
Throughout the day, as different items become relatively clear—or are left with hanging questions that will have to be explored later—new items are introduced at a work area. Some of the bigger items are split into two or three new smaller ones.
A few times during the day, the groups stop their clarification and do some estimation, mostly to learn and to prompt conversation. They’re using relative (story) points; to remain synchronized against a common baseline, they calibrate against some already completed and well-known items in the Product Backlog.
Updating the Product Backlog and Product Owner
The day after the PBR workshops, Portia and a few team members
update the Product Backlog with the new split items derived from the original ones, and delete the originals
add links to the new wiki pages of item details, created in the PBR workshops
record new estimates, and items ready for implementation
Later, Portia and those team members meet with Paolo to review the Product Backlog changes and to answer his questions.
The End
Some key points from the story:
Take a Bite on a giant item to learn from delivery of something small and to avoid premature and excessive analysis.
Do multi-team PBR for items, for shared knowledge across teams, which increases organizational agility, broadens whole-product knowledge, and fosters self-organized coordination.
Strive for whole-product focus, even with many teams.
Next—The next section shifts to the LeSS Huge framework, used for large groups of many teams.