Ролі у SCRUM: Епізод ІІ. Повернення Scrum Master’а

Автор: Олександра Скібіна, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic Ukraine

Автор: Андрій Кульшан, Business Analyst, Product Owner, Consultant, GlobalLogic Ukraine

На зв’язку знову Олександра Скібіна та Андрій Кульшан і ми продовжуємо розбирати ролі, які бувають в SCRUM команді!
У цій колонці ми розберемося, хто ж такі стейкхолдери, dev команди і scrum-майстра. А для самих допитливих читачів – з’ясуємо, в чому ж ключова функція менеджера.
Поїхали!
Якщо ви пропустили перший Епізод, де ми розглядали роль Product Owner та бізнес-аналітика, то він прямо за посиланням.

Stakeholders

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

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

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

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

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

Як зрозуміти, з ким як працювати?

Почати можна з матриці “Вплив / Зацікавленість“. Вона допоможе визначити, куди віднести ту чи іншу групу стейкхолдерів, і як організувати процес взаємодії з ними.

• Manage Closely – в правий верхній квадрант потрапляють стейкхолдери, які мають великий вплив і найбільше зацікавлені в продукті. З цією групою стейкхолдерів потрібно працювати в першу чергу.
• Keep Satisfied – в лівий верхній квадрант потрапляють ті, хто не особливо зацікавлений в продукті, але мають великий вплив. Це можуть бути ті ж зовнішні регулятори, або голови юридичних відділів. Потрібно стежити, щоб вони не засмучувалися, додаючи необхідний функціонал в продукт.
• Keep Informed – стейкхолдери, які дуже зацікавлені в продукті – у них зазвичай багато ідей, але при цьому вплив у них на проєкт невелике. Ображати їх не треба, тому ми їх інформуємо.
• Monitor – є люди, які не зацікавлені й впливу ніякого на проєкт не мають. Проте, треба іноді на них поглядати, раптом вони перейдуть в якусь з інших груп, або висловлять ідеї, які виявляться корисними.

Тепер розгляньмо Dev команду більш детально

DEV team

Dev команда – це система, що самоорганізується. Команда від трьох до семи осіб, яка має можливість приймати рішення самостійно. Ніхто не може сказати команді розробників, яку кількість завдань вони повинні робити протягом ітерації. Scrum майстер і Product Owner можуть давати свої рекомендації, але саме Dev команда повинна приймати фінальне рішення про те, яку кількість роботи вони зроблять.

Команда повинна бути крос-функціональна. Це означає, що всередині команди повинні бути всі ресурси, які необхідні для виконання потрібної роботи в спринті. Якщо потрібен сторонній фахівець, такий як UX дизайнера або DevOps, то завдання Product Owner – заздалегідь подбати про його притягнення. Потрібно все спланувати таким чином, щоб на момент старту спринту мінімізувати кількість зовнішніх залежностей.

Ще один важливий пункт – Scrum не визнає ніяких титулів всередині команди. Думка кожного члена команди важливо і кожна людина може вплинути, при оцінюванні історій. І ще! Ми не створюємо підкоманду всередині команд – вся scrum команда являє собою єдиний підрозділ.

Scrum Майстер

Придивімося до ролі scrum майстра.  Можна виділити 5 основних його завданнь.

1. Основна задача – це служити команді. Якщо на шляху команди виникає будь-яка перешкода – завдання Scrum майстра його усунути.
2. Фасилітація. Він фасилітує більшість мітингів: планування спринту, стендап, ретроспективи, демо мітинги.
3. Scrum майстер повинен займатися навчанням своєї команди. Тобто навчати учасників команди взаємодії один з одним і з представниками бізнесу, оптимізувати процеси, підвищувати їх ефективність, а також пояснювати які цілі стоять перед командою в поточному спринті, і які очікування є з боку клієнтів.
4. Scrum майстер повинен взаємодіяти не тільки зі своєю командою, а й повинен працювати зі стейкхолдерами. В його обов’язки входить навчати стейкхолдерів як їм краще взаємодіяти з командою. Які процеси прийняті на проєкт і яким чином потрібно співпрацювати з командою.
5. Scrum майстер постійно вдосконалює свої знання в області Agile та фасилітації. Він використовує всі можливості для поліпшення поточного процесу.

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

Роль менеджера

А хіба у Scrum передбачено роль менеджера? Нумо з’ясуймо.

У SCRUM проєктах ми рухаємося від традиційного погляду на менеджера як керівника проєкту в напрямку servant-leader позиції. Таким чином завдання менеджера – забезпечити всі необхідні умови для створення високоякісних продуктів і сформувати культуру проєкту. Він повинен допомагати команді й Scrum майстру усунути перешкоди та поліпшити процеси.

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

Менеджер повинен розуміти, що відбувається в командах, проводити регулярні мітинги зі Scrum майстрами й Product Owner, розбиратися в питаннях розробки. Досить часто менеджер грає одну з Scrum ролей.

Менеджер може грати роль Product Owner на проєкті, але на наш погляд, краще менеджеру бути Scrum майстром. Зараз ми аргументуємо чому.

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

На наш погляд, краще обрати роль Scrum майстра. Що це дасть:

• Знання домену та процесу розробки.
• Розуміння зони відповідальності команди.
• Знайомство з командою, розуміння статус кожної людини – яка його роль.
• Можливість швидко долати перешкоди.

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

Підбиймо підсумки. У цій колонці ми розглянули:

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

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

Хай буде з вами SCRUM!