Agile Потік доставки: Завжди доставляйте вчасно у 3 етапи

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

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

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

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

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

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

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

Багато Scrum-майстрів або Kanban-коучів вважають, що для валідного вимірювання швидкості тощо важливо “правильно визначати розмір” завдань або робочих елементів, коли всі робочі елементи мають приблизно однаковий розмір. Тільки тоді Story Points (які необхідні для вимірювання швидкості) корисні для вимірювання швидкості, оскільки вони більше схожі на порівнянну одиницю часу. 

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

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

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

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

Деякі “позитивні симптоми” здорового гнучкого Agile Delivery Flow

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

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

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

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

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

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

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

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

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

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

В теорії ви знаєте, що робити. Як найкраще почати на практиці? Створюючи обізнаність і “готовність до змін” у команді. В ідеалі, через саморефлексію.

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

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

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

Ретроспектива поставок Agile

Health Check Елементи

Коли наш спосіб роботи призводив до неоптимального робочого процесу? (наприклад, нечіткі, невідповідні або недотримані інструкції)

Як ви можете собі уявити, останній пункт перевірки стану (перевірка причини) вже передбачає потенційний захід, щось, що ви можете спробувати протягом одного-двох гнучких спринтів, щоб побачити, чи це може вам допомогти: обмеження кількості завдань зі статусом “Work in Progress”.

Закладаємо фундамент: Укладіть домовленості про командну роботу

У вас є відчуття, що ваша команда ще не готова до такого роду рефлексії? У цьому випадку вам слід спочатку поміркувати про “хорошу роботу” в цілому, а потім встановити кілька основних правил, так званих робочих угод або Working Agreements. Наступний шаблон воркшопу може допомогти вам у цьому. Ви можете провести його як особливу форму ретроспективи на початку проекту або як додатковий воркшоп.

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

Ретроспектива командних зобов’язань

Health Check Елементи

Вирішення конфліктів: “Якщо я помічаю, що в нашій команді виникає конфлікт, то…

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

Цікава, креативна альтернатива

Якщо ці методи ретроспективи здаються вам надто “сухими”, є ще один метод ретроспективи, який зосереджується на відображенні якості результатів вашої команди ( Веселі 54 ретроспективні методи можна знайти тут ): Ретроспектива “Троє поросят”. Це проста альтернатива для того, щоб почати рефлексувати і покращувати свою роботу, заснована на казці про трьох поросят, які побудували будиночки з різних матеріалів.

Висновок - Agile Delivery Flow

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

До речі, багато ідей, які ви тут знайдете, також добре підсумовані в подкасті “Agile Bites”, який я дуже рекомендую (Посилання на подкаст: Укуси Agile). 

Насолоджуйтесь розвитком своєї команди!