Wiele zespołów IT na całym świecie działa w bardzo podobny sposób.
Mamy Klienta. Klient ma wizję – chciałby mieć system, funkcjonalność czy możliwość wykonywana pewnej operacji. „Chciałbym, żeby nasz system mógł eksportować dane do Excela”. „Chciałbym mieć możliwość podglądu stanów magazynowych”. „Chciałbym mieć możliwość szybkiej konsolidacji list mailingowych z wielu źródeł”. Klient ma pieniądze, które może wydać na urzeczywistnienie tego pomysłu. Czasami jest to żywa gotówka, ale najczęściej jest to po prostu możliwość dedykowania czasu pracy jakiegoś zespołu na potrzeby realizacji tej wizji. Klientowi przeważnie zależy na czasie – chciałby mieć swoją funkcjonalność jak najszybciej.
Mamy Zespół Deweloperski – grupę ludzi, która potrafi zmienić pomysł klienta w działającą aplikację.
I mamy Menedżera, który jest odpowiedzialny za pracę lub za rezultat pracy Zespołu. W zależności od sytuacji oraz od organizacji może być to kierownik zespołu organizacji bądź kierownik projektu.
Menedżerzy to zazwyczaj zazwyczaj ludzie z inicjatywą. Nic więc dziwnego w tym, iż Menedżer zaczyna pytać klienta o szczegóły jego pomysłów oraz zaczyna pytać Zespół o możliwość realizacji tychże pomysłów. „Szanowny Kliencie, co dokładnie chciałbyś eksportować do Excela?”. „Drogi Zespole, ile czasu może nam zająć wykonanie takiej funkcjonalności?”. „Jakich informacji wam jeszcze brakuje?”. „Gdzie mogą kryć się ryzyka?”.
Zaczyna powstawać Plan działań. Jego forma nie ma w tym momencie większego znaczenia – może być to lista zadań w Excelu, plan w MS Project, notatka w pliku tekstowym, cokolwiek. Ważne, że znajduje się tam spis rzeczy do wykonania, jakieś estymacje oraz terminy szacowanego wykonania pracy.
Zwykle to Menedżer jest właścicielem tego Planu. Czasami on sam twierdzi inaczej i mówi: „Drogi Zespole, to jest nasz wspólny plan”, natomiast istnieje jeden bardzo prosty test, który pozwala ustalić, kto jest faktycznym właścicielem. Wystarczy poczekać, aż osoba z Zespołu Deweloperskiego odkryje jakąś zmianę w stosunku do tego planu. Może to być nowe, niezaplanowane zadanie albo też odkrycie, że estymacja jakiegoś zadania dwa razy za mała. Jeżeli ta osoba poprawi plan sama, to jest to faktycznie plan zespołu. Jeżeli natomiast przekaże Menedżerowi informację o zmianie i będzie czekała na aktualizację planu – jest to plan Menedżera. Działa tu jedna prosta zasada – jeżeli wiem, że coś jest moją własnością, to nie waham się tego zmienić.
Taki układ daje dużo komfortu zarówno Klientowi oraz Zespołowi Deweloperskiemu. Klient myśli: „jak dobrze, że jest ktoś, który ogarnia te wszystkie techniczne zawiłości i gwarantuje mi, że wszystko zostanie zrobione na czas”. Zespół myśli: „jak dobrze, że jest ktoś, kto ogarnia to całe planowanie i pozwala nam się skupić na pracy”.
Zaangażowanie Menedżera w planowanie ma swoje dobre strony. Menedżer może zrobić kilka wartościowych rzeczy: może zwrócić uwagę na planowanie w dłuższym horyzoncie czasowym; może udzielić zespołowi informacji zwrotnej; może połączyć ten plan z planami innych zespołów i jednostek. Ale jednocześnie fakt, iż Menedżer jest właścicielem Planu, może znacząco ograniczyć motywację członków Zespołu. W pewnym momencie w Zespole może pojawić się poczucie: „nie dowieziemy tego planu – ale przecież to nie jest nasz plan…”
Załóżmy, że w pewnym momencie nasz Klient, Menedżer oraz Zespół zdecydowali o wdrożeniu framework’u Scrum. Jeżeli tylko podchodzą do tego wdrożenia poważnie – to cały ten układ zmienia się diametralnie.
Przede wszystkim zmienia się właściciel Planu. Scrum mówi jasno – planujemy na podstawie Backlogu Produktu, a osobą odpowiedzialną za Backlog jest Właściciel Produktu. Odpowiedzialność za planowanie przechodzi więc z rąk Menedżera do rąk Klienta. Ale żeby Klient mógł coś zaplanować, musi dostać wkład w postaci estymat – i powinien dostać go bezpośrednio od Zespołu Deweloperskiego. Czyli cała komunikacja, której celem jest stworzenie planu, odbywa się teraz na linii Właściciel Produktu – Zespół Deweloperski. W bonusie obie strony dostają Scrum Mastera, który który dba o to, żeby planowanie było sprawne i odbywało się zgodnie z zasadami Scruma.
I tutaj warto zauważyć, że ta zmiana wiąże się z wyjściem ze strefy komfortu dla wszystkich zainteresowanych stron!
Klient – czyli nasz świeżo mianowany Właściciel Produktu – musi chcieć przejąć planowanie długoterminowe z rąk Menedżera i musi nauczyć się tworzenia planów na podstawie wsadu od Zespołu Deweloperskiego. To oznacza konieczność podjęcia się nowego zadania oraz konieczność nauki nowych umiejętności.
Zespół Deweloperski musi nauczyć się szacować duże elementy Backlogu w perspektywie dłuższej niż najbliższe dwa czy cztery tygodnie. A to oznacza konieczność precyzowania zadań, ograniczania liczby niewiadomych – oraz wzięcia odpowiedzialności za szacowanie wykonane na podstawie nie do końca pewnych założeń.
Menedżer musi przekazać odpowiedzialność za planowanie w ręce Klienta oraz Zespołu. A to oznacza konieczność przeformułowania jego roli w organizacji.
Wszystkie te trzy strony są postawione wobec nowych wyzwań.
Co dostajemy w zamian? Możemy doświadczyć uproszczenia komunikacji, szybszego przekazywania informacji oraz zwiększenia motywacji zespołu. „To już jest nasz plan”. Ale żeby otrzymać tę nagrodę, trzeba najpierw uwierzyć bądź zaufać, że Klient i Zespół są w stanie samodzielnie stworzyć plan działania i wziąć na siebie odpowiedzialność za jego realizację.
Scrum jest prosty – ale nie jest łatwy.
A kto jest właścicielem planu w Twojej organizacji?