W 2007 roku Henrik Kniberg wydał książkę Scrum and XP from the trenches. Napisał ją w przez weekend, chcąc podzielić się ze światem swoimi przemyśleniami i praktykami wykorzystanymi podczas rocznej implementacji Scruma w pewnej firmie (celowo nie podał jej nazwy, żeby nie odciągać uwagi czytelników od sedna). Osiem lat później wydana została druga edycja, nazwana przez Kniberga “director’s cut” (do pobrania za darmo pod linkiem). Kniberg opatrzył pierwotną wersję swoimi komentarzami, ponieważ doszedł do wniosku, że w ciągu tych ośmiu lat wiele się nauczył i, choć nie może zmienić przeszłości, chciałby napisać ku przestrodze, jak bardzo się w pewnych kwestiach mylił (nie żeby w innych nie trafił w sedno i nie podtrzymywał swojej pierwszej wersji). Zobaczcie zatem, od czego zaczynał Kniberg, a co niekoniecznie teraz mu się sprawdza:
- W pierwszych latach Kniberg uważał, że dobrze ułożony i zadbany Product Backlog jest początkiem wszystkich prac. Natomiast później pojawiło się mnóstwo technik umożliwiających poznanie potrzeb klientów, a które bazują na hipotezach, badaniach i eksperymentach, poprzedzających tworzenie historyjek do implementacji. I to od tego każdy zespół powinien zaczynać swoją pracę.
- Rzeczą, której Kniberg ogromnie się wstydzi (tak bardzo, że najchętniej wyrwałby kartki o tym z książki), jest szczegółowy opis, jak do wyceny historyjek stosował przelicznik w postaci roboczodni i dodatkowo kazał zespołowi mnożyć wynik przez focus factor, czyli procent zaangażowania zespołu w prace (upraszczając jeśli w dziesięcioosobowym zespole 2 osoby były chore, to focus factor maksymalnie mógł wynieść 80%). Teraz Kniberg gorąco zachęca, żeby dla uproszczenia estymat i skrócenia czasu na nie poświęcanego po prostu opierać się na wyczuciu zespołu i tzw. wczorajszej pogodzie.
- Na początku kariery planning był dla niego najważniejszym spotkaniem scrumowym. Z perspektywy czasu doszedł do wniosku jednak, że to retrospektywa odpowiada za faktyczne postępy zespołu i bez niej nawet najlepszy planning może zakończyć się katastrofą. Dodatkowo na początku planowania robił refinement, co powodowało, że spotkanie to trwało długo i było wyjątkowo męczące. Teraz zdaje sobie sprawę, że powinno się oddzielać pielęgnowanie backlogu od spotkań i utrzymywać jako proces wg potrzeb zespołu.
- Po latach Henrik nauczył się mniej restrykcyjnie podchodzić do jakości. Właśnie przy hipotezach, product show, prototypach nie musimy aż tak bardzo dbać o perfekcyjnie wykonanie prac, bo być może za chwilę i tak będziemy je poprawiać. Ważne natomiast jest to, by zespół miał świadomość, że to nie jest normalny tryb pracy, ale wyjątki i powstały dług techniczny należy zlikwidować w możliwie krótkim czasie po potwierdzeniu eksperymentu.
- Co bardzo ciekawe Kniberg odchodzi od opisywanej w Scrum Guide wskazówki, że każdy sprint musi mieć cel i wskazuje, że teraz dopuszcza nawet kilka iteracji bez zdefiniowanego celu, o ile zespół widzi szerszą perspektywę i ma wyznaczony większy cel na kilka sprintów lub na wdrożenie.
- Po latach pracy w różnych organizacjach Kniberg uznał burndown chart za nadmiarowe narzędzie (usunięto je również z późniejszych wersji Scrum Guide), które zostało wymyślone dla zespołów pracujących w sprincie miesięcznym z excelem. Obecnie mamy i lepsze pomoce wizualne, i krótsze sprinty, więc burndown chart znacząco stracił na znaczeniu.
- Biorąc pod uwagę pracę Scrum Mastera z zespołem stanowczo wycofuje się ze stwierdzenia, że SM nie powinien siedzieć z zespołem, bo będzie się mieszał do ich prac. Im SM jest bliżej zespołu, tym lepiej. Dodatkowo z perspektywy czasu bardzo mu się nie podoba, jak opisywał swój sposób zarządzania zespołem (np. gdy członkowie zespołu nie wiedzieli co robić danego dnia), bo widzi, że blokowało to zespół w nauce samoorganizacji i więcej czasu musiał później poświęcić na wyprowadzenie zespołu z tej patologii.
- Patrząc na fazę testów, Kniberg nie uważa już TDD za świetne narzędzie pracy, raczej skłania się ku temu, by każdy zespół automatyzował testy. Co natomiast śmieszniejsze (dla nas, gdy jesteśmy o te lata doświadczeń mądrzejsi), w 2007 roku bardzo mocno stał na stanowisku, że po sprincie powinny być przeprowadzone manualne testy akceptacyjne, podczas gdy teraz puka się w głowę, że przecież cała ta praca powinna się odbyć w trakcie sprintu, wykonujący ją testerzy powinni być częścią zespołu, a wszystkim powinno zależeć nie tylko na continous integration, ale na continous delivery. A wisienką na torcie, którego teraz by nie przełknął, było przekonanie Henrika, że tester powinien sprawdzać zgodność historyjek z Definition of Done i w razie czego decydować, czy faktycznie historyjka została ukończona. Nie dość, że w ten sposób tester staje się wąskim gardłem procesu, to dodatkowo takie ustalenie nie sprzyja wzmacnianiu odpowiedzialności całego zespołu.
- Bardzo kaja się, że używał w pierwszym wydaniu sformułowania sprint demo, a nie review, jako że demo zakłada komunikację tylko w jedną stronę “zobaczcie, co zrobiliśmy”, natomiast review zachęca do feedbacku i konstruktywnej rozmowy o produkcie.
- Sporządzoną przez siebie listę zadań Scrum Mastera traktuje teraz jak punkt wyjściowy dla nowego zespołu, który potrzebuje dobrego ogarnięcia spotkań, ale uczula na fakt, że ostatecznie te zadania zespół powinien wykonywać samodzielnie, a Scrum Master powinien zająć się przeszkodami uniemożliwiającymi zespołowi pracę.
- Do poprawy dużej ilości błędów Kniberg organizował “brygady strażaków”, które skupiały się tylko na rozwiązywaniu błędów i przywracaniu stabilności produktowi. O ile było to dobre rozwiązanie ad hoc, by ugasić pożar, o tyle w dłuższej perspektywie zespoły przez te brygady nie były w stanie nauczyć się samodzielnie naprawiać błędy i zapobiegać nowym.
- No i na koniec, jeśli mówimy o skalowaniu, Kniberg doszedł do wniosku, że formuła spotkań scrum of scrum raz w tygodniu, gdzie przez godzinę wszyscy mówili, co robili w zeszłym tygodniu, co będą robić i jakie mają przeszkody, była zupełną stratą czasu i w zasadzie nudnym statusem. W późniejszych latach zaczął robić krótkie, 15-minutowe codzienne spotkania, na których przedstawiciele zespołów wskazywali na zależności z innymi zespołami. Te 15 minut zamieniało się w mini giełdę, po której właściwe zespoły wyjaśniały wspólnie, jak chcą zaadresować wskazane zależności.
Ok. Czy już wiecie, dlaczego napisałam ten artykuł? Każdy z nas kiedyś zaczynał jako Scrum Master, czy Agile Coach. Każdy z nas popełniał błędy, podejmował niewłaściwe decyzje i robił coś, co niekoniecznie przysłużyło się zespołowi. Nawet taki Henrik Kniberg. Nikt nie jest nieomylny. Natomiast mamy nad Knibergiem ogromną przewagę – od 2007 roku, gdy powstała ta książka, zagadnienia Scrum i Agile zaczęły być szeroko i gorąco dyskutowane w internecie. Mamy ogromną skarbnicę wiedzy na wszystkie możliwe tematy, możemy czerpać z doświadczeń pionierów, a jednocześnie eksperymentować i popełniać własne błędy. I o ile w pewnych kwestiach nie musimy już wymyślać koła od nowa, więc o pomyłkę trudniej, o tyle dbajmy o to, by eksperymentując z nowymi rozwiązaniami, pamiętać o własnej retrospektywie i krytycznym spojrzeniu na wprowadzane przez nas nowości do procesów zespołu.