Одна з перешкод на шляху до готового — вузькі місця та блоки (корки). Стефані Окерман згадувала про це у своєму попередньому матеріалі.

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

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

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

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

1. Команда не має повноважень

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

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

2. Ми плутаємо обмеження з гіпотезами

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

На тренінгу Professional Scrum Master ми говоримо про те, що обмеження допомагають максимізувати самокерівництво

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

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

Сумнівайтеся в усьому.

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

Одна з таких диких ідей може перерости в цілком робочу гіпотезу.

3. Ми не усвідомлюємо реального впливу блоків

Чи трапляються в вашій команді повторювані блоки? Чи сильно вони впливають на вашу роботу?

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

Чи відкладає ваша команда навчання чи менторинг через брак часу? Може, вони бояться здаватися менш продуктивними?

Ось два способи виявити реальний вплив блоків:

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

– Скільки часу ми марнуємо на боротьбу з блоком? Як часто виникає цей конкретний блок? Стефані Окерман радить спробувати техніку обчислення витрат Waste Snake.

– Як блок впливає на якість? До прикладу, кількість дефектів на виробництві зростає чи падає? Скільки коштує виправити дефект на виробництві, а скільки — в процесі розробки?

– Як це впливає на гнучкість команди?

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

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

4. Забагато планування спринту

Розплановувати кожну робочу годину кожного члена скрам-команди під час спринту — хибна практика, що веде до провалу. Та й команда почуватиметься так, наче в неї просто немає часу на розв’язання блоків. Потрібно усвідомити: вдосконалення — це частина роботи. Ось кілька ідей, як визнати і підтримати цей процес у команді.

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

5. Менеджмент не залучений до усунення організаційних блоків

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

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

А ще ця тема піднімається й обговорюється на сертифікаційному тренінгу Scrum.org Professional Scrum Product Owner

Підсумуємо

Скрам-команда має усувати перешкоди.

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

Скрам-команда має мати повноваження усувати перешкоди.

Вплив блоків на робочий процес має бути прозорим.

Скрам-команді потрібно дати час на усунення перешкод.

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

Джерело: scrum.org.