Ця сторінка була перекладена автоматично. Для кращого досвіду читання, будь ласка, перейдіть на англійську мову.

Перейти на англійську
Jean Michel Diaz
Jean Michel Diaz

Виправити зомбі-скрам за 3 кроки

Що таке Zombie Scrum?

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

Типовими симптомами зомбі-скруму є

  • Механічне виконання ритуальних процесів без доданої вартості
  • Відсутність функціональних покращень, рідкісні або марні огляди зацікавлених сторін
  • Відсутність реальної ретроспективи та планів покращення
  • Мало автономії, брак відповідальності

Наслідки зомбі-скраму: демотивація, зниження якості, відсутність кастомізації – Скрам як порожній ритуал. Дивіться також: Підробка Agile

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

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

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

Як вирішити проблему зомбі-скраму: 3 кроки

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

Крок 1: Мета команди та відгуки клієнтів

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

Керівництво та інші зацікавлені сторони не повинні виступати в якості «проксі» для клієнта. Agile-команди розробляють не те, що, на думку керівництва, потрібно клієнту, а те, що потрібно клієнту насправді. І для цього agile-команди спілкуються не з керівництвом, а безпосередньо з клієнтом.

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

Крок 2: Створіть психологічну безпеку та самоефективність

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

Якщо так, то це може бути пов’язано з 2 причинами:

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

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

Для того, щоб позбутися вивченої безпорадності (тобто низької самооцінки), необхідно зробити наступний крок:

Крок 3: Постійне вдосконалення

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

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

Це не відбувається за одну ніч. Вивчена безпорадність зростає з роками. Але це не повинно бути виправданням! Кожна ретроспектива - це можливість запустити позитивну спіраль самоефективності.

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

Висновок: Зомбі-скрам можна вилікувати

Зцілення = мета команди + відгуки клієнтів + психологічна безпека + постійне вдосконалення

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

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

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

Отже, почнімо!

Категорія блогу

Більше статей про "Поради щодо спритності"

Переглянути всі статті цієї категорії
Agiles Spotify Modell: Squads, Tribes, Chapters & Guilds erklärt

Agiles Spotify Modell: Squads, Tribes, Chapters & Guilds erklärt

Kurzüberblick zum Spotify Modell: Wie Squads, Tribes, Chapters und Guilds Agilität skalieren, welche Rollen beteiligt sind und worauf du bei der Einführung achten solltest.

5 ідей для ретроспективи спринту, які гарантовано сподобаються командам

5 ідей для ретроспективи спринту, які гарантовано сподобаються командам

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

Мої 7 улюблених шаблонів для ретроспективи Agile

Мої 7 улюблених шаблонів для ретроспективи Agile

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

Як покращити комунікацію у віддаленій команді розробників програмного забезпечення?

Як покращити комунікацію у віддаленій команді розробників програмного забезпечення?

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

Метрики DORA & SPACE: 2 командні воркшопи для покращення

Метрики DORA & SPACE: 2 командні воркшопи для покращення

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

Робочі договори: 10 прикладів, зразків та шаблонів

Робочі договори: 10 прикладів, зразків та шаблонів

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

Контрольний список для лідерів команд: 10 ключових завдань

Контрольний список для лідерів команд: 10 ключових завдань

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

Скрам-майстер як лідер для підлеглих: 8 порад для роздумів

Скрам-майстер як лідер для підлеглих: 8 порад для роздумів

Як досвідчений психолог і Scrum Master, я розумію виклики, з якими стикаються керівники команд в умовах гнучкості. Знайти баланс між гнучкістю та лідерством - непросте завдання. У цій статті я хочу...

Не кожна Scrum-команда є гнучкою: підробка Agile

Не кожна Scrum-команда є гнучкою: підробка Agile

Fake Agile: Чи кожна Scrum-команда є гнучкою? Ні, на жаль, не кожна Scrum-команда насправді є гнучкою. Дозвольте мені пояснити: Скрам-команда - це команда, яка працює відповідно до фреймворку Scrum...

Інформаційний бюлетень Echometer

Не пропускайте оновлення на Echometer та отримуйте натхнення для гнучкої роботи