Найняти Скрам-майстра: 83 перевірені питання для співбесіди, частина 3 з 4

Набір №7: гнучкі метрики

52. Якщо ваша скрам-команда постійно не виконує свої зобов’язання, а її швидкість роботи нестабільна, через що це може бути? Як ви вирішуватимете цю проблему?

Якщо скрам-команда демонструє нестабільну швидкість і постійно не виконує свої прогнози, це може свідчити про те, що швидкість використовується як основний показник для вимірювання прогресу команди.

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

Є й інші фактори, які роблять швидкість скрам-команди нестабільною:

• Нові члени команди
• Втрата досвідчених членів команди
• Робота на невідомій території
• Робота з застарілим кодом, тим паче недокументованим
• Поява несподіваного технічного боргу
• Відпустки й лікарняні
• Втручання керівництва, яке змінює обсяг задач у спринті
• Вирішення непередбачених високопріоритетних помилок

Ще однією поширеною причиною того, що скрам-команда постійно не виконує власні прогнози, є те, що елементи беклогу продукту погано підготовлені, що робить завдання важкими для оцінки командою. Або ж проєкти, що надаються команді, можуть мати погано задокументований застарілий код, надмірний технічний борг, занадто багато багів і погано написаного коду. Усе це робить оцінку завдань ризикованою.

Ваш кандидат не повинен погоджуватися з хибною думкою, що прийняття скраму командою працює лише тому, що прогнози і швидкість команди співпадають.

Щоб вирішити такі проблеми з командою, можна зробити наступне:

1. Аналіз ситуації: Проведіть ретроспективу, щоб виявити основні причини нестабільності швидкості та невиконання зобов’язань.
2. Покращення підготовки беклогу: Працюйте над покращенням процесу уточнення беклогу продукту, щоб забезпечити більш точну оцінку завдань.
3. Вирішення технічних проблем: Виявляйте та вирішуйте проблеми з технічним боргом, застарілим кодом і багами.
4. Зміцнення команди: Працюйте над інтеграцією нових членів команди та збереженням досвідчених членів.
5. Підтримка з боку керівництва: Забезпечте, щоб втручання керівництва не порушувало роботу спринтів і не змінювало їх обсяг.

Постійно вдосконалюйте процеси і підтримуйте відкритий діалог з командою, щоб забезпечити стабільність і ефективність роботи.

53. Які ефективні гнучкі метрики ви використовували?

Це питання стимулює кандидата поділитися уроками, отриманими від успішного застосування метрик для допомоги скрам-команді в її безперервному вдосконаленні.

Правила застосування гнучких метрик

1. Відстежуйте тільки ті метрики, які стосуються команди. Ігноруйте метрики, які вимірюють індивідуальну продуктивність.
2. Не вимірюйте показники лише тому, що їх легко виміряти. Це часто стає наслідком використання різних аджайл-інструментів, які будують готові звіти.
3. Записуйте контекст разом з даними. Дані без контексту, такі як кількість доступних членів команди або інтенсивність інцидентів під час спринту, можуть виявитися не більше, ніж інформаційним шумом.

Приклади гнучких метрик

• Час виконання задачі (Lead time)
• Час циклу (Cycle time)
• Кількість дефектів, що потрапили в реліз
• Співвідношення ремонтних робіт зі створенням нової цінності

Хороші кандидати мають знати концепцію менеджменту на основі доказів (evidence-based management).

Як застосовувати ці метрики

1. Час виконання завдання (Lead time): Це час від моменту отримання задачі до її завершення. Вимірювання часу виконання задачі допомагає оцінити загальну продуктивність команди і визначити вузькі місця в процесі.
2. Час циклу (Cycle time): Це час від початку роботи над задачею до її завершення. Цей показник допомагає команді зрозуміти, скільки часу потрібно для виконання конкретних типів задач і де можна зробити процес більш ефективним.
3. Кількість дефектів, що потрапили в реліз: Ця метрика допомагає оцінити якість роботи команди. Велика кількість дефектів може свідчити про необхідність покращення процесів тестування та забезпечення якості.
4. Співвідношення ремонтних робіт зі створенням нової цінності: Ця метрика показує, скільки часу команда витрачає на виправлення помилок порівняно з часом на створення нових функцій. Високе співвідношення може свідчити про технічний борг або проблеми з якістю коду.

Використання цих метрик допомагає скрам-команді постійно вдосконалювати свої процеси та досягати кращих результатів.

54. Які якісні гнучкі метрики варто потрібне відстежувати?

Мета якісних метрик — отримати уявлення про те, як одна або кілька скрам-команд в організації просуваються у впровадженні гнучких методологій.

Приклади якісних метрик

1. Тести самооцінки: Існує кілька тестів самооцінки, які скрам-команда може регулярно проводити для збору метрик. Прикладом може бути чекліст Scrum від Гендріка Кніберга. Інтервал для проведення таких тестів становить 4–12 тижнів, причому як правило, команди з меншою довірою до скраму проводять тести частіше. Окремі значення, зафіксовані цими тестами, не надто важливі. Важливо відстежувати тренд з часом. Для візуалізації цих трендів скрам-майстер повинен агрегувати результати — у випадку з чеклістом Гендріка Кніберга можна створити карту практик гнучких методологій.
2. Опитування думок: Щоб забезпечити участь більш інтровертних членів команди, найкраще проводити анонімні опитування думок. Питання для таких опитувань можуть включати:

• Яку цінність команда доставила в останньому спринті?
• Чи зросла, а чи зменшилася кількість технічного боргу під час останнього спринту?
• Чи задоволені ви співпрацею з колегами?
• Чи порадили б ви свого роботодавця (або клієнта) другу, який шукає нову роботу?

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

Підтримка принципів Agile

Ваш кандидат повинен підтримувати Маніфест Agile і його принцип прозорості: всі метрики повинні бути доступні всім членам скрам-команди, а також значною мірою тим, хто працює з доставкою продуктів.

Приклади використання якісних метрик

1. Підвищення прозорості: Відстеження таких метрик підвищує прозорість процесів і допомагає командам бачити свої досягнення і області для покращення.
2. Відстеження задоволеності команди: Збір метрик про задоволеність членів команди допомагає вчасно виявляти проблеми і працювати над їх вирішенням.
3. Поліпшення комунікації: Якісні метрики сприяють відкритому обговоренню та поліпшенню комунікації в команді.

Відстеження якісних метрик допомагає Scrum-командам постійно вдосконалювати свої процеси та досягати кращих результатів.

55. Як підготуватися до переходу на Scrum?

Якщо не знаєш, куди йдеш, будь-яка дорога приведе тебе туди. Ваш кандидат повинен розуміти, що перехід на agile повинен мати чітку мету і ціль, а це означає планування заздалегідь.

Підготовка до переходу на Scrum

1. Прослуховування та спостереження: Перший крок — це інтерв’ювання якомога більшої кількості членів команди та стейкхолдерів ще до початку переходу. Ці інтерв’ю повинні включати всіх, незалежно від їхньої ролі — розробників, спеціалістів з контролю якості, дизайнерів UX/UI, менеджерів продукту — для виявлення основних причин поточних проблем, невдач і дисфункцій в організації. Об’єднання цих патернів з найважливішими технічними та бізнес-проблемами допоможе визначити основні цілі для перших скрам-команд. Ця фаза спостереження, під час якої скрам-майстер проводить інтерв’ю, зазвичай займає від чотирьох до дванадцяти тижнів, залежно від розміру та структури організації.
2. Навчання членів команди та стейкхолдерів: Навчання майбутніх членів команд та стейкхолдерів повинно початися і проходити паралельно з інтерв’ю. Це допоможе забезпечити, щоб всі були готові до переходу на скрам і розуміли його основи.
3. Створення перших скрам-команд: Наступним кроком є створення перших скрам-команд з існуючих інженерних і продуктових відділів. Важливо сформувати ці команди так, щоб вони мали необхідні навички та знання для успішної роботи в рамках Scrum.

План переходу та вирішення проблем

Ваш кандидат повинен вміти накреслити приблизний план переходу і вирішувати поширені проблеми, які можуть виникнути під час запуску. Ось декілька ключових моментів:

• Визначення мети та цілей: Встановлення чітких цілей і очікувань від переходу на Scrum.
• Комунікація: Забезпечення відкритої та прозорої комунікації між усіма зацікавленими сторонами.
• Підтримка керівництва: Забезпечення підтримки та залучення вищого керівництва для успішного переходу.
• Навчання та коучинг: Регулярне навчання та підтримка команд на кожному етапі переходу.
• Аналіз та коригування: Постійний аналіз процесу переходу та внесення необхідних коригувань для досягнення успіху.

Розробка та впровадження плану переходу

1. Початковий аналіз: Визначення поточного стану команди та організації, включаючи сильні та слабкі сторони.
2. Визначення ключових етапів: Розробка поетапного плану впровадження скраму, включаючи навчання, формування команд, проведення перших спринтів та регулярних ретроспектив.
3. Моніторинг прогресу: Встановлення метрик для відстеження прогресу та забезпечення успішного переходу на скрам.
4. Безперервне вдосконалення: Постійний аналіз результатів і вдосконалення процесів на основі зворотного зв’язку від команд та стейкхолдерів.

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

56. Як створити першу скрам-команду?

Вибір учасників

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

Кік-офф

Кандидати на роль скрам-майстра повинні бути достатньо розумними, щоб запропонувати запросити кожного члена команди розробки продукту, а також виконавчих керівників, які спонсорують перехід, на кік-офф. Метою кік-офф є підтримка членів інженерних і продуктових команд у тому, як вони обирають самостійно організуватися в перші крос-функціональні скрам-команди. Кік-офф може тривати від кількох годин до кількох днів, залежно від обставин конкретної організації.

Самоорганізація команд

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

Подальші кроки

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

План дій

• 1 Підготовка кік-офф:

• Визначте мету та цілі переходу.
• Запросіть всіх зацікавлених осіб та членів команди на зустріч.

• 2 Проведення кік-офф:

• Ознайомте учасників з основами скраму.
• Поясніть важливість самоорганізації.
• Дайте командам можливість самостійно організуватися.

• 3 Початкове навчання:

• Проведіть воркшопи з основ скраму.
• Навчіть команди уточненню беклогу продукту, написанню користувацьких історій, оцінці задач і створенню дошок.

• 4 Підтримка та моніторинг:

• Надавайте постійну підтримку та коучинг новим командам.
• Відстежуйте прогрес і вносьте необхідні корективи.

Перехід на Scrum потребує ретельного планування та підготовки, але з правильним підходом та підтримкою він може принести організації успіх.

57. Що ви рекомендуєте новоствореній скрам-команді робити в першу чергу?

Робота з існуючим беклогом продукту

Першим критичним завданням для більшості новостворених скрам-команд є робота з існуючим беклогом продукту. Відповіді на це питання не повинні згадувати етапи розвитку команди за Такманом, додаткові вправи з командоутворення або будь-яке інше навчання скраму, не пов’язане з беклогом продукту.

Чому це важливо?

Зазвичай скрам-майстер не починає з абсолютно новою командою і без існуючого продукту — ще рідше це трапляється в молодих організаціях і стартапах. Найчастіше на аджайл переходить існуюча організація з уже наявними продуктами і послугами. Для таких випадків кандидат повинен зазначити, що уточнення існуючого беклогу продукту є першим практичним кроком.

Беклог продукту як артефакт

Існуючий беклог продукту — це сам по собі цікавий артефакт, оскільки він надає всебічне уявлення про історію організації з доставки продукту. Цей конкретний беклог продукту дозволяє виявити організаційний борг, недоліки процесів, сумнівні рішення щодо продукту та інші антипатерни.

Виявлення антипатернів

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

Проведення воркшопів з уточнення беклогу продукту

Кандидат має згадати, що воркшопи з уточнення беклогу продукту створюють гарну можливість навчити скраму нову скрам-команду і власника продукту. Це тому, що такий майстер-клас зазвичай охоплює створення користувацьких історій, передачу знань між членами команди, процес оцінки (якщо це застосовно), вступ до гнучких метрик, аналіз технічного боргу та інші теми, критично важливі для успіху скраму.

Кроки для роботи з беклогом продукту

1. Аналіз існуючого беклогу продукту: Оцініть поточний стан беклогу, визначте застарілі, дубльовані та нерелевантні елементи.
2. Очищення беклогу: Видаліть або об’єднайте елементи, які більше не мають цінності або є нерелевантними.
3. Пріоритизація: Спільно з власником продукту визначте пріоритети для елементів беклогу, що залишилися, відповідно до їх важливості для бізнесу.
4. Уточнення користувацьких історій: Перепишіть або уточніть користувацькі історії, щоб вони були чіткими, конкретними та зрозумілими для команди.
5. Оцінка: Виконайте оцінку наявних елементів беклогу за допомогою покеру планування чи інших методів.
6. Регулярне уточнення: Встановіть регулярні сесії з уточнення беклогу, щоб підтримувати його в актуальному стані.

Ці кроки допоможуть новоствореній скрам-команді ефективно працювати з беклогом продукту і забезпечити успішний перехід на Scrum.

Набір №9. Антипатерни скраму

58. Які антипатерни може “зловити” скрам-майстер під час спринту?

Типові антипатерни скрам-майстра

Будь-яка з цих поведінкових моделей завадить продуктивності команди. Обов’язок скрам-майстра — запобігти їх появі. Ось деякі антипатерни:

• 1 Утримання команди в залежності:

Скрам-майстер надто піклується про команду, тримаючи її в залежності від його або її допомоги: організація зустрічей, покупка стікерів і маркерів, ведення записів, оновлення Jira тощо. Ще гірше, коли скрам-майстер вирішує тримати команду в темряві щодо принципів і практик, щоб захистити своє місце роботи.

• 2 Переривання потоку:

Скрам-майстер дозволяє стейкхолдерам порушувати робочий процес команди розробки під час спринту. Існує кілька способів, як стейкхолдери можуть порушити потік роботи команди під час спринту:
– Скрам-майстер веде політику невтручання щодо питань доступу стейкхолдерів до команди розробки.
– Скрам-майстер не заперечує, коли керівництво запрошує інженерів на випадкові зустрічі як експертів з предметної області.
– Скрам-майстер дозволяє стейкхолдерам або керівникам перетворювати щоденні зустрічі (Daily Scrum) на звітні сесії.

• 3 Відсутність підтримки:

Скрам-майстер не підтримує членів команди, які потребують допомоги з задачами. Команди розробки найчастіше формують такі задачі, які інженер може завершити протягом дня. Однак, якщо хтось стикається з проблемами протягом більше ніж двох днів і не говорить про необхідність підтримки, скрам-майстер має вирішити це питання. Важливо, саме тому задачі на фізичній дошці позначаються червоними точками, якщо вони не були переміщені в наступну колонку протягом дня.

• 4 Ігнорування мікроменеджменту:

Скрам-майстер не перешкоджає продакту — або будь-кому іншому — призначати задачі інженерам. Команда розробки зазвичай організовується самостійно без зовнішнього втручання. І скрам-майстер повинен діяти як щит команди в цьому відношенні.

• 5 Фокусування на гармонії в команді:

Скрам-майстер замітає конфлікти і проблеми під килим, не використовуючи ретроспективи спринту для їх відкритого обговорення. Ця поведінка часто є ознакою підпорядкування політиці і використання маніпуляцій для виконання організаційних вимог, що суперечать цінностям і принципам скраму. Якщо організація цінує своїх підлеглих за дотримання правил замість того, щоб говорити правду, навіщо взагалі проводити ретроспективи? Скрам-майстер, який бере участь у карго-культі Scrum, є скоріше наглядачем, ніж гнучким практиком.

Запобігання антипатернам

Для запобігання цим антипатернам скрам-майстер повинен:

1. Заохочувати самостійність команди: Забезпечити знання та інструменти для самостійної роботи і прийняття рішень.
2. Захищати робочий процес команди: Забезпечити, щоб стейкхолдери та керівництво не переривали роботу команди під час спринту.
3. Підтримувати відкриту комунікацію: Регулярно спілкуватися з командою і забезпечувати підтримку в вирішенні проблем.
4. Запобігати мікроменеджменту: Забезпечити свободу команди організовувати свою роботу без зовнішнього втручання.
5. Відкрито обговорювати проблеми: Використовувати ретроспективи для відкритого обговорення конфліктів і проблем і працювати над їх вирішенням у відповідності з цінностями та принципами скраму.

59. Які антипатерни, пов’язані з беклогом продукту, повинен контролювати скрам-майстер?

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

Ключові принципи Scrum

Згідно зі Scrum Guide, скрам-майстер підтримує Власника продукту багатьма способами, щоб забезпечити високий рівень опанування скраму:

• Допомагає знаходити методи для ефективного визначення цілей продукту та управління беклогом продукту
• Допомагає скрам-команді розуміти необхідність чітких і коротких елементів беклогу продукту
• Допомагає побудувати емпіричне планування продукту для складного середовища
• Сприяє співпраці зі стейкхолдерами за запитом або необхідністю

Типові антипатерни, пов’язані з беклогом продукту

1. Пріоритизація за дорученням: Один стейкхолдер або їх комітет пріоритизує беклог продукту. Власник продукту – єдина особа, яка вирішує, які завдання стають елементами беклогу продукту і в якому порядку вони будуть виконані. Відсутність цієї автономії перетворює скрам у жорсткий водоспадний процес 2.0.
2. Повний беклог заздалегідь: Скрам-команда створює беклог продукту, що охоплює весь проєкт або продукт наперед, оскільки обсяг релізу обмежений. Як можна сьогодні точно знати, що саме потрібно буде доставити через шість місяців?
3. Перевантажений беклог: Беклог продукту містить більше елементів, ніж скрам-команда може доставити протягом трьох-п’яти спринтів. Це створює надлишок, який може ніколи не бути реалізованим.
4. Сховище ідей: Власник продукту використовує беклог продукту як сховище ідей і вимог. Це може призвести до перевантаження беклогу, когнітивного перевантаження і ускладнити узгодження з великим планом на рівні управління портфелем і планування дорожньої карти.
5. Копіпаст вимог: Власник продукту створює елементи беклогу продукту, розбиваючи отримані від стейкхолдерів вимоги на менші частини. Це своєрідна monkey job (чорна робота) для власника продукту. Створення елементів беклогу продукту має відбуватися через колективні зусилля команди.
6. Ігнорування команди: Власник продукту не залучає всю скрам-команду до процесу уточнення, покладаючись лише на “провідного інженера” або іншого члена команди.
7. Слухняна команда: Розробники покірно виконують вимоги Власника продукту, не ставлячи під сумнів ефективність підбору задач стосовно якісного використання часу команди з точки зору доставленої цінності.
8. Недостатньо часу на уточнення: Скрам-команда не проводить достатньо сесій з уточнення, що призводить до низької якості беклогу продукту. Scrum Guide рекомендує постійно приділяти достатньо часу уточненню беклогу продукту.
9. Занадто багато часу на уточнення: Скрам-команда проводить занадто багато сесій з уточнення, що призводить до надто детального беклогу продукту. Надмірне уточнення також не є корисним, оскільки може призвести до марнування ресурсів.

60. Які антипатерни, пов’язані з плануванням спринту, має контролювати скрам-майстер?

Планування спринту відіграє вирішальну роль у процесі створення цінності скрам-командою. Згідно зі Scrum Guide:

Ключові принципи планування спринту

• Початок спринту: Планування Спринту (Sprint Planning) ініціює Спринт, та визначає саме ту роботу, яку слід виконати за цей Спринт.
• Спільне планування: У результаті ми отримуємо план, до створення якого була залучена вся Скрам Команда.
• Підготовка до обговорення: Власник Продукту (Product Owner) повинен переконатись, що учасники готові обговорити найважливіші елементи Беклогу Продукту та визначити чи ці елементи відповідають Цілі Продукту (Product Goal).
• Цінність спринту: Власник Продукту пропонує варіанти того, як продукт може збільшити свою цінність та користь у поточному Спринті.
• Цілі спринту: Потім вся Скрам Команда визначає таку Ціль Спринту, яка показує чому Спринт цінний для зацікавлених осіб.
• Завершення планування: Ціль Спринту повинна бути опрацьована до закінчення Планування Спринту.

Типові антипатерни, пов’язані з плануванням спринту

• 1 Що ми захищаємо:

Власник продукту не може узгодити бізнес-ціль майбутнього спринту з загальною візією продукту. Серйозна бізнес-ціль відповідає на питання “Що ми захищаємо?”. Хороша ціль, що випливає з цієї узгодженості, є сфокусованою та вимірюваною.

• 2 Відсутність бізнес-цілі, відсутність цілі спринту:

Власник продукту пропонує елементи беклогу продукту, що нагадують випадковий набір завдань, без будь-якої зв’язності. Відсутність цілі спринту може свідчити про слабкість Власника продукту або неправильну пріоритизацію беклогу.

• 3 Незавершені задачі:

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

• 4 Зміни в останню хвилину:

Власник продукту намагається додати неготові елементи беклогу в останню хвилину. Якщо команда регулярно проводить сесії з уточнення беклогу продукту, це буде траплятися радше як виняток.

• 5 Фокус на виході:

<Власник продукту тисне на розробників, щоб вони взяли на себе більше задач, ніж реально можуть виконати, орієнтуючись на минулі показники команди, такі як швидкість. Це порушує принципи скраму і вимагає уваги скрам-майстра.

• 6 Відсутність підготовки:

Власник продукту не готує беклог продукту належним чином для вибору елементів командою розробки. Беклог продукту повинен завжди представляти найкраще можливе використання роботи розробників з точки зору цінності для клієнта.

Запобігання антипатернам

Щоб запобігти цим антипатернам, скрам-майстер повинен:

1. Забезпечити узгодженість бізнес-цілей: Власник продукту повинен мати чітке розуміння загальної візії продукту і бізнес-цілей кожного спринту.
2. Підтримувати узгодженість беклогу: Беклог продукту повинен бути компактним, чітким і постійно уточнюваним командними зусиллями.
3. Обговорювати незавершені задачі: Усі незавершені задачі з попереднього спринту потрібно обговорити, щоб переконатися, що вони досі у пріоритеті.
4. Уникати змін в останню хвилину: Власник продукту повинен працювати над тим, щоб мінімізувати зміни в останню хвилину і забезпечити готовність беклогу продукту до спринту.
5. Забезпечувати реалістичність планування: Команда повинна мати можливість самостійно обирати задачі для спринту, враховуючи свою реальну здатність їх виконати.
6. Готувати беклог продукту: Власник продукту повинен забезпечити готовність беклогу продукту до обговорення і вибору елементів командою розробки.

Правильне планування спринту є критично важливим для успішної роботи скрам-команди.

61. Яких антипатернів, пов’язаних з Оглядом Спринту, потрібно уникати в команді?

Згідно зі Scrum Guide, Огляд Спринту, або ж Рев’ю, – важлива подія для співпраці з внутрішніми і зовнішніми зацікавленими сторонами, що дозволяє переконатися, що скрам-команда рухається у правильному напрямку:

• Метою Рев’ю Спринту (Sprint Review) є перевірка результатів Спринту та визначення адаптацій в подальшій роботі.
• Скрам Команда представляє результати своєї роботи зацікавленим особам та обговорює прогрес по досягненню Цілі Продукту (Product Goal).
• Протягом наради Скрам Команда та зацікавлені особи переглядають, що було досягнуто у Спринті та що змінилося в їхньому середовищі. На основі цієї інформації всі присутні співпрацюють над тим, що робити далі.
• Беклог Продукту (Product Backlog) також можна скоригувати для того, щоб він відповідав новим можливостям.
• Рев’ю Спринту (Sprint Review) — це робоча сесія, тому Скрам Команда не повинна обмежувати себе лише презентацією виконаної роботи.

Джерело: Scrum Guide 2020

Ось деякі з найшкідливіших антипатернів Огляду Спринту:

• Усе заради плану: скрам-команда не використовує Огляд Спринту для обговорення поточного стану продукту або проєкту з зацікавленими сторонами.
• Смертельно нудний PowerPoint: Учасники втомлюються від презентацій. Основа успішного Огляду Спринту – “показуй, а не розповідай”, або навіть краще: нехай зацікавлені сторони тестують фічу самостійно.
• Оцінка Спринту: команда демонструє свої досягнення, але зацікавлені сторони не сприймають це з ентузіазмом. Порада: розкажіть цікаву історію на початку події, щоб залучити зацікавлених сторін. Пропускайте ті історії користувачів, які, ймовірно, не мають значення. Не потрібно перевантажувати стейкхолдерів розповідями про все-все зроблене. Ми не бухгалтери; наша звітність менш важлива порівняно з результатом для клієнта або створення цінності.
• Шахрайство: команда розробників показує незавершені елементи. Часом, звісно, бувають вагомі причини показувати незавершену роботу. Однак частково завершена робота порушує концепцію готового, один із перших принципів Scrum.
• Scrum а-ля Stage-Gate®: Огляд Спринту є своєрідним процесом схвалення Stage-Gate®, де зацікавлені сторони підписують затверджені фічі. Цей антипатерн типовий для організацій, які використовують гібрид гнучкості і каскадного підходу. Лише скрам-команда має вирішувати, що випускати і коли.
• Відсутність зацікавлених сторін: Зацікавлені сторони не відвідують Рев’ю Спринту. Наприклад, жоден з керівників найвищого рівня не бере участі в Огляді Спринту. Є кілька причин, чому зацікавлені сторони не беруть участь в Огляді Спринту:
  • вони не бачать жодної цінності у цій події;
  • рев’ю конфліктує з іншою важливою зустріччю;
  • вони не розуміють важливості Огляду Спринту.

  За моїм досвідом, вам потрібно “продавати” цю подію межах організації, принаймні на початку використання скраму.

• Відсутність клієнтів: Зовнішні стейкхолдери – також відомі як клієнти – не відвідують Огляд Спринту. Вийдіть з “ехо-камери” вашої організації і запросіть декілька платних користувачів на Рев’ю. Це буде корисно для всіх.
• Незаплановані задачі: Команда розробників працювала над задачами поза ціллю Спринту, і Власник Продукту дізнається про це вперше під час Огляду Спринту. Заради прозорості, відкритості та поваги: у Scrum немає місця для позапланових задач.

62. Які антипатерни проведення ретроспективи спринту ви знаєте?

Типові антипатерни ретроспективи спринту в Scrum:

1. Марнування часу: Команда не цінує ретроспективу. Якщо це так, то, швидше за все, проблема у самій ретроспективі. Вона завжди однакова, ритуалізована та нудна? Проведіть мета-ретроспективу про саму ретроспективу. Змініть місце проведення. Проведіть ретроспективу за келихом пива чи вина. Пам’ятайте, інтроверти також люблять брати участь у ретро.
2. Полонені: Деякі члени команди приходять на ретроспективу лише з примусу. Не тисніть на людей. Зробіть ретроспективу вартою їх часу. Бажання постійно вдосконалюватися як команда має бути народжене з внутрішньої мотивації, а не зі страху чи наказу. Порада: вправа Retromat “Чому ви тут?” – гарний початок для ретроспективи.
3. День бабака: Ретроспектива ніколи не змінюється: ні склад, ні місце проведення, ні тривалість. У такому разі команда знову і знову обговорює ті ж проблеми – це як День бабака без щасливого кінця.
4. Перенесення на наступний спринт: Команда відкладає ретроспективу на наступний спринт. Ретроспектива служить моментом завершення, допомагаючи всім налаштуватися на нові цілі спринту. Тому важливо проводити ретроспективу перед плануванням наступного спринту. Перенесення може порушити флоу команди і затримати впровадження можливих покращень на цілий спринт.
5. #NoDocumentation: Ніхто не веде записи для подальшого використання. Ретроспектива – це вагома інвестиція і її варто сприймати серйозно. Записи та фотографії підтримують процес.
6. Відсутність психологічної безпеки: Ретроспектива перетворюється на цикл звинувачень. Команда перемагає разом, команда програє разом. Гра в звинувачення свідчить як про провал скрам-майстра як фасилітатора, так і про відсутність зрілості та навичок комунікації в команді.
7. Булінг: Один або два члени команди домінують під час ретроспективи. Це часто ознака слабкого або байдужого скрам-майстра. Ретроспектива повинна бути безпечним місцем, де кожен – включаючи інтровертів – може висловитися без домінування чи залякування з боку інших. Невдача у створенні безпечного місця призведе до того, що учасники перестануть брати участь, і результати ретроспективи будуть марними. Головна відповідальність скрам-майстра – забезпечити можливість висловитися всім.
8. Участь зацікавлених сторін: Зацікавлені сторони беруть участь у ретроспективі. Для них є інші скрам-події: огляд спринту, уточнення беклогу продукту, щоденні зустрічі, а також можливості поспілкуватися за кавою або під час обіду. Ретроспектива спринту – закрита для зацікавлених сторін.
9. Пасивність: Члени команди присутні, але не беруть активної участі. Причин може бути багато: вони вважають ретроспективу марною, небезпечною або нудною. Можливо, вони бояться негативних наслідків або це група інтровертів. Якою б не була причина, швидкого вирішення, ймовірно, немає. Скрам-майстру потрібно визначити, який стиль ретроспективи найкраще підійде для їхньої організації.

63. Як ви як скрам-майстер можете визначити, у чому вам слід удосконалюватися?

Це просто: регулярно питайте у своєї команди та зацікавлених сторін, як ви можете стати кращим як скрам-майстер.

Чому б не провести ретроспективу спринту для себе? Виділена ретроспектива спринту набагато ефективніша, ніж витрачати п’ять хвилин наприкінці кожної регулярної ретроспективи команди на запитання про те, як ви можете вдосконалити себе.

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

У наступній частині ми розглянемо такі теми, як:

• Набір №10. Принципи й індикатори успішності скраму;
• Набір №11. Як зробити так, щоб скрам-майстра спіткала невдача;
• Набір №12. Створення цінності в ролі скрам-майстра.