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

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

Це боляче і цього варто уникати. Тому ми підготували для вас переклад цінного гіда з інтерв’ю скрам-майстрів. Автор — Стефан Уолперс, організація Age of Product.

Станом на початок весни 2024 року за два роки існування ця електронна книга отримала більше 25 тисяч завантажень.

Вступ

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

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

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

• Візія, стратегія, гіпотеза
• Валідація й експерименти
• Середньострокове планування від 2 до 6 місяців
• Короткострокове планування від 4 до 8 тижнів
• Близькострокове планування від 2 до 4 тижнів
• Створення продукту
• Доставка продукту

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

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

Інструкція до використання

• Оберіть 2–3 питання з кожної категорії
• Обговорення цих питань достатньо для 60-хвилинного інтерв’ю зі скрам-майстром
• Кожне питання містить набір коректних відповідей, що допоможуть вам оцінити кандидата

Дисклеймер

• Відповіді є суб’єктивним баченням автора і не обов’язково робочі для вашої організації: що працює в організації А, може не працювати в організації Б
• Жодні питання з кількома варіантами відповідей не можуть бути релевантними для ідентифікації того, що ми називаємо гнучким способом мислення, адже гнучкість — надто складне для цього поняття
• Погляд автора на ці питання холістичний: аджайл — це відкриття продукту (що розробляти) плюс доставка продукту (як це робити) як спільна задача усієї скрам-команди

Набір №1: роль скрам-майстра

1. Аджайл-маніфест стверджує, що люди важливіші за процеси. Поясніть тоді, чому кажуть, що роль скрам-майстра повинна “підсилити процес”?

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

Прийнятні відповіді повинні наголошувати на фасилітації та підтримці. Наприклад:

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

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

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

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

• Доставлені продукти мають вищий коефіцієнт повернення користувачів (retention rate), кращу конверсію, зростання LTV й інші вдосконалені бізнес-метрики. Простіше кажучи, успішна скрам-команда збільшує ROI для бізнесу.
• Покращена гнучкість організації дозволяє краще реагувати на можливості ринку, які раніше ігнорувалися.
• Зменшилося марнування часу, грошей і інтелектуальних ресурсів на малоцінні продукти.
• Зменшився проміжок часу від валідації ідеї до доставки продукту.
• Зменшився цикл валідації гіпотез, пришвидшився процес відкриття продукту.
• Команда стала щасливішою: зменшився відтік фахівців і зросла кількість рефералів.
• Зростає конкурентність у війні за таланти: більше досвідчених людей хочуть приєднатися до організації.
• Зростає якість ПЗ: зменшується технічний борг, кількість багів і час, витрачений на обслуговування.
• Скрам-команди користуються більшою повагою стейкхолдерів.
• Стейкхолдери все частіше беруть участь у подіях, наприклад, рев’ю спринту.

3. Чи слід скрам-майстру усувати перешкоди для своєї скрам-команди?

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

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

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

4. Як скрам-майстер має комунікувати із власником продукту?

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

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

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

5. Чи потрібно залучати скрам-команду до процесу відкриття продукту і якщо так, то як саме?

Так, якнайраніше, і ось чому:

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

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

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

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

Це питання стосується попереднього. Знову ж, кандидат має сфокусуватися на поясненні, чому раннє залучення скрам-команди до процесу відкриття продукту — на користь і власнику продукту, і всій організації.

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

7. Як ви забезпечуєте доступ скрам-команди до стейкхолдерів?

Відповідаючи на це питання, кандидат має пояснити, що це непросто.

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

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

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

Скрам-майстер може використовувати різні тактики.

• В першу чергу, він має жити і дихати принципами Скрам Гайду і Аджайл-маніфесту. Ці принципи потрібно розповідати кожному залученому до розробки продукту —і робити це прозоро.
• Продуктові і інженерні команди можуть надати стейкхолдерам докази того, як скрам сильно скорочує проміжок часу між ідеєю і запуском продукту.
• Також вони можуть показувати, як скрам знижує ризики (наприклад, у формі прогнозу, коли ми встигнемо підготувати нову фічу), таким чином покращуючи успішність і інших відділів з точки зору планування і виконання задач.
• Скрам-команда може працювати прозоро й активно залучати зацікавлені сторони, запрошуючи їх на огляди спринтів та інші події. Тут вона розповість про свою діяльність, прогрес, а також про свою потребу у відвертому зворотному зв’язку від стейкхолдерів.
• Навчання всіх, особливо стейкхолдерів, — це дуже важливо. Можна організовувати для них спеціальні воркшопи з внутрішніми фахівцями і запрошеними коучами.

9. Як би ви “продали” Scrum топам?

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

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

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

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

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

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

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

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

Набір №2: уточнення й оцінка продуктового беклогу

11. Продакт оунер вашої скрам-команди часто перетворює документи з вимогами, отримані від стейкхолдерів, у тікети і просить вас їх оцінювати. Що ви про це думаєте?

Продакт оунер так робити не повинен, а скрам-майстер не повинен це приймати. Це по суті каскадний процес, прихований під личиною псевдо-гнучкості.

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

12. Яку свіжу інформацію щодо ситуації з продуктом та ринком ви б хотіли отримати від продакт оунера, щоб розповісти своїй команді?

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

Чудово буде, якщо кандидат запропонує залучити скрам-команду до збору якісних даних через участь у інтерв’ю.

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

13. Хто має писати юзер сторіс?

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

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

14. Як виглядає хороша історія користувача? Яка її структура?

Гарна юзер сторі:

• включає опис
• має описані критерії прийняття
• може бути доставлена в межах спринту
• підготовлена з точки зору UI (дизайн, контент)
• має визначені залежності
• має визначені критерії продуктивності
• має визначені критерії відстеження
• оцінена скрам-командою

15. Що означає акронім INVEST?

• Independent (незалежна). Історія користувача має бути самостійною, не маючи залежностей на інших історіях.
• Negotiable (дискусивна). Доки сторі не стала частиною ітерації, її завжди можна змінити чи переписати.
• Valuable (цінна). Юзер сторі має нести цінність для кінцевого користувача.
• Estimable (оцінювана). Розмір сторі має бути можливо оцінити.
• Small (мала). Історії користувачів мають бути не надто великими, щоб їх було можливо планувати, розділити на задачі і пріоритизувати з певною долею впевненості.
• Testable (доступна для тестування). Історія (або опис, що її стосується) має містити інформацію, необхідну для тестувальників.

16. Чому юзер сторіс не оцінюють в людиногодинах?

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

Оцінювання буває досить непростим, коли:

• Команда працює з застарілим програмним забезпеченням
• Має великий технічний борг
• Або складається з джунів

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

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

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

17. Власник продукту вашої скрам-команди любить закидати найрізноманітніші ідеї в продуктовий беклог, щоб не забути пропрацювати їх пізніше. З часом там накопичилося біля 200 елементів на різних етапах роботи. Що ви про це думаєте? Чи може скрам-команда працювати над 200 елементами продуктового беклогу?

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

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

Набір №3: планування спринту

18. Як ви організовуєте планування спринту?

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

Один зі способів організації планування може бути таким:

1. Власник продукту представляє бізнес-ціль для нового спринту. (Зі Скрам Гайду: “Власник продукту пропонує, як продукт може збільшити свою цінність і корисність у цьому Спринті.”)
2. Уся скрам-команда створює відповідну Ціль спринту.
3. Розробники зобов’язуються виконати Ціль спринту.
4. Більше того, вони виявляють важливі робочі елементи продуктового беклогу для досягнення Цілі спринту. Або створюють нові.
5. Ймовірно, розробники також уточнюють робочі елементи, якщо це потрібно, і планують їх реалізацію.
6. Ми вважаємо беклогом спринту набір, що складається з Цілі спринту, обраних елементів продуктового беклогу та плану їхньої доставки.

19. Які фактори має враховувати скрам-команда на плануванні спринту, визначаючи досяжну Ціль спринту?

Типові критерії, які має враховувати скрам-команда, це:

• Хто буде присутнім під час Спринту; хто з команди хворіє або у відпустці?
• Коли люди покидають команду, передача знань відбувається в останній момент? Чи нові люди, що приєднуються до команди, потребують складного онбордингу?
• Чи будуть якісь державні вихідні під час Спринту?
• Чи всі необхідні інструменти в нас є і чи вміємо ми ними користуватися?
• Чи знайомі ми з частиною роботи, над якою працюємо? Чи збираємося знайомитися в процесі?
• Чи є у нас залежності з іншими командами?
• На якому рівні нам потрібно погасити технічний борг?
• Яка продуктивність скрам-команди була в минулому Спринті?

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

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

20. Чи нормально, якщо Власник продукту додає в Спринт список випадкових завдань?

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

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

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

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

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

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

22. За допомогою яких метрик можна оцінити цінність юзер сторі?

Для оцінки цінності історії користувача або для визначення, чи варто в неї інвестувати, можна використовувати як кількісні, так і якісні показники. Це можуть бути:

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

23. Як сприяти вибору історій користувачів так, щоб обиралися найцінніші, і при цьому не порушити право Команди розробки обирати завдання для Спринту?

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

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

24. Скільки часу Команда розробки повинна виділяти під час звичайного Спринту на рефакторинг, виправлення важливих помилок та дослідження нових технологій або ідей?

Окрім Спринтів, під час яких необхідно вирішувати критичні та термінові завдання (наприклад, виправлення проблеми, яка вивела сайт з ладу), хорошим правилом є виділення 15-10-5 відсотків від загальної робочої потужності скрам-команди на наступні завдання:

• 15% на технічний борг та рефакторинг,
• 10% на виправлення помилок,
• 5% на дослідницькі завдання.

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

25. Чи повинен Власник продукту призначати історії користувачів або зобов’язувати до певних задач окремих членів Команди розробки?

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

26. Як боротися з вибірковістю задач членами команди?

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

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

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

27. Чи можна використовувати Визначення готового?

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

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

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

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

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

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

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

29. Якщо член скрам-команди не хоче брати участь у плануванні Спринту і вважає ці зустрічі марнуванням часу, як ви з цим справляєтеся?

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

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

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

Такі ситуації підкреслюють, що Scrum підходить не для всіх.

30. Чи корисно для розробників планувати всю роботу на весь Спринт під час планування Спринту?

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

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

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

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

32. Чи повинен скрам-майстер турбуватися про коефіцієнт використання розробників?

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

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

Це питання дає можливість кандидату заглибитися у загальні відмінності між індустріальною парадигмою та гнучкою розробкою продуктів.

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

• Набір №4: дейлі скрам;
• Набір №5: рев’ю спринту;
• Набір №6: ретроспектива.