Скрам (не) працює?

Цій тезі, напевно, стільки ж років, скільки Скраму 🙂. Відверто кажучи, я також колись залюбки дискутував коло кавомашини, чому Скрам не працює саме в нашій команді. Адже методологія нескладна, там гайд на півгодини почитати — не те, що з якимось мануалом по реактивності розбиратися.
Якщо ми, такі розумні й красиві, вміємо в Angular/Helm/алгоритми, а Скрам в нас не заводиться, то це ж не в нас проблема, правда?

Диявол, як завжди, в деталях. В визначеннях, в називанні речей правильними термінами. В дотриманні клятих процедур, навіть коли "нашій команді це не потрібно" ©️

Мені підвернувся курс по Скраму; дай-но, думаю, пройду. А в курсі крім лекцій ще є тести. І ось на тестах виявилося, що деталі насправді важливі. І базворди, на кшталт Transparency-Adaptation-Inspection, не базворди, а цінності. Якщо подивитися на процеси з точки зору цінностей, то багато речей стають очевидними.

Наприклад,
▷ — Sprint goal — це тупа формальність, тут і так все зрозуміло
🤷 — Ну, не закінчили ці 2 user story — перенесемо в наступний спринт
🤔 — Нууу, ми можемо це включати в реліз, але там немає ще X, Y, Z.
😠 — Які нові фічі? Нам стільки всього треба доробити!
🤬 — Піздєц, дикі плани поставили, ми стопудово проїбем дедлайн.

А все через те, що в кузні не було цвяха ©️. Якби був Sprint goal і всі його поважали, то було би чітке розуміння, що є releasable, а що — ні. Прозорість в delivery/release дає можливість планувати гнучко і не потонути в techdebt та нереалістичних очікуваннях.
Ось так цінності Скраму стають цінностями бізнесу. При цьому, всі у виграші: бізнес має прогнозований delivery; до девелоперів прислухаються.