Nexus framework что это
Product delivery is complex, and the integration of product development work into a valuable product requires coordinating many diverse activities. Nexus is a framework for developing and sustaining scaled product delivery initiatives. It builds upon Scrum, extending it only where absolutely necessary to minimize and manage dependencies between multiple Scrum Teams while promoting empiricism and the Scrum Values.
This Guide contains the definition of Nexus. Each element of the framework serves a specific purpose that is essential to help teams and organizations scale the benefits of Scrum with multiple teams working together.
As organizations use Nexus, they typically discover complementary patterns, processes, and practices that help them in their application of the Nexus framework. As with Scrum, such tactics vary widely and are described elsewhere.
- Purpose of the Nexus Guide . 2
- Nexus Definition . 4
- Nexus Theory . 4
- The Nexus Framework . 4
- Accountabilities in Nexus . 5
- Nexus Integration Team .. 5
- Nexus Events . 6
- The Sprint 7
- Cross-Team Refinement 7
- Nexus Sprint Planning . 7
- Nexus Daily Scrum .. 8
- Nexus Sprint Review .. 8
- Nexus Sprint Retrospective . 8
- Nexus Artifacts and Commitments . 8
- Product Backlog . 9
- Commitment: Product Goal 9
- Nexus Sprint Backlog . 9
- Commitment: Nexus Sprint Goal 9
- Integrated Increment 9
- Commitment: Definition of Done . 9
- End Note . 10
- Acknowledgements . 10
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. Nexus builds upon Scrum’s foundation, and its parts will be familiar to those who have used Scrum. 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.
At its heart, Nexus seeks to preserve and enhance Scrum’s foundational bottom-up intelligence and empiricism while enabling a group of Scrum Teams to deliver more value than can be achieved by a single team. The goal of Nexus is to scale the value that a group of Scrum Teams, working on a single product, is able to deliver. It does this by reducing the complexity that those teams encounter as they collaborate to deliver an integrated, valuable, useful product Increment at least once every Sprint.
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. These dependencies are often caused by mismatches related to:
Nexus provides opportunities to change the process, product structure, and communication structure to reduce or remove these dependencies.
While often counterintuitive, scaling the value that is delivered does not always require adding more people. Increasing the number of people and the size of a product increases complexity and dependencies, the need for collaboration, and the number of communication pathways involved in making decisions. Scaling-down, reducing the number of people who work on something, can be an important practice in delivering more value.
Nexus builds upon Scrum by enhancing the foundational elements of Scrum in ways that help solve the dependency and collaboration challenges of cross-team work. Nexus (see Figure 1) reveals an empirical process that closely mirrors Scrum.
Nexus extends Scrum in the following ways:
- Accountabilities : The Nexus Integration Team ensures that the Nexus delivers a valuable, useful Integrated Increment at least once every Sprint. The Nexus Integration Team consists of the Product Owner, a Scrum Master, and Nexus Integration Team Members.
- Events : Events are appended to, placed around, or replace regular Scrum events to augment them. As modified, they serve both the overall effort of all Scrum Teams in the Nexus, and each individual team. A Nexus Sprint Goal is the objective for the Sprint.
- Artifacts : All Scrum Teams use the same, single Product Backlog. As the Product Backlog items are refined and made ready, indicators of which team will most likely do the work inside a Sprint are made transparent. A Nexus Sprint Backlog exists to assist with transparency during the Sprint. The Integrated Increment represents the current sum of all integrated work completed by a Nexus.
Figure 1: The Nexus Framework
A Nexus consists of Scrum Teams that work together toward a Product Goal. The Scrum framework defines three specific sets of accountabilities within a Scrum Team: the Developers, the Product Owner, and the Scrum Master. These accountabilities are prescribed in the Scrum Guide. In Nexus, an additional accountability is introduced, the Nexus Integration Team.
Компоненты Nexus
Фреймворк состоит из знакомых любому адепту Scrum ролей, событий, артефактов, а также правил, которые это всё объединяют. В Nexus эти составляющие немного изменили, чтобы методологию можно было применять в масштабных проектах.
Роли. По методике Scrum всем участникам процесса разработки назначаются определённые роли. Их можно разделить на две большие группы — «свиней» и «кур». В первую входят все те, кто имеет непосредственное отношение к созданию приложения: скрам-мастер (Scrum Master), который проводит совещания и следит за соблюдением принципов скрама, владелец продукта (Product Owner), представляющий интересы конечных пользователей, и, собственно, команда разработки (Development Team).
Ко второй группе — «курам» — относятся конечные пользователи, продавцы, консультанты и др.
В Nexus, чтобы помочь с масштабированием методологии, появилась роль Nexus Integration Team (NIT). Это целая команда, в которую входят Product Owner, Scrum Master и представители скрам-команд. Их задача — оценить потенциальные проблемы командной разработки и предотвратить их. Важно отметить, что члены NIT не занимаются непосредственно программированием, а дают рекомендации по применению Scrum- и Nexus-принципов всем остальным участникам.
В целом внедрение NIT помогло улучшить координацию между командами за счет грамотного распределения задач. Однако участники ИТ-сообщества говорят, что новая роль также поспособствовала созданию своеобразного «бутылочного горлышка» — когда члены NIT решают организационные вопросы, команда разработки простаивает в ожидании инструкций.
Артефакты. В Scrum под артефактами понимают набор требований к функциональности продукта, которые помогают организовать деятельность разработчиков. Эти требования описаны в двух журналах: журнале пожеланий проекта (project backlog) и журнале пожеланий спринта (sprint backlog).
В журнале пожеланий проекта перечислены общие требования к функциональности — так называемые пользовательские истории, отсортированные в порядке убывания важности. Они помогают получить представление о том, как должен выглядеть конечный продукт.
Журнал пожеланий спринта — список функций для реализации, выбранных владельцем продукта. На основе этого списка разработчики отслеживают задачи, которые нужно завершить до конца одного спринта.
В Nexus вместо журнала пожеланий проекта команды используют журнал пожеланий продукта (Product Backlog). Для упрощения взаимодействия большого количества разработчиков, этот журнал разбивают на части. Каждая часть «закрепляется» за одной из команд. Так, все разработчики понимают, какими задачами из всего проекта они занимаются. При этом каждая команда по-прежнему ведет свой журнал пожеланий спринта.
События. Все члены команды ходят на собрания, которые иногда называют общим термином «события». «Свиньи» проводят их ежедневно, а «куры» — в начале и конце проекта или спринта. Собрания нужны, чтобы обсудить ход разработки, прикинуть планы, выявить узкие места.
Для улучшения коммуникации между разными командами разработчики Nexus добавили четыре новых вида событий:
- Nexus Sprint Planning — в это время команды решают, кто лучше справится с конкретным спринтом из Product Backlog. После этого каждая команда планирует свой спринт, общаясь с другими скрам-командами, чтобы их задачи не пересекались.
- Nexus Daily Scrum — используется для обсуждения текущего положения дел. Позволяет составить план на день или решить проблемы интеграции.
- Nexus Sprint Review — здесь команды делятся своими успехами по итогам каждого спринта.
- Nexus Retrospective — это время тратится на оценку прошлого опыта и составление плана для улучшения процесса разработки в будущем.
Компоненты Nexus
Фреймворк состоит из знакомых любому адепту Scrum ролей, событий, артефактов, а также правил, которые это всё объединяют. В Nexus эти составляющие немного изменили, чтобы методологию можно было применять в масштабных проектах.
Роли. По методике Scrum всем участникам процесса разработки назначаются определённые роли. Их можно разделить на две большие группы — «свиней» и «кур». В первую входят все те, кто имеет непосредственное отношение к созданию приложения: скрам-мастер (Scrum Master), который проводит совещания и следит за соблюдением принципов скрама, владелец продукта (Product Owner), представляющий интересы конечных пользователей, и, собственно, команда разработки (Development Team).
Ко второй группе — «курам» — относятся конечные пользователи, продавцы, консультанты и др.
В Nexus, чтобы помочь с масштабированием методологии, появилась роль Nexus Integration Team (NIT). Это целая команда, в которую входят Product Owner, Scrum Master и представители скрам-команд. Их задача — оценить потенциальные проблемы командной разработки и предотвратить их. Важно отметить, что члены NIT не занимаются непосредственно программированием, а дают рекомендации по применению Scrum- и Nexus-принципов всем остальным участникам.
В целом внедрение NIT помогло улучшить координацию между командами за счет грамотного распределения задач. Однако участники ИТ-сообщества говорят, что новая роль также поспособствовала созданию своеобразного «бутылочного горлышка» — когда члены NIT решают организационные вопросы, команда разработки простаивает в ожидании инструкций.
Артефакты. В Scrum под артефактами понимают набор требований к функциональности продукта, которые помогают организовать деятельность разработчиков. Эти требования описаны в двух журналах: журнале пожеланий проекта (project backlog) и журнале пожеланий спринта (sprint backlog).
В журнале пожеланий проекта перечислены общие требования к функциональности — так называемые пользовательские истории, отсортированные в порядке убывания важности. Они помогают получить представление о том, как должен выглядеть конечный продукт.
Журнал пожеланий спринта — список функций для реализации, выбранных владельцем продукта. На основе этого списка разработчики отслеживают задачи, которые нужно завершить до конца одного спринта.
В Nexus вместо журнала пожеланий проекта команды используют журнал пожеланий продукта (Product Backlog). Для упрощения взаимодействия большого количества разработчиков, этот журнал разбивают на части. Каждая часть «закрепляется» за одной из команд. Так, все разработчики понимают, какими задачами из всего проекта они занимаются. При этом каждая команда по-прежнему ведет свой журнал пожеланий спринта.
События. Все члены команды ходят на собрания, которые иногда называют общим термином «события». «Свиньи» проводят их ежедневно, а «куры» — в начале и конце проекта или спринта. Собрания нужны, чтобы обсудить ход разработки, прикинуть планы, выявить узкие места.
Для улучшения коммуникации между разными командами разработчики Nexus добавили четыре новых вида событий:
- Nexus Sprint Planning — в это время команды решают, кто лучше справится с конкретным спринтом из Product Backlog. После этого каждая команда планирует свой спринт, общаясь с другими скрам-командами, чтобы их задачи не пересекались.
- Nexus Daily Scrum — используется для обсуждения текущего положения дел. Позволяет составить план на день или решить проблемы интеграции.
- Nexus Sprint Review — здесь команды делятся своими успехами по итогам каждого спринта.
- Nexus Retrospective — это время тратится на оценку прошлого опыта и составление плана для улучшения процесса разработки в будущем.
Want to learn more?
Hopefully, this article was useful for you. The Nexus Framework is one of the many interesting topics that is covered in the Scaled Professional Scrum course. If you’d like to join the Scaled Professional Scrum course, check out my class schedule page for more information.
9. Nexus Integration Team is accountable for the integration
The Nexus Integration Team is the most misunderstood element of the framework. The Nexus Integration Team is not a separate team, nor is it intended to do the integration work.
It focuses on the accountability to integrate the work of each team to create a usable increment consequently. If no one is accountable, this could lead to delays in integration and minimizes transparency. Without this transparency, empirical work is not possible.
Nexus Integration Team members come from Scrum teams. The composition may change over time depending on current integration needs and priorities. Their work on the Nexus Integration Team takes precedence.
The Product Owner and a Scrum Master are permanent members of the team. The remaining members are individuals with the skills and knowledge necessary to solve the Nexus problems.
Rather than solving problems directly, the Nexus Integration Team leverages the skills and knowledge of Scrum Team members to achieve optimal solutions to issues identified. Common activities performed by the Nexus Integration Team include coaching, consulting, and creating awareness of interdependencies and cross-team issues. Only in emergencies do Nexus Integration Team members step in to help teams resolve critical issues.
In summary, the Nexus Integration Team is the focal point for integration.
Nexus Sprint Planning
The purpose of Nexus Sprint Planning is to coordinate 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
6. Only an integrated increment creates the necessary transparency for empiricism
A Product Backlog item only fulfills the Definition of Done if it has been fully integrated into the product. Only then is a new increment of the product created. The integration into the product creates the necessary transparency that drives empiricism. A usable increment must be created by the end of the sprint at the latest. Ideally, integration and delivery will occur more frequently.
Integration of work should come before any other work to be done. If there are integration issues, they must be resolved first before other Product Backlog items can be implemented and integrated into the product.
Масштабирование
Масштабирование начинается с хорошо настроенного скрама в рамках одной команды — те же основы и опыт фрактально переносятся на многокомандный уровень. Постепенно исходная команда делится на две-три команды и итеративно и инкрементально добавляются новые разработчики. Нужно следить, чтобы общий инкремент оставался устойчивым и предсказуемым. В ином случае количество потраченных усилий будет несравнимо выше, и сложность зависимостей, интеграционных и коммуникационных проблем будет расти в геометрической прогрессии при добавлении каждой следующей команды.
Nexus предполагает работу над одним продуктом 3-9 команд. Существует еще Nexus+, представляющий собой следующий уровень надстройки над фреймворком (Nexus для Nexus-а), но стоит трижды подумать, прежде чем его применять. В какой-то момент количество времени, уходящее на менеджмент зависимостей, перевешивает пользу от добавления новых команд.
Single source control, continuous integration/build/test/deploy, use of SOLID principles, API’s, DevOps concepts и т.п. — чем больше масштабирование, тем большее количество техник и подходов необходимо использовать.
Product Owner отвечает за верхнеуровневое видение продукта, за стратегию, приоритезацию и определение ценности. В независимости от масштаба проекта, существует только один бэклог и один PO на продукт. Он или она может иметь помощников по ежедневными задачами: описывать критерии истории, разъяснять командам детали, обращаться за помощью к экспертам в какой-то доменной области. Но финальное слово по приоритезации остаётся за Product Owner.
В январе 2018 года свет увидел обновленный фреймворк Nexus — инструмент на базе Scrum, заточенный под командную работу над крупными проектами. Авторы методологии внесли исправления в ряд определений терминов и поменяли порядок лицензирования. С начала года Nexus Guide распространяется по лицензии Creative Commons. И это значит, что любая компания может свободно использовать Nexus (как и Scrum).
Расскажем об особенностях методологии и её основных компонентах.
Кто и зачем создал Nexus
В 1996 году разработчики Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeffrey Sutherland) представили сообществу методологию гибкой разработки ПО Scrum. Она представляет собой набор строго ограниченных по времени итераций (спринтов), за которые разработчики должны реализовать новые функции для программы.
Как отмечает Джефф Сазерленд, в своей книге «Scrum. Революционный метод управления проектами», Scrum позволяет командам разработки добиваться «сверхэффективности» и увеличивать производительность труда на 300%.
Однако Scrum имеет недостаток — он хорошо подходит для работы в пределах одной команды (причем рекомендованное количество её участников составляет всего семь человек), но плохо «масштабируется» за её пределы — когда нужно скоординировать работу большого числа людей.
В Nexus использованы итеративный и инкрементальный подходы к масштабированию процессов разработки ПО. Каждая команда работает в рамках своего спринта, а потом их результаты объединяются. За счет этого разработку продукта легче координировать.
Кто и зачем создал Nexus
В 1996 году разработчики Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeffrey Sutherland) представили сообществу методологию гибкой разработки ПО Scrum. Она представляет собой набор строго ограниченных по времени итераций (спринтов), за которые разработчики должны реализовать новые функции для программы.
Как отмечает Джефф Сазерленд, в своей книге «Scrum. Революционный метод управления проектами», Scrum позволяет командам разработки добиваться «сверхэффективности» и увеличивать производительность труда на 300%.
Однако Scrum имеет недостаток — он хорошо подходит для работы в пределах одной команды (причем рекомендованное количество её участников составляет всего семь человек), но плохо «масштабируется» за её пределы — когда нужно скоординировать работу большого числа людей.
В Nexus использованы итеративный и инкрементальный подходы к масштабированию процессов разработки ПО. Каждая команда работает в рамках своего спринта, а потом их результаты объединяются. За счет этого разработку продукта легче координировать.
Commitment: Product Goal
The commitment for the Product Backlog is the Product Goal. The Product Goal, which describes the future state of the product and serves as a long-term goal of the Nexus.
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. The Product Owner is accountable for the Product Backlog, including its content, availability, and ordering.
Integrated Increment
The Integrated Increment 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.
5. Nexus Daily Scrum makes integration issues visible
Developers from the teams and the Nexus Integration Team meet before the Daily Scrums to review progress against the Nexus Sprint Goal. They review the current state of the integrated increment (the work of a Nexus completed together to date) by making transparent any integration issues and new dependencies that have emerged.
Representatives use this information as input to their team's Daily Scrum. The role of the Nexus Integration Team in this is to help teams identify their integration and dependency issues and the need for action at the team level.
Of course, this is not the only time that cross-team communication takes place. The Nexus Daily Scrum represents a minimal opportunity and a shared time to update the Nexus Sprint Backlog.
Nexus extends Scrum and maintains its competitive edge
The Nexus framework extends the Scrum framework to include the Nexus Integration Team, the Nexus Sprint Backlog, Cross-Team Refinement, and the Nexus Daily Scrum.
Nexus thus represents a minimal but sufficient extension to Scrum. This extension enables teams to deliver an integrated Increment at the end of the Sprint. The transparency that results from an integrated increment is the decisive competitive advantage of Nexus. It is the only way that organizations remain able to react to changes at any time.
Nexus Daily Scrum
The purpose of the Nexus Daily Scrum 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.
The Nexus Daily Scrum is not the only time Scrum Teams in the Nexus are allowed to adjust their plan. Cross-team communication can occur throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.
The Sprint
A Sprint in Nexus is the same as in Scrum. The Scrum Teams in a Nexus produce a single Integrated Increment.
Nexus Sprint Review
The Nexus Sprint Review 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.
Since the entire Integrated Increment is the focus for capturing feedback from stakeholders, a Nexus Sprint Review replaces individual Scrum Team Sprint Reviews. During the event, the Nexus presents the results of their work to key stakeholders and progress toward the Product Goal is discussed, although it may not be possible to show all completed work in detail. Based on this information, attendees collaborate on what the Nexus should do to address the feedback. The Product Backlog may be adjusted to reflect these discussions.
Nexus Sprint Backlog
A Nexus Sprint Backlog 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.
1. Cross-Team Refinement makes the Product Backlog transparent.
In the Cross-Team Refinement , the Product Backlog is broken down. This is done until it is clear which team pulls the work and whether there are dependencies between the items. This level of transparency is necessary to eliminate dependencies in advance. Forecasts are made to determine which team will most likely work on which Product Backlog item in the upcoming sprints. Cross-Team Refinement simplifies planning for the next Sprints.
Representatives from each Scrum team participate. They are not selected based on their role but situationally based on the work to be refined. How often the representatives meet for cross-team refinement is determined by uncertainty within the Product Backlog. Since refinement is an ongoing process, no timebox is prescribed. Typically, Scrum Teams continue refinement within their teams so that the Product Backlog items are ready for selection in a Nexus Sprint Planning Event.
7. Nexus Sprint Review to inspect the integrated increment
The Nexus Sprint Review replaces the Sprint Reviews of the Scrum Teams to provide a holistic view of the outcome of the Sprint. The purpose is to get feedback from stakeholders on the increment and identify product improvements.
Since this can be a large event, the focus should be on high-level results. If there is a need to inspect a detailed output, the Product Owner and stakeholder can review specific parts of the product at any time during the sprint. As with Scrum, the results of the Nexus Sprint Review serve as input to adapt the Product Backlog.
The Sprint Review takes place at the end of a Sprint. Afterward, the Scrum teams have enough information to conduct the Sprint Retrospective.
Артефакты
Чтобы видеть целостную картину по продукту, Product Backlog всегда сохраняется в единственном числе, как и инкремент. В Nexus нет командных Sprint Review, и результатом спринта является сумма всего, сделанного командами — Integrated Increment по продукту. Помимо Sprint Backlog, добавляется новый артефакт — Nexus Sprint Backlog, который является набором фич для всех команд с указанными между ними зависимостями — своеобразным общим планом спринта, — и используется для отслеживания прогресса и ежедневного перепланирования по общему инкременту.
Definition of Done формируется NIT, пересматривается и поддерживается в актуальном состоянии после каждой ретроспективы. Команды могут дополнительно создавать свои DoD, но правила должны быть строже, чем у общего.
Nexus Sprint Retrospective
The purpose of the Nexus Sprint Retrospective 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.
The Nexus Sprint Retrospective concludes the Sprint.
Artifacts represent work or value, and are designed to maximize transparency, as described in the Scrum Guide. The Nexus Integration Team works with the Scrum Teams within a Nexus to ensure that transparency is achieved across all artifacts and that the state of the Integrated Increment is widely understood.
Nexus extends Scrum with the following artifacts, and each artifact contains a commitment, as indicated below . These commitments exist to reinforce empiricism and the Scrum value for the Nexus and its stakeholders.
3. Nexus Sprint Goal enables focus across teams
This goal provides an overarching goal for all teams in a sprint. It helps create coherence and focus for the Nexus. It also encourages Scrum teams, rather than working on separate initiatives, to work together.
The Product Owner introduces the Nexus Sprint Goal to define the purpose of the Sprint. Together, the Scrum Teams select the highest priority Product Backlog items that, when completed, will realize the Nexus Sprint Goal. The ongoing refinement process should have already identified and largely eliminated dependencies for the selected Product Backlog items.
After the initial selection of Product Backlog items, the individual Scrum Teams proceed with their sprint planning.
Nexus Sprint Planning serves as a container for the Sprint Plannings of the individual Scrum Teams. It is completed when a rough plan of achieving the Nexus Sprint Goal and a detailed plan for the first days of the Sprint, has been created. This overarching plan is captured in the Nexus Sprint Backlog.
The Nexus Framework Explained
We will discuss the framework step by step and explain how the elements allow us to identify and eliminate dependencies across teams. We assume that the reader knows the Scrum Framework well and therefore we highlight just the elements add to the Scrum Framework.
We start on the left with the Product Backlog.
Overview of the Nexus Framework for scaling Scrum. Caution: An icon does not represent a person but a responsibility. Each Nexus has only one Product Owner.
Working on a product requires a Product Backlog. It is the only source of work carried out by Scrum teams. To make this work transparent, Refinement is a helpful practice in Scrum. In Scaled Scrum, however, Cross-Team Refinement is mandatory.
4. Nexus Sprint Backlog is a real-time picture of dependencies
It consists of the Product Backlog items that the developers in Nexus believe are necessary to achieve the Nexus Sprint goal. This new artifact makes visible all the teams' forecasted work and all the dependencies between them.
The Nexus Sprint Backlog helps coordinate work across team boundaries. For example, if Scrum Team A depends on Scrum Team B to complete a Product Backlog item and Scrum Team A does not make progress in completing it, this would be visible in the Nexus Sprint Backlog.
This backlog allows teams to collaborate during the sprint across teams. It can be seen as the aggregation of the Sprint Backlogs of the Scrum Teams. It helps the Nexus to stay accountable for the dependencies during the Sprint. The Nexus Sprint Backlog represents a real-time picture of the workflow during the Sprint and needs to be updated daily. This update should take place in the Nexus Daily Scrum.
Когда стоит использовать Nexus
В масштабных проектах. Фреймворк помогает «бесшовно» организовать работу нескольких скрам-команд в крупных проектах. К примеру, одна индийская компания, создающая security-софт (авторы Scrum не раскрыли её название), год использовала Scrum для разработки своих продуктов. Поначалу в компании была одна скрам-команда, однако вскоре их число увеличилось до трех, и начались проблемы с интеграцией отдельных решений.
Тогда компания пригласила эксперта по Scrum, и он предложил перенести рабочую схему Scrum на многокомандный уровень — внедрить Nexus. Сейчас по Nexus-методологии работают уже шесть команд, которые стабильно выпускают новые релизы ПО каждые две недели.
Тогда в компании решили попробовать Nexus. Методика позволила сократить время выпуска релизов в три раза и выпускать продукт раз в три месяца.
Nexus помогает наладить взаимодействие и между командами, «раскиданными» по всем земному шару. «Ежедневных спринты» поддерживают высокий уровень коммуникации и вовлеченности сотрудников в проект.
Отметим, что хотя Nexus и помогает скоординировать работу множества команд разработки при работе над крупным проектом и ускорить выход релизов (как в случае с TPP), он все же не способен решить проблемы, связанные с внутренним устройством организации. К примеру, фреймворк не окажет заметного эффекта, если в командах будет не хватать специалистов для решения всех задач.
Таким образом, Nexus подходит для работы над крупными проектами (по словам создателей методологии, она дает эффективно управлять девятью скрам-командами) и при грамотном применении помогает ускорить процесс разработки в 3–4 раза. Однако главным фокусом этой методологии является решение проблем с интеграцией, потому она не может помочь в решении других организационных вопросов в компании.
P.S. Пара свежих материалов из Первого блога о корпоративном IaaS:
When scaling Scrum, we balance cost and effort with benefits and advantages. Costs and effort come from adding teams. Benefits and advantages come from delivering more value in the same amount of time.
Scrum practitioners know that scaling Scrum is more than just a math problem. Common sense tells us that there will inevitably be integration conflicts when teams work together on a single initiative. These conflicts arise from interdependencies. We know that it takes discipline and effort to make dependencies transparent and eliminate them. This effort is put into perspective if an integrated increment can be delivered at the end of each sprint. Only delivery will create value for the organization.
Continuously eliminating dependencies and integrating all work is deliberate practice. It is at the heart of Nexus. At its core, the Nexus framework helps multiple teams continuously integrate their work into a product.
Scrum practitioners will find themselves using the Nexus framework because it extends Scrum only minimally. Organizations that choose to scale Scrum with Nexus are committed to continuously delivering value to their users. They don't waste sprints training employees in new roles, implementing new processes or ways of working, setting up new infrastructure, or waiting to get support from external consultants.
This article provides an overview of the Nexus framework for practitioners who are already familiar with Scrum.
Commitment: Nexus Sprint Goal
The commitment for the Nexus Sprint Backlog is the Nexus Sprint Goal. The Nexus Sprint Goal is a single objective for the Nexus. It is the sum of all the work and Sprint Goals of the Scrum Teams within the Nexus. It creates coherence and focus for the Nexus for the Sprint by encouraging the Scrum Teams to work together rather than on separate initiatives. The Nexus Sprint Goal is created at the Nexus Sprint Planning event and added to the Nexus Sprint Backlog. As Scrum Teams work during the Sprint, they keep the Nexus Sprint Goal in mind. 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 receive stakeholder feedback.
Когда стоит использовать Nexus
В масштабных проектах. Фреймворк помогает «бесшовно» организовать работу нескольких скрам-команд в крупных проектах. К примеру, одна индийская компания, создающая security-софт (авторы Scrum не раскрыли её название), год использовала Scrum для разработки своих продуктов. Поначалу в компании была одна скрам-команда, однако вскоре их число увеличилось до трех, и начались проблемы с интеграцией отдельных решений.
Тогда компания пригласила эксперта по Scrum, и он предложил перенести рабочую схему Scrum на многокомандный уровень — внедрить Nexus. Сейчас по Nexus-методологии работают уже шесть команд, которые стабильно выпускают новые релизы ПО каждые две недели.
Тогда в компании решили попробовать Nexus. Методика позволила сократить время выпуска релизов в три раза и выпускать продукт раз в три месяца.
Nexus помогает наладить взаимодействие и между командами, «раскиданными» по всем земному шару. «Ежедневных спринты» поддерживают высокий уровень коммуникации и вовлеченности сотрудников в проект.
Отметим, что хотя Nexus и помогает скоординировать работу множества команд разработки при работе над крупным проектом и ускорить выход релизов (как в случае с TPP), он все же не способен решить проблемы, связанные с внутренним устройством организации. К примеру, фреймворк не окажет заметного эффекта, если в командах будет не хватать специалистов для решения всех задач.
Таким образом, Nexus подходит для работы над крупными проектами (по словам создателей методологии, она дает эффективно управлять девятью скрам-командами) и при грамотном применении помогает ускорить процесс разработки в 3–4 раза. Однако главным фокусом этой методологии является решение проблем с интеграцией, потому она не может помочь в решении других организационных вопросов в компании.
P.S. Пара свежих материалов из Первого блога о корпоративном IaaS:
В январе 2018 года свет увидел обновленный фреймворк Nexus — инструмент на базе Scrum, заточенный под командную работу над крупными проектами. Авторы методологии внесли исправления в ряд определений терминов и поменяли порядок лицензирования. С начала года Nexus Guide распространяется по лицензии Creative Commons. И это значит, что любая компания может свободно использовать Nexus (как и Scrum).
Расскажем об особенностях методологии и её основных компонентах.
Commitment: Definition of Done
The commitment for the Integrated Increment is the Definition of Done, which 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, and usable. The Nexus Integration Team is responsible for a Definition of Done that can be applied to the Integrated Increment developed each Sprint. All Scrum Teams within the Nexus must define and adhere to this Definition of Done. Individual Scrum Teams self-manage to achieve this state. They may choose to apply a more stringent Definition of Done within their own teams, but cannot apply less rigorous criteria than agreed for the Integrated Increment.
Decisions 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.
Nexus is free and offered in this Guide. As with the Scrum framework, the accountabilities in Nexus, its artifacts, events, and rules are immutable. Although implementing only parts of Nexus is possible, the result is not Nexus.
Nexus and Scaled Professional Scrum were collaboratively developed by Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber, and Gunther Verheyen. A special thank you to Kurt Bittner, Ravi Verma, Fredrik Wendt, Jesse Houwing and Simon Flossmann for their significant contributions in advancing Nexus and Scaled Professional Scrum.
Весной этого года команда наших разработчиков побывала на тренинге по многокомандному скраму с использованием фреймворка Nexus. Это оказался очень интересный инструмент, и мы хотим поделиться с вами впечатлениями от его возможностей.
Nexus — это фреймворк Кена Швабера, являющийся органичным и эволюционным расширением классического скрама для крупных проектов с многокомандной разработкой. Он базируется на тех же привычных scrum-основах: ролях, артефактах и ивентах, дополняя их аналогичными ивентами и артефактами для выявления и управления зависимостями, своевременного обмена информацией и доменными знаниями между командами и удержания фокуса на конечном продукте, а не индивидуальных инкрементах.
К стандартным scrum-ролям добавляется новая — Nexus Integration Team, отвечающая за успешную интеграцию всех сделанных инкрементов и решение технических и нетехнических ограничений между командами.
Эта группа участников состоит из выбранных представителей команд, которые озвучивают интересы команды. Если рабочее время участников делится между NIT и командой разработчиков, то более приоритетна работа в Nexus Integration Team.
Состав интеграционной команды может меняться по необходимости.
События
С камнем преткновения многокомандного скрама — перекрёстными зависимостями между фичами и командами, — в процесс официально добавляются refinement sessions, время проведения которых жёстко не задано и выбирается в любой удобный момент спринта.
Событие проходит в несколько этапов: сперва NIT разбивает содержимое бэклога на мелкие и независимые части до уровня, когда одна команда может закончить фичу за один спринт.
Затем выявляются и визуализируются все зависимости между фичами и командами. На этом этапе NIT определяет своеобразную «дорожную карту» фич и зависимостей: что и какой командой будет сделано, в каком спринте.
Дальше фичи спускаются на уровень команд и пересматриваются более подробно с помощью того же подхода: разделить на более мелкие части, выделить и визуализировать зависимости.
Планирование в Nexus также проходит этапами:
- На начальном этапе, где присутствуют все команды, Product Owner озвучивает и поясняет общие приоритеты спринта, цель общего инкремента. Представители команд еще раз корректируют распределение работы исходя из найденных зависимостей. Также на этом этапе формулируется общая цель спринта.
- Дальше команды продолжают планирование в индивидуальном порядке, и результаты планирования по всем командам вносятся в Nexus Sprint Backlog.
Классические три вопроса скрама для интеграционной команды трансформируются в:
- Что было успешно интегрировано до сегодняшнего Daily Scrum?
- Какие новые зависимости обнаружили?
- Какую информацию нужно распространить среди команд сегодня?
Nexus Retrospective состоит из трёх частей:
- NIT определяет проблемы, затронувшие более одной команды, и передает их как дополнительную входную информацию для командной ретроспективы.
- Командная ретроспектива, на которой обязательно принимаются во внимание общие проблемы, определённые на первом этапе
- Финальная часть ретроспективы, где формируется общее видение, как визуализировать и отслеживать сформулированные пункты.
Nexus Integration Team
The Nexus Integration 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.
While Scrum Teams address integration issues within the Nexus, the Nexus Integration Team provides a focal point of integration for the Nexus. 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 Scrum Master, and the appropriate members from the Scrum Teams belong to the Nexus Integration Team. Appropriate members are the people with the necessary skills and knowledge to help resolve the issues the Nexus faces at any point in time. Composition of the Nexus Integration Team may change over time to reflect the current needs of a Nexus. Common activities the Nexus Integration Team might perform include coaching, consulting, and highlighting awareness of dependencies and cross-team issues.
The Nexus Integration Team consists of:
- The Product Owner: A Nexus works off a single Product Backlog, and as described in Scrum, 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. The Product Owner is also accountable for effective Product Backlog management. How this is done may vary widely across organizations, Nexuses, Scrum Teams, and individuals.
- 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 moreNexus Integration Team Members: The Nexus Integration Team often consists of 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.
The Nexus Integration Team is responsible for coaching and guiding the Scrum Teams to acquire, implement, and learn practices and tools that improve their ability to produce a valuable, useful Increment.
Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership. As long as their Nexus Integration Team responsibility is satisfied, they can work as team members of their respective Scrum Teams. This preference helps ensure that the work to resolve issues affecting multiple teams has priority.
8. Nexus Sprint Retrospective enables improvement across the Nexus
There are numerous ways to conduct the Nexus Sprint Retrospective. One common way is:
As input to the Scrum Team Retrospectives, representatives identify issues that affect multiple teams. As a follow-up, each Scrum Team conducts its own Sprint Retrospective. The cross-team issues can serve as the basis for this. After the team retrospective, representatives reconvene to visualize the improvements. This helps teams stay accountable for its implementation during the sprint.
Regardless of how a Nexus conducts its Sprint Retrospective, it must remain true to the guiding principle: The Nexus uses bottom-up intelligence to fix problems that hold back the Nexus as a whole.
Cross-Team Refinement
Cross-Team Refinement of the Product Backlog 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.
Cross-Team Refinement of the Product Backlog at scale serves a dual purpose:
- It helps the Scrum Teams forecast which team will deliver which Product Backlog items.
- It identifies dependencies across those teams.
Cross-Team Refinement is ongoing. The frequency, duration, and attendance of Cross-Team Refinement varies to optimize these two purposes.
Where needed, each Scrum Team will continue their own refinement in order for the Product Backlog items to be ready for selection in a Nexus Sprint Planning event. An adequately refined Product Backlog will minimize the emergence of new dependencies during Nexus Sprint Planning.
2. Nexus Sprint Planning coordinates activities for the Sprint.
Nexus Sprint Planning initiates the Sprint. Within this event, the work and all activities necessary for this Sprint are coordinated. Ideally, all members of the Nexus participate in Nexus Sprint Planning.
The event begins with representatives of the Scrum Teams and the Product Owner inspecting the refined Product Backlog and setting a goal for the Sprint.
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.
At scale, it may not be practical for all members of the Nexus to participate to share information or to 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.
Nexus events consist of:
Читайте также: