Планування спринту є невіддільною частиною роботи команд розробників Agile, але досвід наших консультантів показує, що багато хто припускається помилок при плануванні. Тож, в статті ми розглянемо типові антипаттерни при плануванні спринту.
Взяті на себе обов’язки нереалістичні
Команда бере на себе обов’язки, які сильно перевищують їх реальні можливості. Результат очевидний та передбачуваний – спринт буде завалений. Чому так стається? Причин може бути багато.
Наприклад, тиск когось з топ-менеджменту: “Ми маємо це зробити, у нас контракт, дедлайн тощо”. А команда не вміє казати “ні” або її не чують. Інша крайність – команда надто оптимістична у своїх оцінках і не бачить потенційних ризиків, або ж просто не хоче/не може побачити реальні обсяг робіт.
Команда бере на себе менше обов’язків, ніж змогла б зробити.
Цей антипаттерн такий самий негативний, як і перший. Причин знову таки може бути багато. Наприклад, команда боїться невдач – що завалить спринт. Це особливо актуально, якщо у команди вже був досвід “завалених” спринтів, який закінчився якимось “покаранням” зі сторони топ-менеджменту. Безумовно, тут ламаються одразу декілька ключових цінностей Scrum: довіра, повага, відкритість.
Навантаження команди точно відповідає velocity або більше.
Тут очевидна ситуація перенавантаження або спроби “утилізувати ресурси” на 100%. Планувати зі 100% точністю командам важко, якщо не сказати нереально, тому при навантаженні команд більше, ніж їх середньостатистична velocity – обов’язки навряд чи будуть виконуватися.
Команда занурюється в глибокі технічні дискусії.
Не завжди довгі технічні дискусії допомагають дати оцінку точніше. Якщо обговорення протягом планування затягнулося, це сигнал до того, що у команди не вистачає знань для прийняття рішення та оцінки. Тут можна спокійно зупиняти дискусію та брати в роботу spike. Також Майк Кон в прекрасній книзі “Agile: Оцінка і планування проектів” детально описав всі мінуси довгих дискусій.
Згідно графіку точності оцінки vs витраченні зусилля, ви ніколи не отримаєте 100% правильну оцінку. Всього 10% зусиль дають вже 50% точності оцінки. А найголовніше, з деякої відмітки точність оцінки падає і команда може опинитися в ситуації, коли занадто довга дискусія навпаки погіршила точність оцінки.
Scrum Master більше залучається в технічні обговорення, ніж в процес фасилітації.
Цей антипатерн особливо часто спостерігається, якщо Scrum Master частково ще й виконує роль розробника або ж до цього був ним. Тут важливо пам’ятати про баланс і про своєчасну “зміну капелюхів” на відповідну роль та регулювати, де можна включитися як розробник і це принесе цінність команді, а де необхідно включитися як Scrum Master і профасилітувати дискусію.
Не бронюється час для активностей на підтримку.
Дуже часто в команді є регулярні задачі щодо підтримки, консультуванню тощо. Дуже важливо на плануванні зробити їх видимими та врахувати при плануванні спринту, щоб не опинитися в ситуації, коли ви увесь спринт були занадто зайняті, але от задачі зі спринту не були зроблені.
Безумовно, це всього лише деякі з можливих варіантів. Якщо ви помітили тут деякі антипатерни, які спостерігаєте на своїх плануваннях спринту – вітаємо, ви вже проробили половину шляху по їх усуненню!
Е5 допомагає компаніям оптимізувати та впроваджувати найкращі практики управління проектами. У нашому портфоліо успішні кейси з Agile-трансформації, впровадженні SAFe, оптимізації SDLC процесів і побудови PMO. Детальніше читайте за посиланням.
