Loading...

Agile Scaling Frameworks

Overview

Typically, organizations start their agile journey by implementing agile in various pockets of the enterprise. However, over a period of time, after experiencing the benefits of agile, organizations want to multifold this benefit, by scaling either from few teams to larger teams or even further to part or whole of the enterprise. Challenges of teams being distributed, structured as component teams involving a lot of inter and intra dependencies add to the complexity of scaling, often leading to organizations concluding that agile is only effective at team level for co-located teams. This pressing need to scale right and the various perspectives of scaling is described in detail in the article, 'Start small, scale up'.

Since the inception of agile methodologies, there has been a varied evolution of scaled frameworks to enable scaling at enterprise level. Some frameworks like LeSS and Nexus, keep it very simple and recommend scaling scrum for multiple teams while other frameworks like Disciplined Agile Delivery (DAD) or Scaled Agile Framework (SAFe) are more prescriptive. While these scaling frameworks aim at recommending structure around scrum teams which is the heart of each of them, they revolve around the core agile principles.

Agile scaling frameworks Figure 1 : Scrum - Heart of Scaled Frameworks

Factors for Scaling

Scaling frameworks need to consider organizational structure as well as existing and perceived organizational processes required beyond scrum teams, in order to scale with ease and completeness

Some of the factors considered are as follows:

  • Organizational Size
  • Structure and Governance
  • Culture and Discipline
  • Boundary of Agility
  • Technical Landscape
  • Level of distribution within the organization
  • How business value is perceived

Taking these factors into consideration, each framework aims at:

  • Ensuring the big picture is understood and cascaded across teams
  • Aligning various teams to common objective
  • Focusing on intrinsic value creation
  • Enabling teams to operate synchronously and converge as one product
  • Seamless integration and testing as one product
  • Collaboration across multiple teams, including non-development teams
  • Technical enablement with minimal variations
  • Enabling knowledge development and sharing through common technical forums
  • Retaining anonymity of teams and at the same time providing a rolled-up view of the value attained at different levels

Agile at Scale - Different Frameworks

In this section, we will focus on few of the popular scaling frameworks:

  • Scrum of Scrums -

    Scripted by two of the founders of scrum. Here, the methodology followed is scrum multiplied, with events of collaboration between scrum teams. This is a very simple framework and is generally well suited for organizations where there are multiple scrum teams who need to work synchronously and deliver a single product. The Scrum of Scrums meeting helps teams to coordinate the work and dependencies across teams. But as the size grows it may become overwhelming without proper guidance and structure.

  • Large Enterprise Scaled Scrum (LeSS) -

    Founded in 2005 by Craig Larman and Bas Vodde, LeSS aims to scale Scrum upward. LeSS can be used for up to eight teams with eight people each, while, LeSS Huge, which is a larger variation, can be used for projects ranging in size from eight people all the way up to a few thousand. The LeSS framework advocates one product backlog, one Product Owner for the teams, a sprint planning at the overall level before the planning event at the team level and one definition of 'Done', finally with an output of a potentially shippable increment at the end of each sprint followed by reviews and retrospectives at team as well as the product level. LeSS also tries to list many experiments which serve as a guide for organizations in their scaling journey.

  • Scaled Agile Framework (SAFe®) -

    SAFe was first detailed as a 'big picture' on Dean Leffingwell's blog, in collaboration with the agile community. However, the first official release of SAFe was published in 2011. The latest release, SAFe 4.5, was released in June 2017. Unlike other frameworks which require to tailor up on the base framework, SAFe attempts to address various organizations' structures and prescribe various aspects and needs from an enterprise level. It also maps how the enterprise can operate in SAFe right from demand/ ideation up to development and delivery. Organizations can tailordown the process where required. Word of caution though here, teams should not take the framework as a series of how-to-dos, but must apply it contextually as per relevance.

  • Nexus -

    Nexus is relatively new and was founded in 2015 by Ken Schwaber, who is also the co-creator of Scrum. Nexus is designed for 3 to 9 Scrum development teams and a common product backlog. Any further than 9 teams form another Nexus. Nexus builds on Scrum and introduces additional roles and events. At the core of Nexus is the Nexus integration team which is also another scrum team consisting of a Product Owner, Scrum Master, and other members whose purpose is to collaborate and guide the work of all the multiple Scrum teams to ensure that at the end of the Sprint, the teams collectively deliver a potentially shippable increment.

Summing up

Thus from the above, we see that each of these frameworks has its strengths and weaknesses. The success of scaling agile is not directly proportional to the frameworks used. Instead it requires deeper understanding of the organizational structure, imbibed culture, futuristic objective and applying part or whole of the framework to suit the organization's needs and expectations. Organizations can start with what suits their structure and solve the immediate expectation at hand, and build over that framework to experience the true benefits of agility.

SAFe® Framework

Scaled Agile Framework (SAFe®) is an agile software development framework which helps implement agile at Enterprise level by using principles of lean development. SAFe is both scalable and modular, providing flexibility to the organization to apply it in a way that suits its need. It is an agile scaling framework, which ensures that all the teams in the organization (involving thousands of people) are synchronized, collaborate effectively, and deliver complex systems. SAFe addresses scaling from a single team to multiple teams and also scaling at an enterprise portfolio level involving multiple teams and programs.

The nine SAFe principles are derived from fundamental lean and agile principles, which in turn drive the roles and practices, making SAFe effective. These nine SAFe principles are:

  • Take an economic view
  • Apply systems thinking
  • Assume variability; preserve options
  • Build incrementally with fast, integrated learning cycles
  • Base milestones on objective evaluation of working systems
  • Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths
  • Apply cadence (timing), synchronize with cross-domain planning
  • Unlock the intrinsic motivation of knowledge workers
  • Decentralize decision-making

SAFe® Configurations

SAFe caters to various organizations/ enterprises based on their size, structure, and business needs. There are four out-of-the-box configurations advocated by SAFe framework:

  • Essential SAFe®
  • Large Solution SAFe®
  • Portfolio SAFe®
  • Full SAFe®

Essential SAFe®

This configuration is the heart of SAFe and is the starting point for SAFe implementation. This is the foundation and a core part of the other configurations. In Essential SAFe, the multiple agile teams of the program along with the key stakeholders and other resources form part of the Agile Release Train (ART). The teams in an ART work in the same cadence with a single synchronized time box to deliver the solution. The teams are cross functional and apply the Scrum, Kanban, and quality practices to deliver the working product increment.

Essential SAFe requires that all teams in the train operate in a single cadence with a conscious focus towards continuously delivering an integrated, tested working software at the end of every Product increment.

Typically Essential SAFe is suitable for smaller organizations which have only one product involving multiple teams to work collaboratively and deliver a single solution.

Large Solution SAFe®

Some industries though large, involve one large complex solution instead of many independent solutions. This may require that all the teams are part of the same larger team (or train). However, this would dilute the effectiveness of collaboration, as there are more than 12-15 teams in the same train. SAFe recommends another configuration called Large Solution SAFe, which forms a Solution Train constituted of multiple ARTs and suppliers, either internal or external who also contribute part or whole components required by the Solution Train. Thus the Large Solution SAFe configuration helps in building large scale multi-disciplinary complex IT systems and clearly defines the additional roles, events and artifacts necessary to coordinate the Solution Train. The multiple ARTs contribute towards the Solution Train in the same cadence with synchronized Program Increment (PI) time box and same iteration start and end dates. This reduces the inherent risk and variability among the trains in a large solution development environment.

Portfolio SAFe®

Portfolio SAFe configuration is apt for organizations which have multiple independent solutions and are driven by organizational funding spread across different initiatives. To enable this, Portfolio SAFe adds a Portfolio layer over the program and team layers, which defines the initiatives based on the strategic themes of the organization through value streams. The execution of the initiatives (Epics) under the portfolio is aligned to the organizational strategy. Budgets are allocated based on the value perceived by the initiatives. Thus, it aims at ensuring that the investment in the solution will provide the returns and value the organization needs to meet its strategic objectives.

Full SAFe®

Full SAFe encompasses all levels of SAFe (Team, Program, Portfolio and Large) and supports large enterprises involving hundreds of people or more. Thus, Full SAFe caters to large enterprises involving multiple programs and large solutions, derived from strategic themes and managed on allotted budgets. It defines clear roles at various levels, and events, and provides means of collaboration both vertically across levels and within each level across teams.

Levels in SAFe

This section aims to define in detail each of the levels, which in combination form and cater to different configurations of SAFe. Here, we try to detail the levels, the roles, events, and process flows for each level. Also, each level concludes with a description of how these roles and events are addressed in Jile, which would enable teams to implement SAFe 4.5 in their respective organizations.

Team Level

At the team level, SAFe structures out scrum teams who are developing in cadence and deliver incremental value through a time box, referred as Program Increment (PI), which in turn is typically made out of four iterations and one Innovation and Planning (IP) iteration. These teams would be part of the Agile Release Train (ART) at the program level. SAFe advocates teams to follow the ScrumXP methodology which incorporates the scrum project management methodology powered with the technical practices recommended by Extreme Programming (XP). The Scrum team is a self-organizing, cross functional team of 5 to 9 members, and comprises of scrum roles such as Product Owner, Scrum Master and Development team. Teams such as system teams or maintenance/operations team, who are not working in cadence, yet supporting the agile development teams generally apply Kanban as their primary methodology. Each agile team defines and refines the stories in the team backlog. Teams pick up these prioritized stories, build, test, and deliver them using common iteration cadence, which are based on a series of fixed-length iterations, thus creating a rhythm and ensuring that the entire system is iterating together. Different agile teams on the ART synchronize and create one integrated tested system which is evaluated during system demo and feedback from the stakeholders is obtained. SAFe also recommends built-in Quality. Every iteration creates a potentially shippable increment.

In team level, teams synchronize during various events such as:

  • Iteration Planning -

    During Iteration Planning, the teams pick up the stories and enablers that they would be addressing in the iteration based on priority and commit to the same.

  • Iteration Review -

    Done at the end of the iteration, the team demonstrates the increment at the end of the iteration to all stakeholders and obtains early feedback. Any changes recommended are taken up into the backlog for fixing in the upcoming iterations based on the impact and priority.

  • Execution -

    During the iteration execution where the team is developing the increment based on the stories committed, the team regularly syncs up during the daily stand-up meeting to review progress of the iteration, discuss or make known the impediments and work together towards the common objective of ensuring their iteration commitments as a team are met.

  • Retrospective -

    At the end of the iteration, the team reflects on the previous iteration to check the iteration activities, challenges as well as the outcome of the iteration review. The team identifies aspects of improvement which would enable the team to work better, facilitate quick identification of impediments, ensure faster resolution, thus leading to an effective team with improved processes, which in turn would improve the team's velocity and improve the quality of the product increment.

  • Innovation and Planning (IP) Iteration -

    Typically the last iteration of the program increment, the intent of the iteration is to dedicate time towards continuous improvement, exploration, and innovation. Also, teams can utilize the same for future Program Increment planning. System level verification and validation along with documentation of the increment is also taken up during this last iteration of the Program Increment.

Program Level

At the Program level, different agile teams work collaboratively towards delivering value as part of a long-lived Agile Release Train (ART). Generally, 5-10 agile teams form an Agile Release Train, with typically 50 to 125 persons each. The ART includes the agile teams and other stakeholders all of who continuously synchronize and deliver a fully tested integrated, working system-level product in their iteration boundaries. Managing the ART involves the following focused roles and teams at the Program level in addition to the agile teams that together form a part of the ART:

  • Release Train Engineer (RTE) -

    The Release Train Engineer is equivalent to a chief Scrum Master at the program level. The RTE facilitates the process of the ART and assists the teams in delivering the committed value by communicating with stakeholders, clearing impediments, escalating risks, and helping in driving improvement. The RTE needs to ensure that all teams in the train are on track and collaborating efficiently, where required. It also ensures that no team slows the train (ART).

  • Product Management Team -

    The Product Management Team are the content authority of the program backlog and manage the same. They are responsible for identifying business needs, clearly defining the roadmap when the needs would be met, elaborating the business needs into features, and prioritizing them. The group represents business and acts as a direct bridge to the teams in the ART, continuously defining, prioritizing, and validating the business requirements. They work closely with the RTE and System Architecture/Engineering team to ensure seamless flow of value through the product increments without cluttering on the technical debt, which would later prove to be expensive to handle.

  • System Architecture/Engineering Team -

    This team could constitute an individual or a group of architects who take a system level view and define and manage the technical and architectural runway needed to support the ART. The System Architecture/Engineering team works in close collaboration with the business teams and other stakeholders in detailing and evolving the system, technical, and architectural view of the program. They define the systems, sub-systems and interfaces, non-functional requirements, validate any technology assumptions and evaluate the alternatives while taking the solution context into consideration. The team plays a crucial role as they ensure technical enablement for the teams, which is vital to keep the train running without running into hurdles, jerking due to technical shortcomings or worse, coming to a complete halt. They also manage the delivery pipeline by enabling continuous integration of the increment, and seamless deployment into production.

Teams in the ART deliver incremental value in cadence through Program Increments (PI) each of which is typically comprised of four development iterations and one Innovation and Planning (IP) iteration. The PI is kick started with a PI Planning session in which all stakeholders including the agile teams participate. The objective of the PI is cascaded to all members by the business owner. The teams commit for the features that would be delivered during the PI and later break out for detailed planning, discussing dependencies, and estimating the committed features and stories. In the course of the PI, where the teams are delivering iterations, the RTE, along with the scrum masters of the agile teams meet on a regular basis to sync up on the progress of the program increment and ensure that the train is on track and any impediments and dependencies are cleared forthwith. At the end of the PI, a system demo of the functionality developed during the PI is showcased to the stakeholders. This is followed by an Inspect and Adapt session that includes root cause analysis and identification of systematic improvements.

Large Solution Layer

As the systems become large and complex, it is crucial that teams collaborate effectively to deliver value, keeping the holistic system in view. When a business value stream produces more solutions that includes multiple products, services or systems, a single ART (team of teams) might not be sufficient to handle the large solution. Having hundreds or even thousands of people (typically 10-100 teams) in a single ART would only add to the complexity and dilute the effectiveness of collaboration amongst teams. Large Solution layer thus aims to address large complex solution that typically involves multiple ARTs, each consisting of 10-12 teams. The multiple ARTs together form the Solution Train that shares a common business goal, a common product backlog and an aligned Product Increment. This Solution Train addresses the need for planning, solutioning, tracking, and delivering this large solution effectively by introducing additional roles, events and artifacts wherever necessary to coordinate the trains. The multiple ARTs contributing to the Solution Train run/operate in the same cadence with synchronized PI time box and same iteration start and end dates. This reduces the inherent risk and variability among the trains in a large solution development environment.

To enable multiple ARTs to work collaboratively in synchronization demands more roles and events at the Solution Train Level. The additional roles that enable multiple ARTs to coordinate and collaborate better include the Solution Team Architect/Engineer, Solution Management team and the Solution Train Engineer. Solution Team Architect/Engineer could be an individual or a small team, who would be responsible for the common architecture definition that aids in the solution development, keeping the solution intent in mind. Solution Management team works with the customers in understanding their needs, and guides the teams in deriving requirements based on the Solution Context, which will help derive the capabilities of the solution that is expected. Solution Train Engineer (STE) facilitates the Solution Train similar to the Release Train Engineer (RTE) at the Program level, whose main role would be to manage the train and optimize the solution by participating in the ceremonies and helping the teams achieve them by managing the risks and dependencies across the ARTs in the Solution Train.

In addition to the typical Program level scrum ceremonies, the Solution teams also enter into a Pre and Post PI planning event where the multiple ARTs along with any third party suppliers (internal/external) will prepare for the upcoming Product increment (PI) and follow up on the learnings and improvement of the previous Product Increment. Typically these events are conducted during the Innovation and Planning (IP) iteration of the Product Increment. These events thus essentially help multiple teams among the ARTs to coordinate and allows them to align with the overall solution goals by providing a direction of the delivery towards achieving the collective objective.

Finally the ARTs and suppliers involved in the Solution Train create an integrated and tested solution and gives a solution demo which includes all the necessary and relevant stakeholders to evaluate if the collective PI Objective is met.

Portfolio Layer

The Portfolio Layer provides guidance, principles, and processes for an enterprise to meet the organization's strategic objectives and goals. High level initiatives are defined at the portfolio level and aligns the entire organization towards the common goals. Every solution that provides business value is considered as a value stream and every value stream is allocated with teams and resources to build solutions that deliver the value to the business or customer. These value streams are typically long-lived and include a series of steps from concept to delivery, providing a continuous flow of value.

As the layer involves coordinating between multiple value streams across the organization, there are roles that specifically cater to the portfolio level activities apart from the independent solution level or program level roles. Lean Portfolio Management is a team of highly accountable individuals who are entitled to take financial decisions for a value stream or a program. Epic Owners are responsible for identifying the Epics. They elaborate and analyze the cost and impact of the same and present the lean business case to the management for budget approval and implementation go-ahead. Once it is approved by the business, Epic Owners are responsible for driving the implementation of the Epic, by working in close coordination with the Solution Train and ART teams till it is incorporated as part of the solution and business value realized. Enterprise Architect is responsible for deriving the strategic architecture of the organization and driving a holistic technology implementation across solutions. The Enterprise Architect also fosters reusing the ideas, components, and services from various solutions with the help of the Solution Architects and System Level Architects to provide the architectural governance. They also manage the architectural runway to support the current and near business needs. They continuously collaborate with the system teams, the solution teams and also with the business to support quality architecture.

The presence of the architectural runway ensures that the architectural and technical capabilities are also considered during the development of the minimum viable product. The Epic Owners define the Business Epics that provide the business value and Enabler Epics that actually takes care of the technical needs. Strategic Themes are business objectives and provide the key differentiators based on which the strategy is derived. Strategic Themes are generally derived after much collaborative planning where the enterprise executives along with the Enterprise architect, Lean portfolio management team and other portfolio stakeholders deliberate on the envisioned futuristic state of the product and identify its key differentiators.

Large Enterprise Scaled Scrum (LeSS)

LeSS is a scaled up version of scrum, which helps product teams implement Scrum in a large-scale context. LeSS is applied to multiple teams working together on a single product. LeSS provides experiments, guides, frameworks, principles, and elements to aid teams in implementing LeSS through case studies or lessons learnt from earlier implementations or different contexts. It supports both multi-team as well as multi-site agile development.

LeSS in line with the Scrum practices advocates using single product backlog maintained by a Single Product Owner, common Definition of Done (DOD), and synchronized iterations leading to single product increment. The Product Owner provides the prioritized backlog and distributes the same to the cross-functional scrum teams.

LeSS aids in removing organizational complexities by solving the problems of product development in a simple empirical way by shifting the whole thinking from how to perform a process to why the process must be performed, thus focusing on the intent rather than mere practice. It helps in realizing the value of the work done, thereby eliminating most of the unwanted processes and methods that were followed in a traditional approach. The framework also consciously avoids introduction of additional roles, artefacts, and documentation to avoid complexity, as with quantum of processes, teams tend to lose the human touch in the development, much against the basic principle of agile. When the process is light, teams would be able to focus on interaction and collaboration with all stakeholders leading to effective, value-based delivery.

LeSS - Frameworks

There are two types of agile scaling advocated by LeSS:

  • LeSS Small:

    Supports up to 8 teams (of eight members each). It is best suited for co-located teams that are of size 8 to 10 per team with a total of 8 or less teams.

  • LeSS Huge:

    Supports up to thousands of people contributing to a single product. It supports both co-located and multi-located or multi-site teams, however recommends each scrum team to be co-located.

LeSS Small Framework

LeSS Small Framework is used when the complexity of the product is minimal and involves two to eight scrum teams. The LeSS team in addition to the scrum teams contains one Product Owner for all the scrum teams and a Scrum Master for upto three teams. The teams are cross-functional, working in a shared code environment towards creating done items. The Product Owner maintains a single product backlog and cascades the prioritized items to the scrum teams, who work synchronously in the same sprint cadence and deliver one integrated shippable product increment.

LeSS Huge Framework

LeSS Huge is adopted when there are more than 8 scrum teams. Essentially it is multiple LeSS frameworks stacked together. Since the overall output is a single product, LeSS Huge also advocates single product backlog, same sprint durations and all teams working towards a single delivery.

The single product backlog is split into multiple Requirement Areas with the respective Area Product Owners. The requirement areas are categories that are customer centric. The Area Product Owners in turn are subject matter experts in their respective requirement areas. The Area Product Owners form the Product Owner team and will be collectively responsible for prioritization, though the scope and schedule will still be decided only by the Product Owner. The Product Owner groups the features to the specific requirement areas as Area Backlogs, which in turn will be taken up by the Area Product Owners for implementing.

Events in LeSS

Sprint Planning:

In a LeSS framework, Sprint Planning happens at two levels. Sprint Planning One focuses on what items need to be done in the sprint, while Sprint Planning Two happens at the scrum team level and focusses on how those selected items will be delivered.

  • 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 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 they pick the items from the product backlog that they will work on for the next sprint.

  • 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 between 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.

Product Backlog Refinement:

Typically not later than the middle of the Sprint, the teams need to start planning the items for the next sprint. This would involve:

  • Splitting items

    into smaller chunks that can be fitted into a single sprint

  • Elaborating the items

    with finer requirement and acceptance criteria details until the team feels the item is 'fully' ready to be picked for the upcoming sprint

  • Estimating the effort

    required towards making the ready item finally 'Done'

Backlog refinement is done at three levels:

  • Overall Product Backlog Refinement -

    Here, representatives from all the teams along with the Product Owner decide on the items for the next sprint. This event aims at arriving at a common understanding of the sprint items and enables teams to have a holistic picture to identify the dependencies amongst the team members. The teams then deep dive into the items and clarify the requirements with the Product Owner and subject matter experts.

  • Team Level Product Backlog Refinement -

    After an overall understanding of the sprint requirements, the teams may then deliberate on their specific backlog and attain more clarity on the picked items of the next sprint. All members of the team participate in this event, not only representatives. This also ensures that the understanding obtained during the overall product backlog refinement exercise is cascaded to all the members. 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 interdependencies with other teams, LeSS recommends a Multi-team Product backlog refinement session. During this meeting the multiple teams involved do the refining in the same room (typically a big hall). The teams 'Just Talk' and get their dependencies sorted and agree on how to address those items with minimal or no interruption to each of their items.

Sprint Review:

In LeSS, Sprint Review is conducted as a grand event like a 'Bazar' or Fair, where each team is allotted a station to demonstrate their accomplishments of that sprint. Attending stakeholders can visit the stations in which they are interested. There would be multiple converge cycles where the stakeholders summarize their opinions from the fair.

Sprint Retrospective:

The Sprint Retrospective, like the Sprint Planning, is also held in two stages. At the end of the sprint, the teams have their regular Sprint Retrospective, where the teams reflect on the learnings from the sprint gone by, and inspect and what needs to be done differently to deliver faster, better. The second retrospective happens after the individual team retrospective. Generally this is conducted at the beginning of the next sprint, where all the teams look back into the previous sprint and deep dive into how the teams are working together, any sharing between teams and scenarios faced that need to be handled differently to perform better and in perfect harmony.

Nexus Framework for Scaling Scrum

Ken Schwaber, the co-creator of Scrum and founder of Scrum.org, created the Nexus framework and corresponding Nexus Guide to help organizations enable scaling Scrum for teams beyond 3 to 9 members. The word Nexus means a connection or series of connections which links two or more things or a focal point. Nexus framework thus integrates 3 to 9 scrum teams which are linked together through a Nexus Integration Team and can be easily used for large scale software development. It provides a structure where multiple scrum teams can work together on a single product backlog to deliver a single integrated increment every sprint. It guides teams in sharing work between teams, managing and minimizing dependencies and improving collaboration within and outside the team. Since Nexus builds on top of scrum, it is easier for teams who are familiar with scrum to benefit faster with Nexus. In addition to using Nexus, it is also important that teams and organizations factor in technical excellence as a foundation for growth, and establish and promote this within the organization.

The Initial Step: Forming the 'Nexus'

Nexus is denoted as the 'exoskeleton' of scrum in Scrum.org, which defines the structure over and above a scrum team. While the multiple scrum teams in a Nexus, work on a synchronized cadence, Nexus defines roles, events, and artifacts to enable the scrum teams coordinate better, integrate seamlessly, and finally realize the summed up business value in harmony, and with no or minimal conflicts that generally arise in a scaled setup.

  • Identify the teams who would be part of their Nexus
  • Form an initial Nexus Integration Team
  • Have a single Product Backlog
  • Define 'Done'
  • Identify a Sprint cadence

Nexus Roles, Events, and Artefacts

Picture the scrum team as a central spine. The Nexus external skeleton along with the integration team, and the Nexus events, roles and artifacts form the rib bones of this central spine. Listed below are the roles, artifacts and events prescribed by Nexus in order to ensure that the structure of the organization is erect and strongly bound.

  • Roles -

    While Scrum teams are constituted of development teams, scrum teams and a Product Owner, a Nexus in addition has a Nexus Integration Team which consists of Product Owner, Scrum Master and one or more team members from each team. A Nexus Integration Team coordinates, coaches, and supervises the application of Nexus and Scrum in the Nexus. The intent behind this team is to ensure that there is coordination between teams and there is no conflict. The need for the integration team is crucial as the number of teams working on a single product backlog increase.

  • Artefacts -

    The Nexus Product Owner manages the single product backlog and this sources the Nexus Sprint Backlog , which in turn populates the respective scrum teams' sprint backlog. It brings to the teams a common understanding as well as clarity and depth of what they are working on. The backlog is refined to minimize or eliminate dependencies as much as possible and ensure transparency of the same to the entire Nexus team. Also the teams share a common Nexus Sprint Goal , work towards ensuring a common Definition of 'Done', finally collectively delivering the Integrated Increment.

  • Events -

    The additional events which are introduced by Nexus are Nexus Sprint Planning, Nexus Sprint Review, Nexus Sprint Retrospective, Refinement, Nexus Daily Scrum meeting which is the 'Scrum of Scrums' meeting. The purpose of these additional events are to ensure that the teams look at the business need holistically, plan towards the same by slicing and distributing the work, and smoothly coordinating to produce an integrated increment. It also helps in sharing experiences of different scrum teams. The Nexus Sprint Review is introduced, instead of the individual Sprint review. Since the Nexus teams work together to produce an integrated deliverable, the review of the entire Nexus team happens as a whole.

Nexus Process Flow

Nexus process flow Figure 2: Nexus Process Flow

Refine the Product Backlog

The aim of refinement is to prioritize the product backlog and to decompose the requirements into smaller chunks, such that the dependencies are minimal. After this refinement, the teams would be able to clearly visualize the dependencies of the requirements and work in close collaboration with each other to ensure that the dependencies do not turn into hurdles. Backlog refinement is a cross-team event. Typically the refinement does not have a fixed frequency or duration as it would depend mainly on the volume of dependencies.

Nexus Sprint Planning

The refined product backlog is the input for the Nexus Sprint Planning activity. Nexus Sprint Planning happens at the beginning of the sprint and helps Scrum teams to coordinate activities for that Sprint. Here the teams finalize the objectives also known as Nexus Goal, which they would be working towards in that sprint. By the end of the Nexus Sprint Planning, the teams finalize their commitments for the sprint, have a clear understanding of the dependencies and have their Sprint backlog ready. The team then disperses and have their team level sprint planning, where they plan in detail based on their Sprint backlog.

Nexus Daily Scrum

While the scrum teams have their daily stand-up meeting, it is essential that the different scrum teams in the Nexus also meet up to inspect the current state of the progressive integrated increment, and identify and address any integration issues or other cross-team dependencies. This event is referred to as the Nexus Daily Scrum, where representatives from each scrum team meet up along with the Nexus Scrum Master and Product Owner (as needed). The teams reflect and share the status of work increment from the previous meet, and look into new dependencies that would need to be addressed. Any information that needs to be cascaded across the teams in the Nexus is also shared during this meeting. The actions, decisions, learnings and conclusions from the Nexus Daily Scrum is then carried forward in the individual team Daily Scrum meetings by their respective representatives.

Nexus Sprint Review

Nexus Sprit Reviews are held during the end of the Nexus sprint, where the teams inspect if their Nexus Sprint Goal is achieved through this integrated increment as perceived and committed. As the focus of the Nexus is on the integrated increment, the Nexus Sprint Review replaces the individual Scrum Team Sprint Reviews. The advantage of holding an integrated sprint review is that all the stakeholders get to see one increment and provide feedback.

Nexus Sprint Retrospective

Nexus Sprint Retrospective is conducted in three parts. During the first part of the meeting, representatives from the scrum team meet and collectively reflect on issues that impeded more than one scrum team during the bygone sprint. This way, issues are made transparent to the entire Nexus team. They reflect on how to avoid such impediments by taking necessary steps or plan to equip themselves to face similar scenarios efficiently. Teams look for any dysfunctions in the Nexus if the work committed was achieved, if integration across teams happened frequently or if there were too many dependencies accumulated, which proved to be a bottleneck and slowed the teams. They then reflect on how these dysfunctions could be prevented from recurrence or how the impact could be reduced. After this collective meeting, each individual Scrum Team holds their Individual Sprint Retrospectives, where they discuss the issues brought up during the Nexus Sprint Retrospective and form actions to address these issues. Finally the team representatives (who met in the first meeting), re-connect, discuss and agree on their actions for shared issues, then visualize and track the agreedon actions.

References:

http://www.scaledagileframework.com/#for SAFe https://less.works/less/framework/index.html for LeSS https://www.scrum.org/resources/online-nexus-guide for Nexus

index