The Scrum@Scale Framework

Written by   on   in , ,   with No comments

Scrum of Scrums (SoS)

A Scrum of Scrums operates as if it were a Scrum Team, satisfying the Team Process component with scaled versions of the Scrum accountabilities, events, and artifacts. While the Scrum Guide defines the optimal team size as being fewer than 10 people, Harvard research has determined that the optimal team size is 4.6 people (on average). Therefore, the optimal number of teams in a Scrum of Scrums is 4 or 5.

As a dynamic group, the teams composing the Scrum of Scrums are responsible for a fully integrated set of potentially shippable increments of product at the end of every Sprint. Optimally, they carry out all of the functions required to release value directly to customers.

Scrum of Scrums of Scrums (SoSoS)

Depending upon the size of the implementation, more than one Scrum of Scrums may be needed to deliver a complex product. In such cases, a Scrum of Scrum of Scrums (SoSoS) can be created out of multiple Scrums of Scrums. Each of these will have scaled versions of each Scrum of Scrums’ roles, artifacts, and events.

Scaled Events

  • Scaled Daily Scrum (SDS). 
    • The main talking points of a Daily Scrum are the progress towards the Sprint Goal and impediments to meeting that commitment. 
    • In a scaled setting, the Scrum of Scrums needs to understand collective progress and be responsive to impediments raised by participating teams; therefore, at least one representative from each team attends a Scaled Daily Scrum (SDS). 
    • Any person or number of people from participating teams may attend as needed.
    • To optimize collaboration and performance, the Scaled Daily Scrum event mirrors the Daily Scrum, in that it:
      • Is time-boxed to 15 minutes or less.
      • Must be attended by a representative of each team.
      • Is a forum to discuss how teams can work together more effectively, what has been done, what will be done, what is going wrong & why, and what the group is going to do about it
      • Some examples of questions to be answered:
        • What impediments does a team have that will prevent them from accomplishing their Sprint Goal or that will impact the delivery plan?
        • Is a team doing anything that will prevent another team from accomplishing their Sprint Goal or that will impact their delivery plan?
        • Have any new dependencies between the teams or a way to resolve an existing dependency been discovered?
  • Scaled Retrospective. 
    • Every Sprint, the Scrum of Scrums holds a scaled version of the Sprint Retrospective where the Scrum Masters of each team get together and discuss what experiments have been done to drive continuous improvement and their results. 
    • Additionally, they should discuss the next round of experiments and how successful improvements can be leveraged across the group of teams or beyond.

Scaled Accountabilities

  • Scrum of Scrums Master (SoSM). 
    • The Scrum of Scrums Master is accountable for ensuring the Scaled events take place, are productive, positive, and kept within the time box. 
    • The Scrum of Scrums Master may be one of the team's Scrum Masters or a person specifically dedicated to this role. 
    • They are accountable for the release of the joint teams' efforts and continuously improving the effectiveness of the Scrum of Scrums. This includes greater team throughput, lower cost, and higher quality. In order to achieve these goals, they must:
      • Work closely with the Chief Product Owner to deliver a potentially releasable product increment at least every Sprint.
      • Coordinate the teams’ delivery with the Product Owners' Team's release plans
      • Make impediments, process improvements, and progress visible to the organization
      • Facilitate the prioritization and removal of impediments, paying particular attention to cross-team dependencies
  • Executive Action Team (EAT). 
    • It fulfills the Scrum Master accountabilities for an entire agile organization. This leadership team creates an agile ecosystem that allows the Reference Model to function optimally, by:
      • Implementing the Scrum values
      • Assuring that Scrum roles are created and supported
      • Scrum events are held and attended
      • Scrum Artifacts and their associated commitments are generated, made transparent, and updated throughout each Sprint.
      • Formulating guidelines and procedures that act as a translation layer between the Reference model and any part of the organization that is not agile.
    • The Executive Action Team is accountable for removing impediments that cannot be removed by members of the Scrum of Scrums (or wider network).


Notes

  • Scrum@Scale is also known as Scrum of Scrums.

References

Share:

The LeSS Framework

Written by   on   in ,   with No comments

Agile development with Scrum requires a deep organizational change to become agile. Therefore, neither Scrum nor LeSS should be considered merely a practice. Rather, they form an organizational design framework.

LeSS provides two different large-scale Scrum frameworks. Most of the scaling elements of LeSS are focused on directing the attention of all of the teams to the whole product instead of "my part." Global and "end-to-end" focus are perhaps the dominant problems to solve in scaling. The two frameworks – which are basically single-team Scrum scaled up – are:

  • LeSS: Up to eight teams (of eight people each).
  • LeSS Huge: Up to a few thousand people on one product.

Same as Scrum

LeSS is a scaled-up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:
  • A Single Product Backlog (because it’s for a product, not a team),
  • One Definition of Done for all teams.
  • One Potentially Shippable Product Increment at the end of each Sprint.
  • One Product Owner.
  • Many complete, cross-functional teams (with no single-specialist teams),
  • One Sprint.

Different than Scrum

  • Sprint Planning Part 1: In addition to the one Product Owner, it includes people from all teams. Let team members self-manage to decide their division of Product Backlog Items. Team members also discuss opportunities to find shared work and cooperate, especially for related items.
  • Sprint Planning Part 2: This is held independently (and usually in parallel) by each Team, though sometimes for simple coordination and learning two or more Teams may hold it in the same room (in different areas).
  • Daily Scrum: This is also held independently by each Team, though a member of Team A may observe Team B’s Daily Scrum, to increase information sharing.
  • Coordination: Just Talk, Communicate in Code, Travelers, Open Space, and Communities.
  • Overall PBR: There may be an optional and short overall Product Backlog Refinement (PBR) meeting that includes the Product Owner and people from all teams. The key purpose is to decide which teams are likely to implement which items and therefore select those items for later in-depth single-team PBR. It is also a chance to increase alignment with the Product Owner and all teams.
  • Product Backlog Refinement: The only requirement in LeSS is single-team PBR, the same as in one-team Scrum. But a common and useful variation is multi-team PBR, where two or more Teams are in the same room together, to increase learning and coordination.
  • Sprint Review: In addition to the one Product Owner, it includes people from all teams, and relevant customers/users, and other stakeholders. For the phase of inspecting the product increment and new items, consider a “bazaar” or “science fair” style: a large room with multiple areas, each staffed by team members, where the items developed by teams are shown and discussed.
  • Overall Retrospective: This is a new meeting not found in one-team Scrum, and its purpose is to explore improving the overall system, rather than focusing on one Team. The maximum duration is 45 minutes per week of Sprint. It includes the Product Owner, Scrum Masters, and rotating representatives from each Team.

Less Huge

References

Share:

The Nexus Framework

Written by   on   in ,   with No comments

A Nexus is a group of approximately three to nine Scrum Teams that work together to deliver a single product; it is a connection between people and things. A Nexus has a Single Product Owner who manages a single Product Backlog from which the Scrum Teams work.

The Nexus framework defines the accountabilities, events, and artifacts that bind and weave together the work of the Scrum Teams in a Nexus. It minimally extends the Scrum framework only where absolutely necessary to enable multiple teams to work from a Single Product Backlog to build an Integrated Increment that meets a goal.

The Nexus Framework helps teams solve common scaling challenges like reducing cross-team dependencies, preserving team self-management and transparency, and ensuring accountability. 

  • Nexus helps to make transparent dependencies. 
  • Nexus provides opportunities to change the process, product structure, and communication structure to reduce or remove these dependencies.

Nexus Accountabilities

  • Nexus Integration Team. The Team is accountable for ensuring that a done Integrated Increment (the combined work completed by a Nexus) is produced at least once a Sprint. 
    • It provides the focus that makes possible the accountability of multiple Scrum Teams to come together to create valuable, useful Increments, as prescribed in Scrum.
    • Integration includes addressing technical and non-technical cross-functional team constraints that may impede a Nexus’ ability to deliver a constantly Integrated Increment.
    • It should use bottom-up intelligence from within the Nexus to achieve resolution.
  • The Product Owner: 
    • A Product Backlog has a single Product Owner who has the final say on its contents. 
    • The Product Owner is accountable for maximizing the value of the product and the work performed and integrated by the Scrum Teams in a Nexus. 
    • Is accountable for effective Product Backlog management.
  • A Scrum Master: 
    • The Scrum Master in the Nexus Integration Team is accountable for ensuring the Nexus framework is understood and enacted as described in the Nexus Guide. 
    • This Scrum Master may also be a Scrum Master in one or more of the Scrum Teams in the Nexus.        
  • One or more Nexus Integration Team Members: 
    • Scrum Team members who help the Scrum Teams to adopt tools and practices that contribute to the Scrum Teams’ ability to deliver a valuable and useful Integrated Increment that frequently meets the Definition of Done.

Nexus Events 

Nexus adds to or extends the events defined by Scrum. 

  • The duration of Nexus events is guided by the length of the corresponding events in the Scrum Guide. They are timeboxed in addition to their corresponding Scrum events.
  • It may not be practical for all members of Nexus to participate to share information or come to an agreement. Except where noted, Nexus events are attended by whichever members of the Nexus are needed to achieve the intended outcome of the event most effectively.
  • The Sprint. A Sprint in Nexus is the same as in Scrum.
  • Cross-Team Refinement. Reduces or eliminates cross-team dependencies within a Nexus. 
    • The Product Backlog must be decomposed so that dependencies are transparent, identified across teams, and removed or minimized. 
    • Product Backlog items pass through different levels of decomposition from very large and vague requests to actionable work that a single Scrum Team could deliver inside a Sprint.
    • The frequency, duration, and attendance of Cross-Team Refinement vary.
    • Where needed, each Scrum Team will continue its own refinement in order for the Product Backlog items to be ready for selection in a Nexus Sprint Planning event. 
  • Nexus Sprint Planning. Coordinates the activities of all Scrum Teams within a Nexus for a single Sprint. Appropriate representatives from each Scrum Team and the Product Owner meet to plan the Sprint. The result of Nexus Sprint Planning is:
    • A Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be achieved by the Nexus during the Sprint
    • A Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal.
    • A Single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint Goal and makes cross-team dependencies transparent
    • A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in support of the Nexus Sprint Goal.
  • Nexus Daily Scrum. The purpose is to identify any integration issues and inspect progress toward the Nexus Sprint Goal. 
    • Appropriate representatives from the Scrum Teams attend the Nexus Daily Scrum, inspect the current state of the integrated Increment, and identify integration issues and newly discovered cross-team dependencies or impacts. 
    • Each Scrum Team’s Daily Scrum complements the Nexus Daily Scrum by creating plans for the day, focused primarily on addressing the integration issues raised during the Nexus Daily Scrum.
  • Nexus Sprint Review. It is held at the end of the Sprint to provide feedback on the done Integrated Increment that the Nexus has built over the Sprint and determine future adaptations.
    • The Nexus Sprint Review replaces individual Scrum Team Sprint Reviews. 
  • Nexus Sprint Retrospective. The purpose is to plan ways to increase quality and effectiveness across the whole Nexus. 
    • The Nexus inspects how the last Sprint went with regards to individuals, teams, interactions, processes, tools, and its Definition of Done.
    • In addition to individual team improvements, the Scrum Teams' Sprint Retrospectives complement the Nexus Sprint Retrospective by using bottom-up intelligence to focus on issues that affect the Nexus as a whole.

Nexus Artifacts

  • Product Backlog. There is a single Product Backlog that contains a list of what is needed to improve the product for the entire Nexus and all of its Scrum Teams. At scale, the Product Backlog must be understood at a level where dependencies can be detected and minimized.
    • Commitment: Product Goal - The Product Goal, describes the future state of the product and serves as a long-term goal of the Nexus.
  • Nexus Sprint Backlog. It is the composite of the Nexus Sprint Goal and Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. It is used to highlight dependencies and the flow of work during the Sprint. The Nexus Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that the Nexus can inspect their progress in the Nexus Daily Scrum.
    • Commitment: Nexus Sprint Goal. It is a single objective for Nexus. 
  • Integrated Increment. It represents the current sum of all integrated work completed by a Nexus toward the Product Goal. The Integrated Increment is inspected at the Nexus Sprint Review but may be delivered to stakeholders before the end of the Sprint. 
    • The Integrated Increment must meet the Definition of Done.
Share: