Dlaczego Scrum nie działa – część 2

Kiedy decydujemy się na pracę we framework’u Scrum, to oczekujemy z tego jakichś korzyści. Zresztą obiecuje nam to sam Scrum Guide mówiąc, iż dzięki Scrumowi możemy „wytwarzać produkty o najwyższej możliwej wartości”.

Czasami jednak wprowadzamy takie rzeczy jak „sprint”, „backlog” i „właściciel produktu” – a jednak nie dostrzegamy żadnych benefitów. Mamy poczucie, że tracimy czas na planowaniach, stand-upach i przeglądach, a nie dostajemy nic w zamian…

Przyczyny takiego stanu mogą być oczywiście różne – w tym tekście chciałbym omówić jedną z nich, którą jest brak barier chroniących zespół deweloperski.

Naturalnym stanem wielu projektów IT jest chaos. Mamy wielu udziałowców i partnerów, wymieniamy się mailami, przerzucamy się pomysłami, zbieramy akceptacje. Omawiamy funkcjonalności, ustalamy terminy spotkań, rysujemy roadmap’y, toczymy dyskusje, planujemy wersje systemu, potrzebujemy jeszcze więcej spotkań, wprowadzamy nagłe zmiany, odkrywamy niespodziewane ograniczenia, pojawiają się wrzuty, prosimy o szacowania, zmieniamy po raz kolejny plany – to wszystko kotłuje się i tworzy jeden wielki miszmasz.

Ten chaos nie jest dobrym miejscem pracy dla zespołu deweloperskiego. Deweloperzy potrzebują pewnej stabilizacji, aby wypracować dobre rozwiązania.

Scrum oferuje nam dwie silne zapory, które chronią zespół deweloperski przed chaosem.

Pierwszą zaporą jest Właściciel Produktu. Jednym z głównych zadań tej osoby jest przekucie wszystkich pomysłów, funkcji oraz wymagań w elementy Backlogu Produktu.

Poniższy rysunek pokazuje działanie tej zapory. Z lewej strony mamy wielki bałagan. Z prawej – mamy jedną, spriorytetyzowaną listę rzeczy, które powinny być wykonane.

Backlog Produktu może być duży. Złożony. I bardzo dynamiczny. Nawet jeżeli wszystkie wymagania mamy wyrażone w backlogu, to jego elementy zmieniają się. Dzisiaj ważna jest funkcjonalność A, ale jutro może okazać się, że najważniejsza jest funkcjonalność B.

Stąd też potrzeba postawienia drugiej zapory, którą jest Sprint.

Sprint jest sposobem na zamrożenie najważniejszej części backlogu. Podczas planowania Sprintu zespół deweloperski mówi: „Zakładamy, że te zadania, które bierzemy teraz do sprintu, nie będą za bardzo zmieniać się podczas jego trwania. Dlatego możemy zaplanować sposób ich wykonania. I zakładamy, że będziemy mieli komfort pracy nad tymi zadaniami bez zbyt wielu rozproszeń”.

Spróbujmy sobie teraz wyobrazić, co dzieje się w momencie, kiedy tych zapór nie ma – albo kiedy nie działają one prawidłowo. Z reguły pojawia się wtedy taka sytuacja:

Klienci i udziałowcy wprowadzają zmiany w backlogu produktu, backlogu sprintu i mają bezpośredni wpływ na członków zespołu deweloperskiego. „Musimy wykonać to zadanie teraz”. „Ta funkcjonalność jest krytyczna”. „Musimy to oddać do końca tego tygodnia”. Z reguły powoduje to brak stabilności, brak jasnego celu sprintu oraz ogólne niezadowolenie.

Dlatego przed podjęciem decyzji „wdrażamy Scrum’a!” warto jest zadać sobie dwa proste pytania:

1. czy mamy Właściciela Produktu, który podejmuje ostateczne decyzje o zawartości i priorytetach Backlog Produktu?
2. czy możemy pozwolić zespołowi deweloperskiemu na pracę bez zakłóceń podczas trwania sprintu?

Jeżeli nie możemy odpowiedzieć „2 razy tak” – korzyści ze stosowania sprintów będą bardzo ograniczone. O ile w ogóle będą…