Loading...

LeSS - Just Scrum at Scale - Nothing More, Nothing Less!

Since 2005, Craig Larman and Bas Vodde have been working with many organizations to scale Scrum, Lean, and Agile Development to big product groups. They turned their experience and knowledge gained from this study into the draft of an agile framework called "Large-Scale Scrum (LeSS)".

While many thought-leaders have come out with such guidance, Craig and Bas believed that 'Scrum' as a framework has all elements required for the efficient adoption of Agile, irrespective of the scale. The available set of roles, processes, and artifacts was sufficient for successful implementation of Agile. Thus, they formulated LeSS with no additional jargons or sophisticated artifacts.

  1. Is applicable to multiple teams that are cross-functional, cross-component, full-stack feature teams of 3 to 9 self-motivated, learning focused members
  2. Working together involving collaborative effort with a common goal to deliver one common shippable product at the end of a common Sprint
  3. Focusing on 'One Product' that is a broad complete end-to-end customer-centric solution that real customers can use. It is not limited to a component, platform, layer, or library

LeSS has two frameworks:

  1. LeSS that involves 2 - 8 teams
  2. LeSS Huge for more than 8 teams

LeSS Framework Figure 1 : LeSS Framework

Let us delve deeper into the LeSS framework, and look at the processes to be followed to adopt this framework.

Step 1: Define your Product

One of the core principles of LeSS is to keep a 'Whole Product Focus'. With this principle, the stress is on the fact that all teams need to focus on the product as a 'Whole', instead of their individual parts, tasks, or specialization. There is no value in providing individual or half working parts.

A 'Product' is what the customer utilizes, sees, and values as a whole.

Let us understand this further. According to you, which of the following can be considered a 'Product'?

  1. The Hardware Circuit Board of an Automated Navigation System
  2. An Automated Navigation System as a whole, including the hardware and software
  3. A car, which includes all the parts together

Obviously, what a customer sees as a whole product is the 'Car' itself, which forms the broad definition. Defining a broad Product, from a customer-centric point of view, yields the following benefits:

  • Aids customer-centric prioritization
  • Creates simpler organizations around the product
  • Attracts focus towards the real problem and impact, rather than on requested 'Requirements'

Managing the 'Product' at the broadest level may not always be practical. With the broad definition, limit the definition to what is as practical as possible, by taking into consideration existing structures, planned organizational development, and feasibility of structural changes and so on.

LeSS de-scales organizational complexity by providing broader product definitions, dissolving unnecessary complex organizational solutions, and finding simpler solutions.

When planning a LeSS adoption, start with an effective Product definition. The Product definition determines:

  1. The scope of the product backlog
  2. The Product Owner, and
  3. The team strength based on the product size

Step 2: Define your Product Team

In LeSS, organization is structured into 'Product Teams' with more focus on the 'Whole Product'. A Product Team, is a team of 2-8 Feature Teams. A 'Feature Team' is a long-living, cross-functional team comprising of generalizing specialists that completes many end-to-end customer features one-by-one.

LeSS necessitates that the team has the necessary knowledge and skills to complete an end-to-end customer-centric feature. If not, the team is expected to learn or acquire the needed knowledge and skills as they proceed.

A Product Team Figure 2: A Product Team

The above figure depicts a 'Product Team' structure in LeSS. This team has a 'Whole Product' focus and hence, they work on a single 'Product Backlog'. As they are 'Feature Teams', they are capable of working on any item in the Product Backlog.

If any Feature Team member does not have the necessary skill to work on a specific requirement, learning is "Forced" thereby, breaking the over specialization constraint.

Step 3: Manage Product Backlog and Continuous Refinement

The Product team work towards building a single product, and work from a single Product Backlog that defines all the work to be done for the product.

LeSS maintains one Product Owner for this Product Backlog, who supports the 'Whole Product' focus. The Product Owner creates and manages the Product Backlog along with the teams and focuses on two key information flows:

  1. Prioritizing items in the Product Backlog
  2. Clarifying items in the Product Backlog to the teams

The Product Owner also continuously engages in 'Product Backlog Refinement'. Typically, not later than the middle of a sprint, the teams along with the Product Owner refine items to make it ready for the next sprint. Key activities of Product Backlog Refinement are:

  1. Splitting big items
  2. Detailing items until ready
  3. Estimating

This refinement is done at three levels:

  • Overall Product Backlog Refinement -

    Representatives from all teams, along with the Product Owner decide on the items for the next sprint. This helps bring a common understanding among teams and also helps each one get a holistic picture.

  • Team Level Product Backlog Refinement -

    After acquiring an overall understanding of the sprint requirements, the teams deliberate on their specific backlog items and attain more clarity on the items picked for the next sprint. The Product Owner is informed of any changes to the backlog, such as splitting of items or new estimates

  • Multi-team Product Backlog Refinement -

    In scenarios, where teams have inter-dependencies with other items, LeSS recommends a Multi-team Product Backlog Refinement session.

Step 4: Perform Sprint Planning (One & Two)

Once the Product Backlog is refined and a substantial number of items are in 'Ready' state, items are planned and delivered as per Product-Level 'Sprint', leading to an integrated 'Potentially Shippable Product Increment'.

The Sprint starts with 'Sprint Planning' that consists of two parts: the first part focuses on the 'What' and the second focuses on the 'How' of those items that will be delivered.

  1. Sprint Planning One (Common for all teams) -

    At the beginning of the Sprint, all the members from all teams attend the Sprint Planning One. However, as the sprints mature and the understanding of the team improves, only representatives from each team attend the Sprint Planning One event. The Product Owner and team or representatives from each team attend this meeting and pick the items from the Product Backlog that they will work on for the next sprint.

  2. Sprint Planning Two (Done separately for each team) -

    After the items are selected by the team (from Sprint Planning One), the team holds their own Sprint Planning Two meeting. When there are strong interdependencies among teams, a combined Sprint Planning Two is conducted by these teams to identify interdependencies and figure out how to handle them effectively. At the end of this meeting, the teams have better clarity on the work to be done by each of them in that sprint and each proceed to work towards their respective sprints.

LeSS consciously avoids the notion of a 'Release Planning' activity because this tends to make product groups:

  • Think of a major Release Planning activity shortly before the upcoming release cycle
  • Then start development activities towards that release

This mindset is just a variation of 'Order the meal, then wait for delivery of the meal', which is associated with the traditional 'Contract Game' and inconsistent with the 'Cooperative Game' of invention and communication in agile planning.

Hence, Sprint Planning One and Two is essentially a rolling wave release planning activity that happens continuously with every sprint yielding a 'Potentially Shippable Increment', which the Product Owner can decide to 'Ship' at any sprint

Step 5: Execute the Sprint with Coordination and Integration

Post Sprint Planning, each of the teams start working on the items in their Sprint backlog. Each team practices the 'Daily Scrum' to ensure they have all the information they need to take shared responsibility and achieve the 'Sprint Goal'. Additionally, in LeSS, 'Daily Scrum' is used for 'Coordination' across teams by having members from other teams join these meetings.

During the Sprint, all teams may adopt decentralized coordination and integration to ensure smooth execution that results in a 'Potentially Shippable Increment'. Some of the Coordination techniques are:

  1. Just Talk -

    Any team member should be able to walk up and talk easily to any member of another team to discuss any issue or deal with any dependency. When the need for coordination arises, people should be able to reach out and 'Just Talk' - in person, over call, chat, or email.

  2. Communicate in Code -

    Adopt 'Continuous Integration' so that all team members check code into mainline. Post commits, team members should talk to others about the changes in order to synchronize with others.

  3. Send Observers to Daily Scrums -

    Another technique is for teams to send representatives to other teams as 'Silent Observers' to report back on updates and key information.

  4. Component Communities and Mentors -

    Knowledge and experience gained around components, their technologies and needed skills have to be made known, and for this 'Communities of Practices [CoP]' may be created for the components and communicated with all teams. These communities are often organized by 'Component or Community' mentors, who are part of a 'Feature Team', and take up additional responsibilities like:
    1. Being mentor or guide for the component or technology area
    2. Monitoring the long-term health of the component
    3. Organizing a component community
    4. Organizing design workshops
    5. Reviewing code
    Besides coordination, these communities also help in improving code quality as well as design.

  5. Scrum of Scrums -

    This is a 'Daily Scrum' like meeting among teams, to synchronize on relevant work, remove obstacles, and work on dependencies.

  6. Technical Experts as Travelers -

    Many product teams rely on a couple of experienced technical experts. The 'Travelers' join different teams, resolve bottlenecks, and also bring in consistency.

As all teams coordinate and continuously integrate, the execution of the sprint results in a 'Potentially Shippable Increment'.

Step 6: Review and Retrospective

Post sprint execution, review and retrospection happens to inspect and adapt.

  1. Sprint Review:

    Sprint Review is where all the teams review the one potentially shippable product increment with the focus always being on the 'Whole Product'.

    The Sprint Review is conducted as a grand event like a 'Bazar' or 'Fair', using a diverge-converge pattern. During the 'Diverge', each team is allotted a station to demonstrate their accomplishments of that sprint. The stakeholders attending the event can visit the stations in which they are interested. Post this, there would be multiple converge cycles where the stakeholders summarize their opinions about the fair. Post the review, the teams, Product Owner and users, customers or stakeholders decide on the direction of the Product.

  2. Sprint Retrospective:

    Similar to planning, the retrospective happens at two levels.

    1. Team Retrospective: The individual teams reflect on the learnings from the sprint gone by, and inspect on what needs to be done differently to deliver faster and better.
    2. Overall Retrospective: Post this, an 'Overall Retrospective' is conducted where all the teams look back at the previous sprint and deep dive into how the teams are working together, sharing with each other and the previous scenarios that could have been handled differently to perform better and in perfect harmony.

Conclusion

Scrum as a methodology has been extremely beneficial for teams to bring incremental delivery and adapt to changes faster through feedback loops. One of the main reasons for it being one of the most adopted Agile Methodologies is because Scrum hits an ideal balance between abstract principles and concrete practices.

Taking the same philosophy further, Craig Larman and Bas Vodde have come up with Large Scale Scrum [LeSS] that achieves the same balance for larger product groups. LeSS isn't new Scrum or improved Scrum. Neither is it 'Scrum at the bottom for each team, and something different layered on top'. LeSS is about figuring out how to apply the principles, purpose, and elements of Scrum in a large-scale context as simple as possible.

It is for this reason, that the framework does not introduce any new roles or artifacts, and makes it very easy for large teams to understand and adopt.

References

https://less.works/

index