Скрам без скрам-майстра: короткий посібник та 3 поради

Будемо чесними: багато організацій не можуть або не хочуть дозволити собі Scrum-майстра через пов’язані з цим фінансові обмеження. Але Scrum без Scrum-майстра - чи це взагалі можливо? Чи можна використовувати Scrum без Scrum-майстра?

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

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

Існує велика кількість переліків обов’язків та ролей скрам-майстра, але по суті можна сказати, що все зводиться до трьох речей (Читати далі: Ролі скрам-майстрів ).

Скрам-майстер відповідає за

• Модерація процесу Скраму (особливо церемоній Скраму, таких як щоденний стендап, огляд спринту, ретроспектива та планування спринту)
• Усунення перешкод і захист команди
• Постійне вдосконалення на шляху до самоорганізації команди 

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

І хто візьметься за них у команді, яка хоче використовувати фреймворк Скрам, але не має Скрам-майстра?

Ось короткий огляд того, як я бачу ситуацію.

Відповідальність	Скрам-команда	Класична команда	Скрам-команда без скрам-майстра
Модерація зустрічей	Scrum Master	Керівник команди	Керівник команди, деякі члени команди
Усунення перешкод	Scrum Master	Як другорядне завдання: керівник команди	Як другорядне завдання: керівник команди
Постійне вдосконалення	Scrum Master	Як другорядне завдання: керівник команди	Як додаткове завдання: керівництво командою, в кращому випадку - всією командою

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

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

Хто ж відповідатиме за це у звичайній команді розробників, яка не працює за Скрамом, тобто команді, яка розробляє програмне забезпечення без Скрам-майстра за своєю природою?

Ймовірно, або а) лідер команди / менеджер проекту / власник продукту тощо, або б) ніхто не відчуває відповідальності за такі речі. І саме так поводяться скрам-команди без скрам-майстра:

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

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

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

Загалом, ми повинні ігнорувати “виходи” Scrum-майстра і думати про “результати” хорошої Scrum-команди (докладніше про це: Вихідні дані проти результатів ), тому що проміжні результати не так важливі, як кінцевий результат. Якими є результати роботи скрам-команди і як їх можна досягти без скрам-майстра?

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

Але які частини Scrum-фреймворку є найважливішими? Це точно не процеси та церемонії. Швидше, йдеться про знання конкретної мети (мета: створити кращу цінність для клієнтів за допомогою ітераційних циклів) і готовність рухатися до неї. Це в основному також відомо як “Agile Mindset” (докладніше про це: Agile Мислення ), або, моїми словами: дійсно серйозно ставитися до “постійного вдосконалення” в напрямку цієї мети.

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

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

• Не впроваджуйте всі гнучкі церемонії, методи та принципи одразу.

• Натомість, почніть з найважливіших: прозорості (для заохочення комунікації) та постійного вдосконалення.

  • Прозорість: як правило, введення дошки Канбан є гарною ідеєю. Це слід поєднувати зі щоденним (або південним?) стендапом для обговорення вашої роботи, можливо, під керівництвом лідера команди. Раптом робота стане видимою, а комунікація потече абсолютно новим, продуктивним шляхом.
  • Постійне вдосконалення: почніть із запровадження гнучкої ретроспективи. Оскільки на початку багато чого зміниться і виникне багато напруженості, зазвичай існує велика потреба в просторі для обговорення напруженості та перевірки гіпотез щодо її вирішення. Це і є метою хорошої ретроспективи: визначити заходи або пункти дій, протестувати їх протягом 1-2 спринтів, а потім подивитися, чи працюють вони. Наприклад, це може бути ітерація бачення продукту або встановлення реальної мети для спринту. Це було б ідеально: команда природним чином впроваджує Scrum самоорганізовано і на основі проблем.

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

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

Тому спочатку може бути навіть вигідно не мати Scrum-майстра і не “надмірно активно впроваджувати” гнучкі методи. 

І останнє, але не менш важливе: є спеціальний інструмент, який може зацікавити вас, якщо ви ставите собі питання: чи можна впровадити Скрам без Скрам-майстра?

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

Echometer - це цифровий інструмент, який допомагає гнучким лідерам команд з гнучкими ретроспективами та командами Health Check. Дистанційно, гібридно чи на місці: він робить командний коучинг вимірюваним і професіоналізує вашу роботу, заощаджуючи при цьому багато часу. Просто завітайте на наш сайт, щоб дізнатися більше: www.echometerapp.com.

Звичайно, в цьому тексті я дещо спростив і зробив його дуже коротким. Тим не менш, це може бути актуальним і цікавим поглядом на те, як підійти до вирішення проблеми проведення скраму без скрам-майстра. Підводячи підсумок: Намагайтеся мати Скрам-майстра. Якщо ви не можете, зосередьтеся на створенні атмосфери постійного вдосконалення, і команда зможе прийняти і вивчити Скрам самоорганізовано.

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

Наостанок, ще раз нагадую: якщо ви хочете спробувати, як це - розвивати свою команду за допомогою нашого інструменту: ви можете запустити гнучку ретроспективу без входу в систему, в даному випадку воркшоп “Keep, Stop, Start”. 

Або ж просто перешліть наш сайт відповідальним колегам: www.echometerapp.com.