Nie bój się, eksperymentuj

Z wielką przyjemnością, a wręcz i rozrzewnieniem, wspominam pierwszy zespół, w którym pracowałem w roli Scrum Mastera. Była to drużyna w pełnym tego słowa znaczenia, drużyna, która idealnie wpasowywała się w, moim zdaniem kluczową, zasadę Manifestu Zwinnego Oprogramowania:

Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.

Szybko udało nam się wejść w świat Scruma, wypracować zasady działania, znaleźć wspólny język i razem zmierzyć się z celami, które zostały nam wyznaczone.

Od samego początku praca szła nam znakomicie. Zespół z każdym dniem uczył się nowego sposobu pracy i był coraz lepszy. Zamiast, jak dotychczas, grupy ludzi pracujących nad projektem, w końcu mieliśmy do czynienia faktycznie z pracą zespołową. Przyjemnie było na to wszystko patrzeć.

Ja jednak wciąż byłem niezadowolony.

Backlog był przygotowany w zakresie niezbędnym do wypuszczenia produktu na rynek. Wymagania znajdujące się na jego górze były dopracowane w najmniejszych szczegółach, na co od początku mocno naciskałem. Z kolei te zaplanowane na później były w formie hasłowej, raczej ogólnikowej. Zwracałem uwagę na to, żeby każde wymaganie posiadało jednoznacznie sformułowane cele biznesowe, żeby te o podobnym temacie były zgrupowane w ramach kategorii oraz żeby unikać technicznego żargonu. W efekcie zespół rozumiał jaki jest cel poszczególnych zadań, a biznes i wszyscy zainteresowani projektami mieli jasny obraz sytuacji. Praca IT w końcu była w pełni transparentna i czytelna dla całej organizacji.I wszyscy byli zadowoleni. Wszyscy oprócz mnie. Bo nie mieliśmy formatu User Stories “Jako <użytkownik> chciałbym <żeby>, <ponieważ>. I jakoś tak te wymagania wydawały się gorszego sortu, jakieś takie niescrumowe.

Planowanie sprintu wyglądało dobrze. Zespół nie miał problemu z estymacją wymagań i zaplanowaniem ilości prac na najbliższy sprint. Bez problemu dogadywał się z Product Ownerem, który był bardzo zadowolony z tempa pracy i jej efektów oraz przyrostowego uszczegóławiania wymagań. Ja jednak miałem sporo wątpliwości czy na pewno to wygląda dobrze. Bo Przewodnik po Scrumie wyraźnie dzielił spotkanie na dwie części. Z pierwszą – co może zostać zrobione w Sprincie nie mieliśmy żadnych problemów, doprowadziłem do tego, że trzymaliśmy się tu zasad z przewodnika. Gorzej było z częścią drugą – w jaki sposób wybrany zakres pracy zostanie zrealizowany. Czytałem przewodnik wiele razy, przejrzałem internet wszem i wobec, wpisując w wyszukiwarkę coraz to dziwniejsze frazy, przekopywałem się przez sporą ilość literatury. I nigdzie nie mogłem znaleźć wzorowego przykładu jak ta druga część powinna wyglądać. Miałem sporo wątpliwości. Bo przecież nie było w trakcie tego spotkania czasu, kiedy zespół projektował system i zarysowywał prace niezbędne do przekształcenia elementów Backlogu Produktu w działający Przyrost produktu. Nie rozpisywaliśmy na mniejsze porcje prace planowane na pierwsze dni Sprintu. Ba, najgorsze, że zespół nie tłumaczył Product Ownerowi i Scrum Masterowi w jaki sposób ma zamiar pracować, by osiągnąć Cel Sprintu i wytworzyć oczekiwany Przyrost. Wszystko załatwialiśmy to w inny sposób i w jednej części spotkania.

Zaczynaliśmy od krótkiego ustalenia z Product Ownerem celów, które chcemy osiągnąć w najbliższym sprint’cie. Potem prosiliśmy o trochę czasu, gdzie trwało rozbijanie wymagań na zadania techniczne. I tu – kolejna zgroza – od razu ustalaliśmy kto danym zadaniem się zajmie, a nawet, kto będzie osobą, która szczególnie mocno zadba o skoordynowanie prac i doprowadzenie ich do zakończenia. Uch, reguły Scruma milczą na ten temat, czy tak w ogóle wolno robić – tego typu myśli krążyły po mojej głowie… Kontynuując, gdy już mieliśmy pełen obraz kto podejmie jakie zadanie, każdy indywidualnie oceniał czy nie będzie w najbliższym sprint’cie zbytnio przeciążony. Ostatecznie – podejmowaliśmy decyzję ile wymagań jesteśmy w stanie zrealizować i zapraszaliśmy ponownie Product Ownera, któremu przedstawialiśmy nasz plan do akceptacji, proponując w razie potrzeby alternatywy. I działało to świetnie. Ale byłem niezadowolony, bo w moim odczuciu zmieniliśmy reguły Scruma, wędrując w stronę czegoś co zdawało mi się typowym “Scrum, but…”

Daily Scrum wyglądał wzorowo. Uciekliśmy od pułapki spotkania statusowego, prace były wzajemnie koordynowane, padało wiele cennych uwag, a technikalia omawiane były na koniec w gronie zainteresowanych. Ale ja wciąż uparcie walczyłem o to, żeby odpowiadać na trzy pytania z “Przewodnika po Scrumie” i skupiać się na opowiadaniu, co zrobiłem i co zrobię.

Nasze cele były dowożone, niemalże każdy sprint kończył się pewnym zrealizowaniem wszystkich spośród nich. Ale mnie codziennie martwił wykres spalania, który nie zmierzał ku zeru w oczekiwanym przeze mnie tempie, zbyt daleko znajdując się od linii prezentującej rzekomo idealny przebieg.

Na przegląd sprintu przychodziło dużo osób z zaciekawieniem przysłuchujących się całości i zadających istotne pytania, których efektem było dodanie nowych wymagań do backloga. Zespół prezentował wyniki swoich prac, a Product Owner pokrótce podsumowywał całość i mówił o planach na najbliższe sprinty. Ale mieliśmy sprint dwutygodniowy, a spotkanie trwało 30 minut. A przecież według zasad Scruma, możemy na to przeznaczyć aż dwie godziny. Długo zastanawiałem się jakiego elementu nam brakuje, co robimy nie tak, że tak szybko je kończymy.

Wszystko działało i z każdym sprintem byliśmy coraz lepsi. Ale ja wciąż szukałem dziury w całym, wciąż byłem niezadowolony i martwiłem się, że odbiegamy od wyznaczonych zasad…

Dopiero z czasem przyszło otrzeźwienie. Pierwszą rzeczą, która dała mi do myślenia, była lektura tak zwanych książek kanonicznych w temacie Scrum/agile, a także blogów guru, uznanych praktyków. Okazało się, że inni działają w podobny sposób. Ba, niektórzy wręcz świadomie łamią pewne zasady, ponieważ w kontekście danej chwili, danego zespołu, danej firmy ma to sens i przynosi określone profity.

Potrzeba było kilku sprintów, zakończenia z sukcesem pierwszego etapu, żeby móc na wszystko spojrzeć z dystansem. Robiąc sobie indywidualną retrospektywę całości prac zespołu, olśniło mnie. Zrozumiałem w końcu o co chodzi w Scrumie, na czym polega zwinne wytwarzanie oprogramowania. I skąd zasada – nie bój się, eksperymentuj.

Łatwo piszę się to wszystko z kilkuletniej perspektywy. Perspektywy, z której widzę, że nie byłem sam z tym problemem. Ba, nieustannie spotykam się ze Scrum Masterami, którzy opowiadają mi takie problemy. Niby wszystko działa dobrze, ale oni sami gdzieś podświadomie czują, że nie są całkowicie zgodni z regułami Scruma. I są w kropce, bo nie mają pomysłu jak wyjść z tej sytuacji.

Przewodnik po Scrumie to nie X przykazań, a Schwaber i Sutherland choć mniemanie o sobie mają wysokie, to jednak nie karzą za zło i nie wynagradzają za dobro. Scrum jest lekki, łatwy do zrozumienia, ale trudny do opanowania. Dlatego, że ma w sobie “to coś”, ten pierwiastek, te idee, tę kulturę pracy, którą trzeba poczuć. Właśnie dlatego, że jest tu czucie i wiara, a nie procedury i mędrca szkiełko i oko.

#ScrumMaster