4 поради про щоденний скрам для власників продукту і продакт-менеджерів
Щоденний скрам — звична зустріч для аджайл-команд. Та я досі стикаюся з тим, що деякі власники продукту і продакт-менеджери не певні, чи варто їм на неї ходити. У цьому пості Роман Піхлер зібрав рекомендації про те, чи варто PM і PO ходити на дейлі, коли це краще робити і як саме брати в ньому участь.
Порада 1: Пам’ятайте, нащо це потрібно
Щоденний скрам або, як його ще називають, дейлі стендап, створено, щоб допомогти команді розробки виконувати її роботу. Скрам-команда спільно визначає ціль спринту і несе відповідальність за те, щоб її досягти. Це включає щоденне відстеження прогресу і обговорення будь-яких необхідних змін. Щоденний скрам підтримує самоорганізацію в силу того, що для учасників команди він є приводом поговорити на такі теми:
- як вони прогресують;
- що планують робити далі;
- чи потрібна комусь допомога — чи є труднощі або блокери.
Щоденний скрам має проходити швидко — не більш ніж 15 хвилин. Його слід проводити щодня в одному місці в один час; на мій погляд, найкращий час — ранок.
Порада 2: Чи слід приходити?
Я раджу власникам продукту і продакт-менеджерам брати участь у щоденному скрамі принаймні двічі на тиждень. Це допомагає розуміти, що відбувається у діючому спринті, чи можете ви допомогти і як саме. Наприклад, ви можете помітити, що деякі історії користувачів виконані і можна влаштувати їх огляд; чи що команді незрозумілі деякі критерії прийому і потрібні ваші роз’яснення.
Також ви можете попросити команду уточнити елементи беклогу продукту чи, наприклад, оновити дорожну карту продукту.
Якщо ж ви працюєте над крупним продуктом і співпрацюєте з іншими відповідальними за цей продукт (власниками фіч або компонентів), зазвичай вам не потрібно ходити на дейлі-скрам. Замість нього ви берете участь у скрамі скрамів (SoS) — аналогові щоденного скраму, який часто використовують для фасилітації роботи кількох команд. Мені подобається проводити щоденні зустрічі SoS відразу після щоденних скрамів, куди приходять представники кожної команди розробки.
В кожному разі, пам’ятайте, що вирішення проблем не входить в задачі цієї зустрічі. Тож вам не слід перетворювати її на воркшоп з роботи з беклогом або дорожною картою. Якщо ви бачите, що в учасників команди виникають питання про критерії прийому, наприклад, просто дайте на них відповідь після зустрічі. Якщо ж вам потрібна допомога команди в роботі над дорожною картою продукту, ви також можете організувати окрему зустріч.
Нарешті, не забувайте про баланс власних обов’язків. Це ж не лише співпраця з командою розробки, але також і зустрічі з клієнтами і користувачами, домовленості зі стейкхолдерами. Якщо ви фанатично відвідуєте щоденний скрам, перевірте, чи це не порушує рівновагу з іншими справами.
Порада 3: Не втручайтеся
Ця зустріч потрібна в першу чергу не вам, а команді розробки. Утримуйтеся від спроб втрутитися в самоорганізовану активність команди: не призначайте задач, не критикуйте учасників особисто — це може ослабити автономію команди і її відданість справі. Якщо ви відчуваєте тривогу щодо того, як проходить спринт, скажіть про це чесно, але конструктивно. Не вказуйте команді, що їй робити. Керувати спринтом і досягати його мети мають учасники команди, ви ж маєте керувати продуктом і повним циклом його релізу (який складається з кількох спринтів).
Якщо члени команди дивляться на вас і розповідають, що вони встигли зробити, швидше за все, щось іде не так. Люди звітують вам про статус проєкту замість того, щоб взяти на себе відповідальність за свою роботу. У таких випадках поясніть їм, що відбувається, і попросіть звернутися не до вас, а одне до одного. Як варіант, ви можете припинити відвідувати щоденний скрам, поки не обговорите, як покращити процес, на наступній ретроспективі спринту.
Варто відмовитися від відвідування зустрічей також і тоді, коли вам складно втриматися від вказівок, кому що робити і яку дію за якою слід виконувати. Так ви допоможете команді самоорганізуватися і повністю контролювати свою роботу. При цьому слід розібратися, чому вам складно відпустити роботу і довірити її команді: тривогу викликає амбітна ціль проєкту? Чи, наприклад, спроможність команди виконати ціль спринту? Що ви можете зробити, щоб відчути себе спокійніше?
Порада 4: Дайте скрам-майстру робити свою роботу
Організация ефективного щоденного скраму — обов’язок скрам-майстра. Хоч якщо ви відчуваєте, що щось іде хибним шляхом — наприклад, що учасники команди не відстежують свою роботу, що вони не ходять на зустрічі чи спізнюються, або ж що щоденний скрам триває довше, ніж потрібно, — обговоріть ці проблеми зі скрам-майстром і командою розробки на наступній ретроспективі спринту. Та не беріть на себе обов’язків скрам-майстра.
Пам’ятайте: ваша робота — керувати продуктом, а не командою чи процесом. Якщо у вас немає скрам-майстра, він недоступний чи недостатньо кваліфікований, врахуйте, що це блок на шляху до створення успішного продукту. Спробуйте вирішити проблему — найміть нового скрам-майстра чи допоможіть розвинутися діючому.
Перекладено й адаптовано командою BrainRain за матеріалами статті Романа Піхлера від 20 червня 2017 року.
