Mind Map Gallery Nexus framework guide(2021)
- Page：01
- Page：02
无数据
- 220
- 2
- 1
Nexus framework guide(2021)
Nexus framework and Nexus 40+ practices
Edited at 2021-04-14 16:50:57
- Recommended to you
- Outline
Nexus
Purpose
framework for developing and sustaining scaled product delivery initiatives
build upon Scrum, extending it only where absolutely necassy
minimise and manage dependencies between multipe Scrum teams while promoting empiricism and scrum values.
Still Scrum: not change the core ideas of Scrum, or leave out elements or negate the rules of Scrum
Definition
Group of 3-9 Scrum Teams(STs), that work together to deliver 1 product
Connection between people and things
1 Product Backlog(PB)
1 Product Owner(PO)
Define: accountabilities, events and artefacts that bind and weave together the work of the Scrum Teams in a Nexus
Minimaly extends the Scrum framework only where absolutely necessary to enable multiple teams to work from a single PB to build an Integrated Increment that meets a goal.
nexus Theory
Nexus preserve and enhance Scrum's foundational :
bottom-up intelligence
Empiricism
goal: scale the value that a group of Scrum Teams, working on a single product is able to deliver.
Help teams solve common scaling challenges like:
reducing cross-team dependencies
preserving team self-management and transparency
ensuring accountability
helps to make transparent dependencies
causes
Product structure
degree to which different concerns are independly seperated in the product will greatly affect the complexity of creating an integrated product release.
communications structure
the way that people communicate within and between teams affects their ability to get work done.
Delays in communication and feedback reduce the flow of work
provide opportunities to change:
process
product structure
communication structure
Reduce or remove dependencies
conterintuitive but: scaling the value that is delivered does not always require adding more people
Scaling-down(Descaling): reducing the number of people who work on something, can be an important practice in delivering more value.
The Nexus Framework
extends Scrum:
Accountabilities
NIT ensures that the Nexus delivers
valuable
useful Integrated Increment
at least once every sprint
Events
appended to, placed around, or replace regular Scrum events to augemnt them
Serve both all Scream Teams and individual Scrum Team
Artifacts
All Scrum teams use the same, Single PB
Refined and made ready
make transparent which team will most likely do the work inside a Sprint
Nexus Sprint Backlog:assist with transparency during the Sprint
Integrated increment: represents the current sum of all integrated work completed by a Nexus
Accountability in Nexus
3 Scrum specific sets of accountabilities
PO
SM
Developers
Nexus Integration Team(NIT)
Provide focal point of Integration(technical & non-technical cross-functional team constraints) for the Nexus
Responsible for coaching and guiding the STs to acquire, implement and learn practices and tools that improve their ability to produce a valuable ans useful Increment
Members
PO(1)
1PB
Accountable for maximizing:
Value of the product
Work performed and integrated by the STs in a Nexus
Effective PB management
SM(1)
Accountable: ensuring the Nexus framework is understood and enacted as describe in the Nexus guide
May also be a SM in >=1 ST in the Nexus
Appopriate NIT members
people with the necessary skills and knowledge to help resolve the issues the Nexus faces at any point in time
ST members
Help STs adopt tools and practices=>deliver valuable and useful Integred Increment that frequently meets the DoD
composition may change over time to reflect the current needs of a Nexus
Activities
coaching
consulting
highlighting awareness of dependencies and cross-team issues
Accountable for ensuring that a done Integrated Increment(the combined work completed by a Nexus is produced at least once a Sprint
Nexus Events
The Sprint
Same as in Scrum
STs produce 1 Integrated increment
Cross-team refinement
Reduces or eliminates cross-team dependencies
Decompose PB=>dependencies
transparent
identified across teams
removed or minimized
Purpose(2)
Helps the STs forecast which team will deliver which PBIs
Identifes dependencies across those teams
Is ongoing activitie
Frequency, duration, attendance varies to optimize those 2 purposes
If needed each team will continue their own refinement in order to for the PBIs to be ready in a nexus Sprint planning event
Nexus Sprint planning
appropriate representatives from each ST + PO to plan the Sprint
Result:
Nexus Sprint Goal: align withe the Product Goal
Describe the purpose that will be achieved by the Nexus during the Sprint
Sprint Goal for each ST: align with the Nexus Sprint Goal
1 Nexus Sprint Backlog
represents the work of the Nexus toward the Nexus Sprint Goal
Make cross-team dependencies transparent
1 Sprint Backlog for each ST
Make transparent the work they will do in support of the Nexus Sprint Goal
coordinate the activies of all STs within a Nexus for a single Sprint
Nexus Daily Scrum
Attendance:
Appropriate representatives from STs
Activities
Part 1: Representatives
Identify integration issues and newly discovered cross-team dependencies or impacts
inspect the current state of the integrated Increment
Part 2: ST's Daily Scrum
Complements the Nexus Daily Scrum
Creating plan for the day
focus primarily on addressing the integration issues raised during the Nexus Daily Scrum
Not the only time STs in the Nexus are allowed to adjust their plan
Cross-team communication can occur througout the day for more detailled discussions about adapting or re-planning the rest of the Sprint's work
Identify any integration issues and inspect progress toward the Nexus Sprint Goal
Nexus Sprint Review
Focus capturing feedback from stakeholders
Replaces individual ST reviews
Activities
the Nexus presents
the results of their work to key stakeholders
progress toward the Product Goal is discussed
may not possible to show all completed work in detail
attendees collaborate on what the Nexus should do to address the feedback
The PB may be adjusted to reflect discussions
Held at the end of the Sprint
to provide feedback on the done Integrated increment
Determine future adaptations
Nexus Sprint Retrospective
Activities
The Nexus Inspects how the last Sprint went with regards to
individuals
teams
interactions
processes
tools
DoD
each ST's retrospective
individual team improvements
Bottom-up intelligence to focus on issues that affect the Nexus as a whole
Purpose: to plan ways to increase quality and effectiveness across the whole Nexus
concludes the Sprint
Add to or extends the events defined by Scrum
Duration is guided by the length of the corresponding events in the Scrum guide
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
Adequately refined PB will minimize the emergence of new dependencies during Nexus Sprint Planning
Nexus Artefacts and commitments
Artefacts
Product Backlog
Commitment: Product Goal
Describes the future state of the product
Serves as a long-terme goal of the Nexus
Must be understood at a level where dependencies can be detected and minimized
Accountable: PO
Content
Availability
Ordering
Single: list of what is needed to improve the product for the entire Nexus and all of its STs
Nexus Sprint Backlog
Commitment: Nexus Sprint Goal
Is the sum of all the work and Sprint Goals of the STs within the Nexus
Creates coherence and focus for the Nexus for the Sprint
Encourage STs to work together rather than on separate initiatives
Created at the Nexus Sprint Planning event and added to the Nexus Sprint Backlog
STs keep the Nexus Sprint Goal in mind during the Sprint
The Nexus should demonstrate the valuable and useful functionality that is done to achieve the Nexus Sprint Goal at the Nexus Sprint Review in order to reveive stakeholder feedback
Used to highlight dependencies and the flow of work during sprint
Updated throughout the Sprint as more is learned
Should have enough detail that the Nexus can inspect their progress in the Nexus Daily Scrum
is the composite of the Nexus Sprint Goal and PBIs from the Sprint Backlogs of the individual STs
Integration Increment
Commitment: Definition of Done(DoD)
Defines the state of the integrated work when it meets the quality and measures required for the product
The Increment is done only when:
integrated
valuable
usable
Responsible
NIT
All STs within the Nexus must define and adhere to this DoD
Individual STs self-manage to achieve this state
May choose to apply a more stringent DoD within their own teams
BUT cannot apply less rigorous criteria than agreed for the Integrated Increment
Is inspected at the Nexus Sprint Review, but may be delivered to stakeholders before the end of the Sprint
Must meet the DoD
Desicions made based on the state of artifacts are only as effective as the level of artifact transparency
Incomplete or partial information will lead to incorrect or flawed decisions
The impact of those decisions can be magnified at the scale of Nexus
Represents the current sum of all integrated work completed by a Nexus toward the Product Goal
Represent work or value
Are designed to maximize transparency
NIT work with STs within a Nexus
to ensure transparency is achieved acroo all artifacts
the state of the integrated Increment is widely understood
Commitments: exist to reinforce
empiricism
Scrum value for the Nexus and its stakeholders
Help solve dependency and collaboration challenges of cross-team work
Nexus 40+ practices
Forming a Nexus - Organizing Teams
Practices
Start with a small team,then grow
Summary
To help one team to become high-performing first, then help another, then help another. Avoids the problem of scaling mediocre team performance.
Why use ?
A team scaling technique that starts with a small team. As this team grows, the team splits and members move to start new teams.
Internship Model
Summary
To share knowledge across teams and to instill a shared culture across teams when scaling the number of teams.
Why use ?
A team scaling technique that preserves the original team. Add new people to a high performance team, then new people move to start their own teams.
Feature Teams
Summary
A team formation approach that consists of a cross-functional team that is able to pull, deliver, and support an end-to-end feature.
Why use ?
To give teams deeper insight into customer needs and to reduce waste and wait-time by reducing hand-offs of work to people outside the team.
Microservices
Summary
An architectural style that organizes the architecture of applications around a set of narrowly-focused, independently deployable services.
Why use ?
To improve the modularity of the code, which improves its maintainability, making it easier to change different parts of the code independently from other parts.
UI Drives Feature Areas
Summary
A team formation technique that uses the User Interface to identify areas of high cohesion and low coupling, then form teams around these areas.
Why use ?
To reduce cross-team dependencies, based on an assumption that different parts of the UI serve different needs and can be decoupled from other parts.
Persona Teams
Summary
A team formation approach where teams form around personas, which are fictionalized abstract descriptions of types of users of the application.
Why use ?
To give teams deeper insight into the users of an application, which can help them feel more connected to the user, which can help them build better solutions.
Feature Set Teams
Summary
A team formation approach where teams form around customer-facing product areas, which are also known as value areas.
Why use ?
To scale feature teams by focusing on a consistent customer experience in a domain area.
Team Self-Selection
Summary
A team formation technique where team members choose which team they join based on their interests, their constraints, and the needs of the team.
Why use ?
To increase the sense of team identification and reduce team conflicts by empowering people to choose what they work on and who they work with.
Forming a Nexus - Organizing Work
Practices
Impact Mapping
Summary
A planning technique that uses a visual map to help communicate and connect business goals, personas, outcomes, impacts, and Product Backlog Items (PBI)
Why use ?
To understand the connection between PBIs and the product and business goals they satisfy.
User Story Mapping
Summary
A planning technique that helps teams to decompose user stories into manageable chunks of work by visualizing user stories along two independent dimensions.
Why use ?
To provide a structured way to refine PBIs to flesh out an initial usable version of a product and then additional functionality.
Track Business-centric items in the Product Backlog
Summary
A planning technique that helps teams track business centric items when decomposing the Product Backlog.
Why use ?
To ensure transparency and alignment of work that needs to be done to deliver business value (e.g. development, marketing, support, etc.)
Cross-team Refinement
Summary
A Refinement technique used by multiple teams working together on one Product Backlog to reduce or eliminate cross-team Product Backlog Item dependencies.
Why use ?
To improve the flow of work when multiple teams are working together to build a single Product.
Create PBIs as "Thin" as Possible
Summary
A planning technique to decompose and split Product Backlog Items along with their acceptance criteria.
Why use ?
To reduce the problem where PBIs are "undone" at the end of a Sprint and to minimize dependencies.
Running a Nexus
Practices
Visualize your Work
Summary
A strategy for making the status of, and progress on, Product Backlog Items visible and therefore transparent.
Why use ?
To communicate and reduce misunderstandings about the status of PBIs.
Nexus Sprint Planning Room Layout
Summary
An approach for organizing the teams in Nexus Sprint Planning, including remote teams.
Why use ?
To help improve collaboration during the Nexus Spring Planning event.
Use the Nexus Sprint Backlog to Manage the Flow of Work
Summary
A technique for using the Nexus Sprint Backlog to visualize the status of, and progress on, PBIs, during the Sprint for the Nexus.
Why use ?
To eliminate the need to use other artifacts to make the work transparent by visualizing the sequence and dependencies of the PBIs forecast for the Sprint for the Nexus.
Science Fair/Expo
Summary
A set of related techniques that can help to improve the Sprint Review at scale by letting stakeholders see what they want/need to see, on demand, during the Nexus Sprint Review.
Why use ?
To make running large Sprint Reviews more effective and engaging between the Development Teams and stakeholders.
Offline Sprint Review
Summary
A set of related techniques that enables teams to better engage with stakeholders when those stakeholders cannot attend the Sprint Review. either in-person or remotely.
Why use ?
To improve the effectiveness of Sprint Reviews when stakeholders can't be present.
Retrospective Board
Summary
A set of techniques for making Sprint Retrospective items transparent.
Why use ?
To make sure that Sprint Retrospectives items don't get ignored or forgotten.
Build Experimentation into the Product
Summary
A validation approach for evaluating alternatives using a released Product.
Why use ?
To obtain product feedback from users; to better understand whether the Product is meeting user needs.
Build Manual Feedback into the Product
Summary
Validation techniques for gathering interest and feedback from a released Product
Why use ?
To obtain product feedback from users; to better understand whether the Product is meeting user needs.
Build Automated Feedback into the Product
Summary
A validation approach for using instrumentation in the application to gather information about usage.
Why use ?
To obtain product feedback from users; to better understand whether the Product is meeting user needs.
Scaled Product Ownership
Summary
An approach to scaling Product Ownership by delegating some of the work of Product Ownership while still maintaining Product Owner accountability.
Why use ?
To scale Product Ownership when there's too much work for them to do, and they need help.
Continuous Integration
Summary
A development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build and test process, allowing teams to detect problems early.
Why use ?
To discover coding and code integration problems as early as possible, while the code is still fresh in the developer's mind.
Automated Acceptance Testing
Summary
An approach for using test automation to verify that requirements are met.To reduce the level of manual effort that is required to verify that requirements are being met.
Why use ?
To reduce the level of manual effort that is required to verify that requirements are being met.
Feature Toggles
Summary
A technique that enables all work to be integrated regardless of feature readiness
Why use ?
To enable code to be integrated without introducing partially completed work by keeping the code "turned off" until everything is ready for the feature to be used.
Develop for Operations
Summary
Techniques that improve the deployability and supportability of applications
Why use ?
To improve the release readiness of a product by making sure that all the work necessary to deploy and support a PBI is completed in the same Sprint.
Track Operations / Infrastructure Work in the Product Backlog
Summary
Techniques that improve the deployability and supportability of applications
Why use ?
To improve the release readiness of a product by making sure that all the work necessary to deploy code related to a PBI is completed in the same Sprint.
Teams on Differing Cadences
Summary
Techniques for synchronizing the work of multiple teams in a Nexus when their Sprint lengths differ.
Why use ?
To handle the situation in which not all teams in the Nexus cannot get PBIs to "done" at the same rate. Especially relevant in mixed hardware/software products, and products that require some work to be done on legacy code.
Communities of Practice
Summary
A technique for forming and supporting groups of people with common interests, for the purpose of sharing learnings and improving skills.
Why use ?
To share information across teams; to improve professionalism across teams.
Track Architecture Work in the Product Backlog
Summary
A technique that improves the resiliency and reduce the total lifecycle cost of applications.
Why use ?
To improve the resiliency and reduce the total lifecycle cost of applications.
Facilitate Shared Architecture
Summary
A technique for refactoring and sharing components across applications and teams.
Why use ?
To improve the resiliency and reduce the total lifecycle cost of applications.
Internal Open Source (aka "Inner Source")
Summary
A technique to enable multiple teams to make changes to the same code at the same time.
Why use ?
To move away from teams owning components to shared component ownership.
Managing a Nexus
Practices
Product Backlog Treemap
Summary
A technique for visualizing the size and completeness of PBIs.
Why use ?
To provide a way of visualizing the size/complexity of PBIs. Also used to make the status of the work transparent.
Feature Burndown
Summary
A technique for visualizing the completeness of work at the feature level.
Why use ?
To provide a way to visualize Done and Undone work for a Sprint or for a release.
Health Check
Summary
A technique for helping teams assess their own performance.
Why use ?
To provide a lightweight way for teams to self-diagnose challenges so that they can focus on improving the things that will help them most.
World Café
Summary
A facilitation technique for knowledge sharing in large groups by breaking them into smaller sub-groups, based on sub-topics, and rotating people through the groups.
Why use ?
To provide a way to share and discuss ideas in a large group environment.
Open Spaces
Summary
A facilitation technique for breaking into smaller groups to discuss and focus on topics of interest through self-organization.
Why use ?
To provide a a way to break into sub-groups to focus on ideas or problems when the entire group may not be interested in every topic.
De-scaling
Summary
A technique for restoring order to a Nexus that is struggling with scaling problems by reducing the number of teams.
Why use ?
To provide ways to simplify problems arising from having scaled poorly or unnecessarily, especially situations in which the sheer numbers of people involved have become destabilizing.
Scrumble
Summary
A technique equivalent of "pulling the andon cord"; stopping work and descaling until stability can be restored to the Nexus.
Why use ?
To deal with a situation in which the Nexus has become incapable of doing useful work, and all work needs to stop until order and coherency can be restored (if possible).
Distributed Teams Travel
Summary
An approach for improving cohesiveness and building stronger working relationships with distributed teams.
Why use ?
To improve and increase cross-team collaboration by building personal relationships and creating a shared culture across distributed teams.
Distributed Tooling
Summary
A technique for using technology to improve the ability for distributed teams to work together.
Why use ?
To make distributed collaboration more effective through the appropriate use of distributed collaboration technology.