Підходи взаємодії Скрам Майстра та Власника Продукту | Scrum Україна - тренінги, навчання та сертифікації Agile, Scrum, Large-Scale Scrum
 
Стаття відображається оригінальною мовою.

Підходи взаємодії Скрам Майстра та Власника Продукту

15 Feb 2023

Ідея статті народилась із проблеми, яку я часто зустрічаю під час роботи з різними компаніями: Скрам Майстри не можуть знайти підходи до роботи з Власником Продукту (Product Owner = PO). Ця стаття дасть вам кілька ідей навколо 3-х проблем, чим ви можете бути корисні для PO.

Розгляньмо 3 проблеми, з якими може допомогти Скрам Майстер.

Нерівномірність роботи

Робота, що бере команда - в один спринт беруть, як великі, так і малі задачі, пробуючи “грати в тетріс” у рамках спринту: тобто комбінувати роботу у таким спосіб, щоб в ідеалі всі були зайняті, але все, що взяли, було закінчено. Але чим більше буде варіативність, тим менша ймовірність, що робота в той пазл складеться.

Unevenness of work

Прикладами рішення можуть бути комплекс вправ:

  • Проведення навчання для команди та PO з декомпозиції. Короткі тренінги, на 1-2 години, можна розробити на прикладі гри Elephant Carpaccio чи подібним їм.
  • Комбінуйте навчання з реальним рефайментом беклогу. Проведіть навчання і у той же день зробіть PBR та використовуйте підходи з вашого навчання.
  • Цю навичку складно освоїти без регулярної практики, тому рекомендую вам постійно тренуватись у цьому напрямку. Наприклад, самостійно пробуючи декомпозувати ідеї, що є у вашому продукті. Тобто ви берете якийсь функціонал, самостійно декомпозуєте його, дивитесь, як саме можна вашу декомпозицію використовувати, вести інкрементальну розробку, приорітизувати. Обговорюйте декомпозицію з вашим PO, залучайте його та команду до таких дискусій із точки “давайте подумаємо, як ми можемо краще працювати з беклогом”.
  • Фокусуйте команду на рівномірній декомпозиції, щоб елементи беклогу, що ви берете в спринт, мали однакову розмірність. Основою такої дискусії можуть бути приклади з Теорії Обмежень.
  • Проводьте ретроспективи, що сфокусовані на обговорені того, як робота виконується в спринті, як вона проходить крізь нього, де зависає і чому.
  • Фокусуйтесь на цілі спринту, як на інструменті пріоритизації завдань у спринті. Тобто кожен день дивіться, чи ви йдете до цілі, чи ні. Запросіть PO на Daily Scrum в команді, залучайте PO до розмов про ціль та її досягнення.
  • Використовуйте онлайн дошки для візуалізації вашого прогресу. Якщо команда чи PO не готові до такого, зробіть таку дошку для себе. Далі ви можете використовувати її для обговорення планів, таким чином ви залучите людей до її використання. Найкращим інструментом для старту буде User Story Mapping. Спробуйте створити її з тими, хто готовий (працюйте з волонтерами). Якщо зовсім туго, залучіть PO і зробіть це з ним. Попросіть його показувати інструмент команді, у такий спосіб ви залучите їх до використання та оновлення інструменту.
  • Посилайтеся на візуалізацію при плануванні спринтів та виборі завдань для PBR.

User Story Mapping

Вотерфольно-ітеративний підхід

Доставка нового функціоналу дуже часто йде не ітеративно-інкрементально, а конкретними етапами (по типу аналіз, розробка, тестування, поставка і т.д.), де тільки етап розробки йде по Скраму. Наприклад, спочатку йде фаза аналізу і формування вимог, потім команда формує технічне бачення і архітектуру, потім вони це розроблюють, тестують інтегроване рішення, фіксять проблеми. У такого підходу є очевидні проблеми, наприклад:

  1. Створення більшої кількості документації, ніж потрібно, втрата на це часу, що фактично зменшує час на розробку
  2. Неможливість викинути частину скоупу, якщо ви не встигаєте через сильну інтегрованість рішення на рівні як архітектури, так дизайну бізнес-логіки.
  3. Отримання результату вкінці, виявлення найбільших ризиків (інтеграції та поставки) лише на останньому етапі.

Такий підхід унеможливлює прогнозування роботи й робить її максимально зав'язаною на брак помилок. Хоча команда може використовувати ітеративний підхід, він фактично виконує роль розбивки проєкту на етапи, ніж ітеративну поставку.
У мене є досить детальне відео на цю тему.

Що ми можемо запропонувати тут:

  • Аналізуйте, скільки ви роботи берете в спринт і скільки закінчуєте, скільки перевалюється зі спринту в спринт;
  • Працюйте з PO в напрямку планування лише тої кількості роботи, що ви ісіторично можете виконати (робите 5 задач за спринт, то не беріть більше ніж 5);
  • Обговорюйте з PO і командою на PBR тільки той обсяг роботи, що ви можете взяти в наступний спринт, не плануйте на довгий період;
  • Оновлюйте роадмап (чи будь-яку іншу візуалізацію прогресу) кожен PBR та планування;
  • Аналізуйте виконання цілей спринту з командою і PO, зробіть це ритуалом.

Дезінтеграція Власника продукту й команди

Здебільшого команда бачить власника продукту, як людину, що не є фактичною частиною команди. Проявом цього може бути:

  1. Відсутність власника продукту на ретроспективах. Такі ретроспективи, часто, проходять під гаслами “у всіх проблемах винен бізнес”, але дізнатися про це неможливо, бо той самий бізнес не запросили.
  2. Підхід “ми”-”вони”, коли команда протиставляє себе умовному Власникові Продукту. Проявом може буди непрозора комунікація про проблеми, або не завчасна. Часто можна побачити динаміку Батьки-Діти, де Власник Продукту поводить себе з командою з батьківського его стану, а вони грають роль неслухняних або бунтівних дітей.

Проблема дезінтеграції також часто лежить у площині організаційної структури, де найчастіше можливі наступні варіанти:

  1. Власник Продукту фактично є менеджером команди. Тоді команда, умовно, “боїться” буди прозорою і казати про ризики, адже це буде впливати на їх подальшу оцінку в очах менеджера. Так, тут багато залежить від лідерських навичок менеджера і його підходів у роботі.
  2. Команда використовується в умовній моделі “аутсорсу”, де Власник Продукту є замовником роботи в команди, що управляється менеджером з ІТ. Найчастіше трапляється в банках, телеком компаніях і подібним їм структурам.

Що я можу запропонувати вам:

  • Зробіть перший крок назустріч PO і запросить його на всі зустрічі.
  • Поясніть команді та PO, яку проблему створює його відсутність на зустрічах, особливо на ретро. Будьте відкритими та будьте в позиції “я прошу про допомогу”, а не в позиції “так написано в Скрам Гайді”
  • Заплануйте регулярні 1-1 з PO, обговорюйте теми за день до. У такий спосіб ви почнете вибудовувати місток між вами та PO, що дасть змогу відбудувати місток далі з командою.
  • Створіть домовленості між усіма ролями, обговоріть очікування.

Сподіваюсь поради будуть вам у пригоді!

Рекомендовані заходи

тренінг
Дмитро Незабитовський  

Дводенний курс з основ Agile, Scrum фреймворку та Kanban-методу. Курс сертифікаційний, після закінчення учасники отримують іменні сертифікати ICAgile Certified Professional (ICP): Scrum & Kanban.

тренінг
Олексій Кривицький  

Цей сертифікований онлайн-курс розкриє перед вам мир масштабної продуктової розробки на 5, 10 або 11...

вебінар
Дмитро Незабитовський, Олександр Червінський  

На цьому вебінарі ми розкриємо основні поняття та принципи роботи з моделями командних ролей в Agile командах, а також надамо практичні поради та інструменти для їх ефективного застосування.

Рекомендовані статті

Скільки коштують ваші зустрічі? Та як не втрачати гроші.

Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …

Top 5 питань про Agile Retrospectives

Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.

Чому коучинговий підхід актуальний у бізнесі?

Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

З приводу тренінгів, реєстрацій, рахунків:
+380993383636
@scrum_ukraine
hello@scrum.ua

Із питань корпоративних програм:
+380993383636
hello@scrum.ua

©2017 - 2024 Scrum Ukraine. Всі права захищені.

Політика конфіденційності