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

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

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

Перший крок по відношенню до вашого потоку поставок Agile

Я говорю про моніторинг потоку доставки Agile ваших завдань. Якщо ви зробите лише кілька речей правильно, ви зможете досягти набагато більш передбачуваних результатів. Навіть ваші графіки розкиду часу циклу або симуляція Монте-Карло для розрахунку кошторису проекту можуть нарешті показати правильні прогнози, замість того, щоб повністю відхилятися від мети (читати далі: 9 Agile Показники для тих, хто приймає рішення).

Перший симптом, з яким потрібно боротися, - це те, що є завдання, які проходять шлях від "Заплановано" до "Завершено" всього за кілька днів, а є завдання, які тривають більше місяця. Щоб протидіяти цьому, ви повинні переконатися, що завдання завжди містить найменшу можливу версію бажаної функції. Без наворотів, які не є необхідними для основного запиту клієнта. По суті, це MVT, мінімально життєздатне завдання. Це не означає, що це робить кожне завдання маленьким. Але це має допомогти вам досягти стадії, коли завдання займатимуть максимум кілька тижнів, а не місяців.

Другий крок щодо вашого потоку доставки Agile: WIP замість швидкості

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

Але це неправильно: завдання навіть не обов'язково повинні бути однакового розміру. Не варто так вважати, тому що контролювати оцінки Story Point просто занадто складно. Єдине, що ви можете контролювати - це кількість нових завдань, які ви починаєте.

Щоб стати передбачуваним, зробіть наступне: Відстежуйте показник "розпочатих нових завдань" у порівнянні з показником "завершених завдань". Ці два показники повинні бути в балансі. Іншими словами, показники "входу" і "виходу" завдань повинні бути якомога ближчими, в ідеалі навіть однаковими.

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

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

Деякі "позитивні симптоми" здорового гнучкого потоку доставки Agile

На практиці це може призвести до наступної поведінки:

• • Ми не починаємо нові завдання, коли ще багато чого не зроблено. 

• • Ми зосереджуємося на тому, щоб завершити розпочате, перш ніж починати щось нове.

• • Вік завдань ніколи не перевищує кількох тижнів.

• • Якщо немає поважної причини, ми завжди працюємо над найстарішим завданням.

Ліміти WIP (work-in-progress) також допомагають у цьому, хоча їх часто буває недостатньо. Як тільки команда навчиться зосереджуватися на завершенні завдань, а не на тому, щоб просто починати нові, ви будете кращими за більшість команд.

Якщо ви правильно використовуєте Agile Delivery Flow

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

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

Крок 3: Почніть працювати над покращенням процесу доставки Agile

В теорії ви знаєте, що робити. З чого ж краще почати на практиці? З підвищення обізнаності та "готовності до змін" у команді. У кращому випадку - через саморефлексію.

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

Я можу порекомендувати обговорити згадані мною моделі поведінки за допомогою нашого гнучкого інструменту ретроспективи Echometer у вашій ретроспективі (читати далі): 7 інструментів ретроспективи у порівнянні). Ви навіть можете зробити це частиною ваших робочих угод або регулярних Health Checks, щоб підвищити обізнаність, регулярно ставлячи запитання.

Наступні питання є нашим ретроспективним шаблоном для "гнучкої доставки" (читати далі: 22 веселі шаблони для гнучкої ретроспективи). Ми починаємо з кількох тверджень Health Check і запитуємо команду, чи вони схильні погоджуватися або не погоджуватися з ними. Після цього ставимо кілька відкритих запитань: