Product owner, product backlog, and sprint planning

On the left side of the LeSS product development process in Figure 5-1 is the product owner and product backlog. The product owner selects features from the backlog and engages in a two-stage sprint-planning process:

• Sprint Planning 1: The first stage of sprint planning centers on determining which items in the product backlog to work on and setting a goal for the sprint.
• Sprint Planning 2: The second stage of sprint planning involves determining how to get the work done — how to complete the selected items from the product backlog.

In other words, Sprint Planning 1 is about what to do, and Sprint Planning 2 is about how to do it.

Sprint backlog

One of the objectives of sprint planning is to develop a sprint backlog for the various Scrum teams. In Figure 5-1, the sprint backlog is depicted as the Jumbotron that all the team members are looking at. Each team draws items from its backlog and then works to complete those items in time allotted for the sprint.

Scrum teams

Over the course of a sprint, Scrum teams pull one or more items from the product backlog and work on completing them over the sprint. To complete their tasks, Scrum teams must collaborate with:

• Customers and end users to refine the definition of the product backlog item
• The product owner to prioritize product backlog items
• Other teams to coordinate and integrate their work to produce one whole product increment

Note in Figure 5-1 that the teams are divided into three lanes with a product owner who spans all three lanes. The product owner is about as close to top-level management as you will get in LeSS, and it’s really not management at all. The product owner simply organizes the work to help the teams complete their sprints.

Scrum Masters

You may notice in Figure 5-1 that the three teams have only two Scrum Masters (designated by “SM” in the figure). One Scrum Master works with the two teams in the bottom two lanes. The other has her own team in the top lane. This shows that unlike team Scrum, LeSS permits different teams to share Scrum Masters.

Coordination

The double-headed arrows that cross the lanes dividing the teams represent the coordination required among teams to develop a single, unified potentially shippable product increment that’s ready for shipment.

Daily Scrum

The dialogue bubbles in the graphic represent Daily Scrums. Every day, each team meets (without managers or a Scrum Master) to answer the following three questions:

• What did WE do yesterday?
• What will WE work on today?
• What is in OUR way?

Teams may meet together during Daily Scrums to spend some time coordinating their work.

Product backlog refinement

Teams are required to spend some time during their sprint (less than ten percent) to refine the product backlog for future sprints. Refinement (depicted by magnifying glasses in the graphic) may include one or more of the following:

• Splitting big items
• Adding detail about an item
• Estimating the time required to develop an item

Note that the teams in the top two lanes share a backlog refinement meeting. While in the bottom lane the team has its own meeting. (See Chapter 6 for details.)

Sprint review, retrospective, and overall retrospective

At the end of the sprint, various groups meet to discuss the outcome of the sprint and ways to improve the product and process:

• Sprint review: The teams, product owner, end users, customers, and other stakeholders meet to discuss what the team built along with changes and new ideas to decide the direction of the product. This is where each team demonstrates its work. You can see the little signpost on top of that meeting. That represents the feedback that the team gets so team members can inspect and adapt their product.
• Retrospective: Team members meet to share information and insight and discuss ways they can improve their work going forward.
• Overall retrospective: All teams meet with the Scrum Masters and product owners to discuss much broader process improvements, overall organization, and systemic problems within the organization.

See the later section, “Learning from achievements and mistakes: Continuous improvement” for details on how to conduct these three meetings.

Potentially shippable product increment

Every sprint ends with a potentially shippable product increment. Prior to that, during the sprint, the teams must collaborate to integrate their work and produce a whole product. The overall goal of developing a potentially shippable product increment is intended to:

• Keep the focus on the whole product
• Increase transparency and eliminate the possibility that any portion of the work remains undone
• Reduce work in progress
• Maintain short feedback cycles for continuous improvement

At the end of the sprint, you have a potentially shippable product increment, but that doesn’t mean everyone stops working. As soon as the final review process is over a new sprint begins.

Large-Scale Scrum is Scrum

LeSS creators stress that Large-Scale Scrum is no different from Scrum. Unlike SAFe (see Chapter 4), which adds processes and roles, Scrum simply provides principles, rules, and guides for the application of Scrum in a multi-team context. LeSS doesn’t change the way Scrum teams function; it only provides guidance to facilitate how those teams scale or descale (see “More with LeSS”) to larger enterprise-level products.

Transparency

The dictionary definition of “transparent” is “easy to perceive or detect.” Transparency is a core concept in all agile frameworks, because it’s what drives continuous improvement through discovery and adaptation. Product owners, Scrum Masters, team members, and other participants are expected to be open and honest with one another. In addition, the sprint model creates short feedback loops that dramatically increase visibility into problems in the product, process, team, and organization overall.

More with LeSS

The More with LeSS principle stresses simplicity over complex organizational solutions, such as increased layers of management and complicated structures and processes. The idea is that complicated solutions cause more problems than they solve. In this respect, LeSS is a descaling framework to remove large organization complexity. With LeSS, the emphasis is on developing greater insight into problems at the product development level and addressing them at that same level with simpler solutions.

Whole product focus

LeSS encourages cross-functional teams by focusing their efforts collectively on developing a whole product instead of having individual teams focus solely on whatever part of the product they’re working on. Teams are advised to function according to the following guidelines:

• Your team’s part has no value until it’s integrated into the whole product.
• Your team isn’t done until its part is integrated into the whole product.
• Given the choice to optimize the team or the whole product, optimize the whole product.

Customers buy a product, not parts of it.

Customer centric

When multiple teams are involved in product development, each team tends to become so involved in developing its part that it forgets how the customer will use the product. LeSS encourages a closer connection between teams and customers by recommending that organizations do the following:

• Form feature teams instead of component teams to maintain a focus on end-user needs. (See the later section “Feature teams” for more about the difference between feature teams and component teams.)
• On very large products, group teams into customer requirement areas instead of architectural subsystems.
• Have the product owner connect teams directly with customers instead of serving as an intermediary.
• Have teams get most of the clarifications about the product directly from customers, which frees up more time for the product owner to focus on the big picture.
• Share the product backlog among all teams working on the product and continuously reprioritize the backlog to optimize the system for customer delivery.

Continuous improvement toward perfection

Continuous improvement toward perfection is one of the pillars of Lean thinking, the other being respect for people. The purpose of this principle is to encourage organizations to embrace change and for everyone in the organization to challenge everything and continue to develop his knowledge and skills. Improvement stops only when the product, the process for creating it, and the organization and the people who develop it have achieved perfection — which essentially means never.

Lean thinking

Lean thinking is a business methodology in which an organization’s management is committed to continuously investing in its people and giving each employee the opportunity to identify problems in his own way of working, solve those problems, and make improvements. As you can see, the two principles of Lean thinking and continuous improvement toward perfection are closely aligned.

Systems thinking

Systems thinking is a management discipline that sharpens awareness of whole dynamic systems and how the components of those systems interrelate. Certain tools such as flow charts and simulation models are often used, but the scope of systems thinking often encompasses processes, limits, delays, behavioral patterns, and anything else that may affect the productivity of the system overall. With LeSS, systems thinking has two primary purposes:

• To ensure long-lasting systemic improvement in an organization through experimentation and empirical analysis instead of standard best practices and quick-fix solutions that commonly suffer from lack of insight or are based on false assumptions.
• To extend value beyond the product development teams and out to the entire organization to look at ways that the organization can be improved overall to deliver greater value to the customer.

Empirical process control

Empirical process control is an approach to product and systems development that relies less on up-front planning and more on experimentation, transparency, inspection, and adaptation. In short, teams are encouraged to innovate and experiment in order to continuously improve the product and the systems for building it.

Think of it this way: Every so often I’ll get a contract to work in a different part of the city. I live in an area where it’s extremely important to plan out your commute to work. If you come up with a bad plan, you could get stuck for hours in traffic. So I use an empirical approach to determine the best process for my commute to work. One day I try the bus, another day I try the train. I may try driving or riding my bicycle to the train station and then taking the train. Each time I try something new I record how long it takes for me to get to work. After a while I figure out the quickest commute.

That’s how LeSS improves your enterprise agile approach. It encourages you to inspect and adapt how you deliver your product and find the way that works best. In many ways it takes the empirical approach of Scrum and applies it to the whole enterprise agile process.

Queueing theory

Queuing theory is a mathematical study of wait lines used to predict and reduce wait times. It’s used in all agile frameworks to reduce wait times inherent in the traditional linear product development processes. In LeSS, many teams working in parallel and together, develop different parts of a product and then integrate the parts near the end of a sprint to create a potentially shippable product increment. See Chapter 4 for more about queueing theory and Chapter 8 for more about managing queues.

Scrum teams

A Scrum team is a self-managed, cross-functional group of three to nine people who do it all, from writing code to producing documentation, to creating a part of a product and integrating it into a functioning increment of the product. In LeSS, numerous teams work in parallel and together on a single product with the common goal of delivering a shippable product at the end of a given sprint. Each team has the following characteristics:

• Each team member is dedicated to only one team; a person can’t be pulled off a team to work on another team.
• Teams are cross-functional, meaning each team contains all the skills needed to produce a shippable product.
• Members of each team work together in the same space to promote communication, cooperation, trust, and shared learning.
• Each team remains together for as long as possible to improve the ability of team members to work as a unit.

Feature teams

Feature teams are cross-functional, cross-component, stable, and long-lived. They take customer-centric features from the product backlog and complete them to deliver a potentially shippable product increment.

The “feature” in “feature team” highlights the difference between feature teams and component teams:

• Feature teams: A feature team has all the knowledge and skills required to build a feature, such as a feature in an accounting program for producing an accounts payable report (to show which customers owe money and how much).

  Think of a feature team as a small, flat organization within the larger enterprise. Everyone on the team works together to deliver the product. Everyone in the rowboat rows, just as they do on any agile team.

• Component teams: Component teams handle various aspects of a feature. For example, to produce an accounts payable report, you may have a component team that works on the database, another that works on the user interface, and a third that focuses on presenting the data in a report. In this example, three component teams would be involved in delivering the feature, and they would need to work closely to coordinate their work.

The component team model results in a lot of dependencies, as shown in Figure 5-2 by the arrows from the items in the product backlog (in the column on the left). Because each work item requires two or more teams to complete it, one team may need to wait on another team to complete its work before it can move forward on that item. It also requires a great deal of cross-team coordination and communication, as shown by the double-headed arrows connecting the teams. No single team has the knowledge and skill set to complete a work item on its own.

In contrast, each feature team can choose one item from the product backlog and complete it without the help of another team. As you can see in the figure, none of the teams is connected to another. They all have the knowledge and skills required to work on each component of the product, so Team Wei can complete Item 1 by working on any and all Components A, B, or C, without depending on any other team to complete its work.

Scrum Master

The Scrum Master has a deep Scrum understanding to guide and coach the organization on Scrum principles and practices, so they have a better understanding of how to deliver value to customers. Each Scrum Master has four focus areas:

• Team
• Product owner
• Organization
• Development practices

Don’t think of the Scrum Master as team leader. The Scrum Master serves more of a role as advisor to bring everybody up to speed on Scrum, to educate and coach teams in self-management and shared responsibility, and to prepare product owners for their role and facilitate their interaction with their teams.

Communities of practice

Communities of practice (CoPs) are groups of people that gather informally around a certain functional area of expertise, such as software development, analysis, or testing, to share their knowledge and expertise and discuss their challenges. Essentially, they gather to talk shop. CoPs cross team boundaries, which can improve communication and cooperation across teams. For example, Scrum Masters may decide to meet as a group to share what they know about Scrum and exchange ideas of how they can help the teams, product owners, and organization overall.

Although organizations don’t form these groups, you can encourage their formation by providing time and space for the CoPs to meet, information technology infrastructure, learning materials and other resources, and perhaps even snacks and beverages.

Organizational structure

The LeSS organizational structure is flat, as shown in Figure 5-3. The head of a product group is a product manager who works to support the product owner and teams in their efforts to produce a quality product and the perfect system for developing it. The head of a product group may help the team remove obstacles or improve its knowledge and skills.

Note that the organizational chart includes an Undone Department. Ideally, the nature of cross-functional teams makes this department unnecessary, but sometimes a team lacks the knowledge and expertise, such as testing, quality assurance, or business analysis, to complete a shippable product. When that happens, the undone department must complete the work.

For more about the various roles in the LeSS framework, see the later section “Getting to Know the Key Players.”

Continuous integration

Continuous integration is an approach to software development that involves making small changes that are integrated daily and tested frequently. Typically, each team member integrates his work at least once a day, which can result in several integrations over the course of a day. The emphasis is on developing a product in small batches and short cycles, which increases visibility into the process, thus increasing the quality of the system.

Continuous delivery

Continuous delivery involves keeping the product in a potentially shippable state at all times. The purpose of continuous delivery is to reduce the time, cost, and risk of delivering changes by allowing for more frequent updates to products in production. See Chapter 1 for details.

Acceptance testing

Acceptance testing checks a product to ensure that it meets the sprint goal and that the product is indeed potentially shippable. Acceptance testing includes a user-acceptance test and may also include functional or system testing.

Architecture and design

Architecture and design in LeSS involves less planning and more observation to see where the customer is going and then designing and building products accordingly. It’s an approach to design that relies more on pull than push. (See Chapter 3 for more on “pulling” work.)

Clean code

Clean code is a term used in programming to describe a minimalist approach to programming. The goal is to use the least amount of code required for a feature or function, and that code should be easier for other programmers to read and extend. Writing clean code is especially important in LeSS, where you have so many teams of developers collaborating on a single product.

Unit testing

Unit testing involves running small, fast software programs to verify the functionality of a piece of code. Don’t confuse a unit test with a bug test. A unit test determines whether a piece of code behaves as suspected in a variety of test cases. Unit testing is key in LeSS, which encourages frequent testing and adaptation.

Test-driven development

Test-driven development (TDD), as explained in Chapter 2, is a software development process that involves the repetition of a short development cycle. The developer writes a test case, designed to fail, that defines a desired function or improvement and then writes the least amount of code necessary for the program to pass the test and then refactors the code to acceptable standards. The main purpose of TDD is to reduce defect rates.

Thinking about testing

The notion of thinking about testing calls on team members to challenge their assumptions about testing, such as the following:

• Testing must be done at the end.
• Testing must be done by dedicated testers.
• Development must be complete before testing can start.
• Testing must be done according to plan.

By encouraging team members to challenge their assumptions, the thinking about testing approach encourages more innovative ways to test a product at any point in the development process.

Test automation

Iterative, incremental program development results in a continuously evolving product that must be tested at each iteration. In addition to testing the new code, the product must be tested to ensure that the old code still works after the new code has been integrated (regression testing). In an agile development environment, manual testing can’t keep pace. Testing must be automated as much as possible.

Specification by example

Specification by example (SBE) is a collaborative approach to defining requirements and developing test case scenarios for software products. The product owner and teams collaborate with end users and other stakeholders to develop realistic scenarios for how the product will be used.

Role of manager

Traditionally, managers have been in charge of determining what needs to be done and how to do it. In a LeSS organization, the product owner (with team input) decides what needs to be done, and the Scrum teams figure out how to get it done. Management plays no role in either case and should resist any temptation to do so. Instead, managers function more as support personnel, ensuring that the product owner and teams have what they need to do their jobs and helping to remove any obstacles that may be getting in their way.

Go see

Go see is a method that closes the gap between management and product development to give managers greater visibility into what is happening in the organization. Managers are encouraged to sit with developers to find out what’s really going on, so they can make better decisions and figure out ways to help.

Teaching problem-solving

While traditional managers are expected to solve problems, LeSS shifts the manager’s role to teaching problem-solving and systems thinking and encouraging team members to think for themselves. The idea here is to move the problem-solving and decision-making responsibilities closer to product development, where they can be used more effectively to improve the product and the systems for creating it.

Self-management

One of the pillars of Lean thinking is respect for people. Instead of looking at employees as lemmings in need of strong leadership, Lean thinking sees them as highly motivated individuals who are able and willing to create high-quality products. Lean thinking encourages individuals and teams to be self-motivated and self-directed. As such, self-governing teams are expected to:

• Set their own direction
• Design the team and determine its role in the context of the organization
• Monitor and manage work process and progress
• Execute team tasks

Improvement service

Managers are in charge of developing an improvement service — a system for logging areas that need improvement and then addressing those issues. Following the LeSS framework, many organizations choose to create an improvement backlog. Managers consult with teams to determine areas of improvement and prioritize them. Teams can then choose items from the backlog to work on.

You may be able to find plenty of areas of improvement by looking at what comes out of the sprint review, retrospective, and overall retrospective at the end of each sprint (see the earlier section, “Sprint review, retrospective, and overall retrospective”). You may also consider conducting a workshop with the product owner, Scrum Masters, and teams to develop your initial improvement backlog.

Avoid adding items to the improvement backlog without first discussing them with the product owner, Scrum Master, and teams. Doing so will undermine the LeSS principle of self-management.

Manager as Scrum Master

The roles of manager and Scrum Master tend to overlap, so many organizations consider making the manager a Scrum Master. Is that a good idea? Well, that depends on the manager. If a manager is able and willing to relinquish control and authority to the teams and adopt a mindset of serving the team, such a move may make sense. If not, then it’s a bad idea, because a Scrum Master who acts as a traditional manager will undermine the democracy of the team.

Requirement areas

Requirement areas are customer-centric categories of backlog items, often referred to as product backlog items (PBIs) (see Figure 5-5). For example, a website may have a separate requirement area for articles and advertisements. The product owner draws items from the product backlog and assigns each to a requirement area to create different views of the product backlog called area backlogs, discussed next.

Area product backlog

When working on a very large product, the product owner can easily become overwhelmed, and because LeSS focuses on optimizing the whole system, the product owner can become a bottleneck for all the feature teams. The best way to steer clear of this potential bottleneck is to break down the work into smaller batches. So the product owner breaks down the product backlog into smaller batches, each of which comprises an area product backlog assigned to its own area product owner.

Lean thinking is about optimizing the whole and breaking down your work into smaller batches.

Area product owner

The area product owner maintains and prioritizes work items in a subset of the product backlog that pertains to a certain feature or a set of related features. Think of the area product owner as a product owner for a feature instead of for the entire product.

Organizational structure

The LeSS Huge framework is built on top of the regular LeSS framework, so it tries to add the minimum number of new roles and processes required to work on much larger products. Keep in mind that LeSS Huge is designed for eight or more teams, representing dozens, hundreds, or even thousands of developers. When you have that many people involved, you need an organizational structure to align their efforts. In LeSS Huge, the organizational structure, shown in Figure 5-6, involves the following areas:

• Head of product: The head of product provides the team with a unified vision of the product, communicating to everyone working on the product what it is and what it must do to serve the customers’ needs.

• Sites: The two “Site” boxes on the left indicate the preference of grouping related teams and team members locally when an organization encompasses multiple sites across two or more buildings, cities, or countries. The purpose of having “teams in site,” as the LeSS developers refer to this grouping, is to reduce the need for long-distance communication among teams.

  Although you want to keep your teams local to a given site, don’t group teams according to requirements areas, because such an approach often results in making certain requirements areas more permanent than they need to be. Instead, look at these site groupings as a way to keep line organization local. (Line organization is traditional top-down, chain-of-command, department organization.)

• Undone department: In LeSS, “done” means a product increment is deliverable to a customer. A new team may not have the knowledge and skills required to create a product increment that’s considered done, in which case the product enters the Undone department, where additional teams complete the work. The ultimate goal is to have no Undone department because, ideally, every team has the capacity to deliver potentially shippable product increments. However, the reality is that on large products, you’ll probably have to spin up new teams that have trouble delivering product increments that meet the criteria for the definition of “done,” so you’ll need this department to complete their work until all teams have the capability to create deliverable product increments (which may never happen). (See Chapter 6 for more about the definition of “done.”)

• Support: When teams are working on a huge product, they need more support in the form of configuration management, laboratory support, integration, and operations. On smaller products, regular LeSS teams can usually take care of a lot of the environmental requirements to deliver their product; for example, they can spin up their own servers and software development environments.

  Try to keep your support “department” as small as possible and maintain its focus on supporting the teams, not controlling them or trying to set direction. They should be seeking ways to help, not ordering teams to “do it this way.”

• Product owner team: The product owner team is made up of the product owner and area product owners, who work together to distribute work items and maintain and prioritize their respective backlogs.
• Competence and coaching: Products that need LeSS Huge can usually support full-time coaching and training staff. Some organizations create an agile center of excellence — typically a small group of coaches and trainers that thinks about ways to improve agile in the organization.

Staying close to Scrum

One of the core ideas behind LeSS is that you don’t have to add roles, events, rules, layers, and bureaucracy. You could take this lightweight Scrum framework and expand it out (wider but not necessarily deeper) to meet all your scaling needs. In other words, Scrum is all you need.

This approach differs significantly from how other enterprise agile frameworks deal with Scrum. The SAFe framework puts Scrum in the bottom corner of its diagram. Scrum is seen as just one of several agile practices you can use for your team. You could easily run SAFe without Scrum at all. (See Chapter 4 for more about SAFe.) All your teams could use Kanban, or Extreme Programming. They could even use a mishmash of agile methods such as ScrumBan or ScrumXP.

Disciplined agile (DA) also sees Scrum as a team-level set of practices. To deliver an enterprise-level product, you need to fill in the gaps that the lightweight Scrum intentionally leaves, which is why disciplined agile delivery (DAD) creates ten new roles to deliver agile enterprise software. (See Chapter 6 for more about DAD.)

Exposing flaws in processes

Like Scrum, LeSS sees itself as a way to expose flaws in processes. The combination of small teams and short development cycles enhances transparency, making failures more apparent. Again, other frameworks give you many more answers. Both SAFe and DAD add layers of new processes. While these layers provide additional guidance, they tend to obscure problems.

Staying simple

Above all, LeSS embraces Scrum’s approach to simplicity. The creators of LeSS like to think of enterprise frameworks as having two extremes. On the one hand you have very process-heavy frameworks. These might include the rational unified process (RUP), traditional waterfall approaches (see Chapter 1), or even SAFe. On the other hand, you have very lightweight principles and ideas such as Lean Software Development and Kanban. LeSS positions itself between the two, providing just enough structure and guidance to create high-functioning teams that collaborate closely.

Scrum is simple and lightweight and designed to expose flaws. The creators of LeSS believe that’s why Scrum is widely used. They want to take these ideas and apply them to large organizations without losing sight of what has made Scrum so successful.

Working with the development team

The product owner has two primary responsibilities in regard to the development team:

• Prioritization: After analyzing information related to profit drivers, strategic customers, business risks, and other factors, the product owner prioritizes items in the product backlog.
• Clarification: To a lesser degree, the product owner clarifies items in the product backlog. I say “to a lesser degree,” because this is a shared responsibility between the product owner and the teams. They work together to clarify features and functionality.

The product owner also ensures that what the teams build “hit the mark” and finds out what the teams need and how to meet those needs to remove any obstacles that may be hindering their efforts.

Teaming up with the customer

The product owner maintains a close relationship with the customer to deliver to the customer-centric solutions that meet their needs in a timely manner. She needs to know their goals and understand their key challenges and, when appropriate, challenge the customer if she envisions something beyond what the customer wants.

Facilitating communication between teams and customers

Ideally, customers and developers collaborate on solutions that best meet the customer’s needs. The product owner must encourage and facilitate this open communication between the two. As their knowledge of the customer and product grows, developers often come up with interesting new ideas on their own. In many ways they understand the internals of the product better than anyone else. These teams will come up with the best ideas if they have an overall understanding of the customer’s expectations.

Collaborating with higher management

Although product owners are expected to maintain a productive relationship with higher management (portfolio managers and C-level executives and so on), it’s really a two-way street that requires more from higher management than from the product owner:

• The product owner must understand and appreciate higher management’s concerns for return on investment and market share and increase visibility into product development status.
• Higher management should respect the fact that the product owner’s primary responsibility is to ensure product quality and customer satisfaction. For example, executives must not be pulling product owners and teams offline to attend to their pet projects. Higher management is also responsible for ensuring that the product owner has the information and resources to do her job.

Coordinating with the Scrum Master

The relationship between the product owner and the Scrum Master is one of student and teacher. Scrum Masters are expected to be aware of the product owner’s challenges and concerns and provide helpful guidance while also educating the product owner about LeSS. The ultimate goal is to increase the product owner’s knowledge and influence behaviors that facilitate product development in the LeSS framework.

Sticking with the three adoption principles

Embrace the following three principles when adopting LeSS:

• Deep and narrow over broad and shallow: Try LeSS on one product line and get it right before rolling it out across your entire organization.
• Top down and bottom up: Management should provide support, mostly in the form of training and coaching, to help product owners, Scrum Masters, and teams make the transition. The focus should be on support, not control. Everyone in the organization, from the bottom up, needs to embrace LeSS and develop a deeper understanding of its principles and practices.
• Use volunteering: Encourage volunteering, through education and discussion, to get the process rolling. Volunteers can help with the formation of teams and communities of practice.

Stepping through the LeSS adoption process

The LeSS Company recommends starting with one product line prior to gradually rolling out LeSS to the entire organization. To transition a product line to LeSS, the LeSS Company recommends the following six steps:

1. Educate everyone.
2. Define “product.”
3. Define “done.”
4. Have appropriately structured teams.
5. Make sure only the product owner gives work to the teams.
6. Keep project managers away from the teams.

STEP 3: DEFINE “DONE”

All Scrum teams working on a project must agree on a definition of “done” (DoD) — a set of acceptance criteria that’s consistent across all user stories. (Acceptance criteria are conditions that a product must meet to satisfy the stakeholders. A user story is a feature described from a user’s perspective, as explained in Chapter 1.) For example, the DoD may be that at the end of every sprint, all the code has been tested and works with the rest of the application.

Each function or feature may have its own acceptance criteria, but they all have the same DoD. For example, suppose you’re on a Scrum team that’s creating a smartphone app to search for local restaurants. Your team is in charge of creating a feature that allows you to search for a menu item across several different restaurants. The acceptance criteria for that feature may include the need for a box into which the user can type keywords, autocomplete based on common menu items, and the ability to limit search results to a certain radius from where the user is located. The feature won’t be satisfactory until it meets all of those acceptance criteria.

Another team is working on a feature that enables the user to get directions to whichever restaurant is selected. If the user clicks on a restaurant, the resulting page has a button labeled “Get Me There” that accesses the user’s Maps app, inserts the restaurant’s address, and triggers the Maps app to conduct the search. These acceptance criteria differ entirely from those of the previously described feature.

Both teams meet with the product owner, who tells them that the features must run on iOS and Android and be unit tested and integrated into the app. These acceptance criteria comprise the DoD, because they apply to both features.

In LeSS, all your teams need to be working off of a common definition of “done” to increase transparency, avoid delays, and increase flexibility. Without a clear idea of what constitutes “done,” teams may develop an end product that may or may not be ready to ship, as shown in Figure 5-9. As the figure shows, after releases 21-40 and releases 41-60, the teams are unsure whether the product is done or not done, which leaves the product owner wondering at any given point after that, “Is the product done or not?” Remember that work from all the teams must come together in the end, and they can’t do that without a shared definition of “done.”

Conducting a Sprint Planning 1 meeting

In the Sprint Planning 1 meeting, the product owner and all teams meet together to look at the product backlog and determine which teams will work on which items. This meeting is typically short, especially when the product owner and teams are experienced and have been working together for some time. Experienced teams usually know which teams are best at handling different types of work.

If you’re the product owner, you conduct the meeting, but your job is pretty simple; you present the highest priority items in your product backlog to the teams and give the teams some time to distribute the work among themselves. You may need to field some questions from the teams to clarify items in the product backlog.

Here are a few tips for conducting an effective and efficient Sprint Planning 1 meeting:

• Limit the number of participants, especially if you have more than two teams. Each team can have one or two representatives who know the team’s capabilities.
• Don’t let a Scrum Master represent any of the teams, because the Scrum Masters aren’t actually members of any team. They may not know the team well enough or have the trust of other team members to give them the authority to select work items.
• Discuss the definition of product and the definition of “done,” so all teams are on the same page. As product owner, one of your primary responsibilities during the Sprint Planning 1 meeting is to align all the teams with a vision of the product and the definition of “done” acceptance criteria for the end of the sprint.
• Encourage the team reps to ask questions and discuss concerns. This may be the only time you have all the teams in one room. They can often help to resolve any issues before development commences.
• Discuss any potential need for the teams to coordinate their efforts and, if two or more teams need to collaborate, ask them to plan for a Multi-Team Sprint Planning 2 meeting, when the teams can plan how they’ll work together.

Conducting a Sprint Planning 2 meeting

In the Sprint Planning 2 meeting, each team meets to figure out how the team will complete the work it agreed to perform during the Sprint Planning 1 meeting. If two or more teams need to collaborate during the sprint, they meet together, and the Sprint Planning 2 meeting is referred to as a Multi-Team Sprint Planning 2 meeting.

The goal of either meeting is for each team to walk out with a sprint backlog — a prioritized list of work items the team must complete by the end of the sprint. Each team may create a sprint task board or just a list of work items.

If you’re doing a Multi-Team Sprint Planning 2 meeting, have all the teams involved meet in the same location at the same time with each team conducting its own Sprint Planning 2 session. This gives the teams the opportunity to discuss any shared design, coordinate their shared work, identify opportunities for collaboration and cross-training or knowledge-sharing, and deal with any foreseeable issues.

Keeping teams chatty

LeSS encourages teams to be chatty. You don’t want any team stuck in formal meetings. Instead you want all teams’ members to be able to get what they need by grabbing a neighbor for a quick chat or hollering across the room to a member from another team.

Most formal meetings waste time, dilute focus, and demotivate. Think about the last time you were in a formal meeting with ten or more people sitting around the table. Most of what you hear isn’t relevant to your work, so you spend a lot of time just sitting and answering email, thinking about ways you could spend your time more productively, or praying for someone to end the meeting soon.

By encouraging informal communication, LeSS enables teams to work more and spend less time in pointless, unproductive meetings. You get up, grab the person who has the information you need, have a brief chat, and get back to work. You meet on a need-to-know basis.

Coordinating with Daily Scrums

LeSS encourages teams to have Daily Scrum meetings lasting 15 minutes or less, usually at the beginning of the day. In a Daily Scrum meeting, team members stand around in a circle and take turns delivering a brief update on the following three items:

• What they accomplished since the last meeting
• What they’ll accomplish before the next meeting
• Any obstacles standing in their way

During the Daily Scrum meeting, don’t spend a lot of time in discussion. If more discussion is needed, arrange a follow-up meeting, perhaps with the Scrum Master, to figure out how to remove any obstacles or to deal with other issues.

If your team is collaborating with another team, considering sending a representative from your team to the other team’s Scrum meeting to listen in. This is a great way to enhance communication across teams.

Communicating in code

Some teams choose to work with a continuous integration server to “communicate in code.” This type of server is usually a central code repository, sort of like Google Docs for programmers. Instead of emailing everyone about a change you made or are thinking of making, you just do the work and add comments about the change. When members of your team or another team check out the code, they can easily spot the change or proposed change.

Creating communities of practice

Like SAFe, LeSS encourages the formation of communities of practice (CoPs) — people across the organization who share a common interest or specialty and often work on developing best practices.

For example, suppose each of your feature teams has a developer who works well as a database engineer. That developer may want to work with other developers and different teams to create a set of common practices. They work together almost like an internal meetup group. They share their thoughts on engineering practices and the best development techniques, and they may even cross-train members of other teams who are interested in database engineering but know little or nothing about it. (See Chapter 4 for more about CoPs.)

Engaging in an overall product backlog meeting

During the overall product backlog meeting, the shorter of the two stages in the refinement process, teams or team reps work closely with the product owner to figure out which items to add to the product backlog. If you’re the product owner, you present your highest value items to the team reps, and you work with them to select items for further refinement. The goal of this initial meeting is to create an aggressive product backlog that’ll be whittled down in future product backlog refinement meetings.

If you’re a team rep in the overall product backlog meeting, you give the product owner a rough idea of the work and time required for each item, ask questions to clarify items, and provide additional input and insight to help with the refinement process. Make sure you know what the product owner has in mind for each item in the backlog; if you don’t know, keep asking questions to clarify. You may also work with the product owner to connect items in the backlog; for example, to identify items that may be developed more efficiently when worked on together during a future sprint.

Whether you’re a product owner or a team rep, agree on an estimation technique for the relative size of work items. Some teams use T-shirt sizing — Small, Medium, Large, and XL. Having only four sizes keeps the haggling over size estimates to a minimum. If you need a more precise estimate, consider using planning poker, as I describe in Chapter 1.

At the end of the meeting, you should have a collection of high-level items ready for individual or multiple teams to refine further.

Refining the product backlog at the team level

After the overall product backlog refinement meeting, the teams or team reps take their portion of the product backlog back to their teams for further refinement. Some items selected during the overall meeting may go to individual teams, while others go to two or more teams (multi-teams) for further refinement:

• Team refinement: The team works with users and other stakeholders to refine its portion of the product backlog.
• Multi-team refinement: Two or more teams or the representatives of these teams collaborate with users and stakeholders to refine their portion of the product backlog. Multiple teams need to work together on refining the backlog if any items they’ll be working on have dependencies that require their coordinated work to complete.

In either case, during the product backlog refinement meeting, team members collaborate with users and other stakeholders to clarify items in the backlog, split big items into smaller items, analyze items, reestimate, and reprioritize. Here are a few suggestions for improving the outcomes of these product backlog refinement meetings, whether they involve one team or more:

1. Clarify what needs to be done in your team’s portion of the product backlog.

   Consult the product owner if further clarification is needed.

2. Break down any items that can be broken down into smaller work items.
3. Use an estimation technique, such as planning poker (see Chapter 1), to get some idea of the work and time required to complete each item.
4. Reprioritize the items on your list.

At each step, try to give everyone a voice and avoid groupthink — a tendency for people to go along with the group or agree with a more charismatic member of the group instead of thinking creatively and expressing their own ideas and opinions.

Multi-team refinement meetings can be nightmarish if not run correctly. Getting five to nine people on a team to agree on anything is difficult enough. Imagine trying to get additional teams to agree on what needs to be done, how to get it done, and how to work together. You may have 15 people or more trying to estimate how long it will take each team to deliver its chunk of the product.

Involve team members in the product backlog refinement process. Don’t leave it up to Scrum Masters to make these decisions. Team members have a clearer idea of what needs to be done, how to do it, and how much work each item is likely to require. Work always seems easier when you’re not the person who’s going to be doing it.

Conducting sprint reviews

At the end of each sprint, the teams, product owner, customers, users, experts, executives, and anyone else who’s interested gather to review the product built during the sprint and discuss changes and new ideas to formulate the future direction of the product and to improve the process for building it. The maximum length of a sprint review is one hour per week of sprint; for example, two hours for a two-week sprint.

The purpose of the sprint review is to inspect and adapt, not inspect and accept. Teams shouldn’t just showcase their work in an attempt to impress customers, company executives, and other stakeholders. The product owner and team should come to the meeting with an eagerness to learn from the review, and the users and other stakeholders should be prepared to be approach the process with a critical mind. Maintain focus on empirical process control — making data-driven decisions to improve product and process. Shut down any attempts to blame anyone or any team for mistakes, because doing so discourages innovation.

Although a sprint review has no set agenda, it usually goes like this:

1. The users and the product owner inspect the product (preferably by actually using it).

   For example, you may have a review room with several computers running the program that was developed during the sprint. Users and other stakeholders attending the meeting can take the product for a spin.

2. All participants engage in a discussion of the product to determine what can be improved.
3. The teams, Scrum Masters, and product owner engage in an in-depth discussion of what they need to do moving forward to improve both the product and the process for building it.

The LeSS developers recommend a diverge-converge approach to the sprint review:

• Diverge: Conduct this stage of the sprint review as a bazaar or science fair. Meet in a large room with multiple “stations” staffed by team reps, where product owners, users, and other stakeholders can try the features each team developed and engage with the team reps in discussions about the product. Stakeholders visit any of the “stations” that interest them.
• Converge: Gather as a group and have the stakeholders summarize the insights and opinions they developed during the bazaar. At this time, you may also want to present a subset of items developed during the sprint and inspect the items as a group.

You may have two or more diverge-converge cycles, culminating with a meeting between team reps and the product owner to clarify the future direction of the product and discuss ways to improve the process for building it.

Try the bazaar/science-fair approach as a first step, but remain open to other options. What works well for one organization or a certain product may not work well for another. Be open an honest about what’s working and what’s not and look for ways to improve your sprint review process.

Looking back with retrospectives

After the sprint review, each team conducts a team retrospective to discuss process improvements. This is the same as the one-team retrospective in Scrum. During the retrospective, team members discuss the obstacles impeding their work and possibly the work of other teams and add these obstacles to an organizational improvement backlog.

Avoid the common mistake of conducting retrospectives as gripe sessions. Keep the focus on improving the process for creating the product. Discourage any attempts to point blame at certain individuals, teams, or others within the organization.

Going deep with an overall retrospective

Unlike Scrum, LeSS adds a meeting after the team retrospectives called an “overall retrospective,” which is typically conducted just before the beginning of the next Sprint Planning 1 meeting. In the overall retrospective meeting, the product owner, Scrum Masters, team reps, and any managers gather to discuss cross-team, organizational, and systemic challenges that may be impeding workflow and compromising quality.

Here are some common topics you may want participants to discuss during the overall retrospective:

• Whether teams have close contact with customers and other stakeholders
• Whether cross-team communication and coordination can be improved and, if so, how
• How well the teams are working together
• Whether communities of practice are forming, are active, and are supporting the organization’s success
• Anything that happened during the sprint that a team should share with other teams
• Whether teams are engaging in continual learning and are learning from each other
• How well the product owner is maintaining all five of the relationships she’s responsible for
• Any organizational issues that are standing in the way of progress or preventing teams from excelling

A key LeSS principle is to use systems thinking. During the overall retrospective, don’t focus on what’s going on within each team, but what’s going on across teams and across the entire organization that may be affecting team performance. The overall retrospective is an exercise in improving the system.

Questioning the claim that culture follows structure

LeSS is built on the notion that “culture follows structure,” which is the fourth of Larman’s four laws (see the earlier sidebar “Avoiding common adoption traps: Larman’s Laws”). Others believe that structure follows culture. This debate is similar to that between behaviorists who believe that animal behavior can be conditioned through outside stimuli and cognitive scientists who believe you can control someone’s behavior by changing the way the person thinks.

Both debates represent either/or fallacies that are often disproven by others who take a “both, and” approach. In other words, instead of embracing Larman’s claim that “culture follows structure” or the opposite claim that “structure follows culture,” accept that both structure and culture play important roles in a successful transformation and work toward changing both.

The funny thing is that Larman’s fourth law, “Culture follows structure,” totally contradicts Step 1 in the six-step LeSS adoption process: “Educate everyone.” An attempt to educate everyone is an attempt to change people’s mindsets and the organization’s culture as a whole. So avoid taking Larman’s fourth law too seriously and try to size up your organization first:

• If your organization is highly resistant to big change, you may need to focus on changing minds and culture first. Otherwise, people are likely to reject any new structure you try to implement.

  If your organization is highly resistant to change, consider introducing big change gradually. You may want to start with one or two Scrum teams and, when they achieve success, expand from there. When people start to see the benefits, they’ll be more receptive to accepting the new approach.

• If your organization has a culture that readily embraces change, people will probably embrace any new structure you introduce, whether it’s the LeSS framework or something else. If this description fits your organization, you may be able to introduce the LeSS framework without concerning yourself too much about changing your organization’s culture.

Watching out for over-scaling

One of the most common and serious problems that undermines attempts to adopt LeSS is related to over-scaling in one or both of the following ways:

• Making too many changes too quickly for the organization to adjust
• Choosing big solutions to small challenges

In this section, I suggest ways to avoid these two common pitfalls.