Типовые ошибки при использовании Scrum
Scrum предполагает полное использование ролей, событий, артефактов и правил в соответствии с официальным руководством. Частичное или некорректное использование этих элементов нельзя называть Scrum. В этой статье я расскажу примеры ошибок, которые я замечал у команд, верящих в то, что "работают по Scrum".
1. Владелец продукта согласовывает технические детали
Реальность: продакт должен погружаться в технические детали и решать, какую технологию должна использовать команда при разработке.
The Scrum Guide: продакт отвечает за видение продукта (почему делаем?) и глобальные цели (что делаем?), которые отражает в бэклоге продукта. Команда отвечает за реализацию (как делаем? каким образом достигаем цели?).
Владелец продукта — максимизатор ценности:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog.
The Scrum Team > The Product Owner
The Product Owner is the chief product visionary. The PO should be able to clearly articulate the product vision to the Scrum Team and key stakeholders, and how that vision aims to maximize the value of the product and of the work the Scrum Team performs.
Источник: подготовительные тесты
Three most applicable characteristics of the Product Owner:
1. Product Marketplace Expert
2. Product Value Maximizer
3. Lead Facilitator of Key Stakeholder Involvement
Источник: подготовительные тесты
Команда разработки — самостоятельная боевая единица, которая самостоятельно решает, как достигать цели спринта:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
The Scrum Team > The Development Team
2. Кто угодно ставит задачи команде разработки и влияет на приоритеты в течение спринта
Реальность: CEO, топ-менеджеры и другие заинтересованные лица напрямую ставят задачи команде разработки.
The Scrum Guide: только владелец продукта управляет бэклогом продукта и отвечает за него; только команда управляет бэклогом спринта и отвечает за него. Любые предложения стейкхолдеров проходят через владельца продукта, который самостоятельно принимает решение об их добавлении и приоритете в продуктовом бэклоге.
Только владелец продукта принимает решения по продукту:
The Product Owner is the sole person (единственное лицо) responsible for managing the Product Backlog.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.
The Scrum Team > The Product Owner
Изменения в бэклоге продукта могут вноситься только по решению владельца продукта:
Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Scrum Artifacts > Product Backlog
Команда разработки самостоятельно управляет своей работой:
Development Teams are structured and empowered by the organization to organize and manage their own work.
The Scrum Team > The Development Team
Только команда разработки владеет бэклогом спринта:
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. Scrum Artifacts > Sprint Backlog
Стейкхолдеры могут принимать участие только в одном событии Scrum — Sprint Review. Они не участвуют в Sprint Planning, Daily Scrum и Sprint Retrospective. При этом, любой участник Scrum может взаимодействовать со стейкхолдерами в любое время.
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
Scrum Events > Sprint Review
3. Непрозрачные артефакты
Реальность: над разными фичами продукта работают разные владельцы продуктов. У каждой команды свой продуктовый бэклог, в котором крайне сложно разобраться другим. Не сформулированы DoD, и невозможно сравнить производительность двух команд. Непонятно, какой прогресс по задачам.
The Scrum Guide: у одного продукта должен быть один бэклог и один владелец продукта. DoD должны быть либо общие для компании, либо согласованы между разными командами разработки, которые трудятся над одним продуктом. Прогресс по продуктовому бэклогу обновляется каждый Sprint Review, а по бэклогу спринта — каждый день на Daily Scrum.
У всех должно быть ясное понимание языка, процесса, критериев завершенности:
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
For example:
- A common language referring to the process must be shared by all participants; and,
- Those performing the work and those inspecting the resulting increment must share a common definition of "Done".
Scrum Theory
Люди принимают решения на основании артефактов. Если они непрозрачны — повышаются риски, связанные с этими решениями:
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.
Artifact Transparency
Все должны понимать, что значит "Готово":
When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment.
Artifact Transparency
Если критерии готовности не сформулированы на уровне компании, их создает команда разработки. Если команд разработки одного продукта несколько — они совместно разрабатывают единый список критериев готовности:
If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done".
Artifact Transparency
Для продукта может существовать только один продуктовый бэклог:
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.
Scrum Artifacts > Product Backlog
За прозрачность продуктового бэклога отвечает владелец продукта (независимо от того, кто выполняет эту работу):
Product Backlog management includes ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next. The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
The Scrim Team > The Product Owner
Прогресс продуктового бэклога обновляет владелец продукта как минимум каждый Sprint Review:
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Scrum Artifacts > Prodcut Backlog
Команда разработки самостоятельно обеспечивает прозрачность бэклога и прогресса спринта на ежедневной основе:
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
Scrum Artifacts > Sprint Backlog
4. По итогам спринта нет инкремента
Реальность: команда мыслит задачами, а не целями. По итогу спринта сделаны какие-то задачи, но нет ни одного готового инкремента, который можно выпустить. Либо выпущен продукт без соблюдения "критериев готовности", из-за чего пользователи сталкиваются с множеством багов и уходят из продукта.
The Scrum Guide: смысл спринта — поставлять потенциально готовый к выпуску инкремент готового продукта в соответствии с критериями готовности.
Готовый к использованию и потенциально готовый к публикации продуктовый инкремент — это сердце спринта:
The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.
Scrum Events > The Sprint
Работа команды — поставлять потенциально готовый к публикации инкремент готового продукта каждый спринт:
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment.
The Scrum Team > The Development Team
Инкремент — это сумма всех завершенных элементов продуктового бэклога в текущем спринте и сумма всех инкрментов предыдущих спринтов.
Этот момент сложно понять из определения, поэтому поясню на примере. Допустим, мы готовим торт для друзей. В первом спринте мы запекли коржи и смазали их кремом. Во втором спринте мы обмазали торт шоколадным кремом, добавили сливок и ягод. В третьем спринте мы положили торт в красивую упаковку с роскошным бантом. Инкремент первого спринта — вкусный торт, второго спринта — роскошный шоколадный торт с ягодами (а не шоколадный крем со сливками и ягодами), инкремент третьего спринта — роскошный шоколадный торт в волшебной подарочной упаковке (а не упаковка).
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Scrum Artifacts > Increment
С инкрементом в целом и MVP в частности связано множество заблуждений, поэтому, опубликую две картинки для понимания (этого нет в The Scrum Guide, но никак ему не противоречит):
В статье я привел перечень ошибок, которые замечал в работе с командами, верящими, что "работают по Scrum". Этот список не отражает положение дел в целом и ограничен исключительно моим опытом. Если хотите поделиться дополнительными кейсами, какими-то полноценными исследованиями со статистикой, другими замечаниями и предложениями — пишите мне в телеграм (@marknelyubin).