Pora na ostatnią część cyklu artykułów o mitach związanych ze Scrumem. Tym razem nie skupiam się na wybranych elementach metody i nieporozumienia, o jakich piszę, dotyczą różnych jej aspektów: Zespołu Scrum, przejrzystości czy Definicji Ukończenia.
Namawiam też do zapoznania się z pozostałymi częściami, które można czytać w dowolnym porządku, ale najlepiej robić to po kolei: część pierwsza, część druga, część trzecia, część czwarta i część piąta.
Mit 61: pielęgnacja Backlogu ma skrócić Planowanie Sprintu do minimum
Spotkałem naprawdę wiele Zespołów, które po to, aby „sprawnie” realizować Planowanie, tworzą szczegółowy plan realizacji elementów Backlogu Produktu w ramach jego pielęgnacji. Są przekonane, że właśnie o to w niej chodzi. Planowanie Sprintu polega potem najczęściej na szybkim potwierdzeniu, że nic się nie zmieniło, a bywa, że nawet tym się nikt nie kłopocze.
„Sprawność” takiego Planowania jest pozorna. Jest ono krótkie, ale tylko dlatego, że praca, którą należy wykonać w jego trakcie, jest rozsmarowana na wiele poprzednich iteracji.
Co gorsza, ustalenia dokonywane w trakcie pielęgnacji, mają szansę zdezaktualizować się, więc pracę być może trzeba będzie powtórzyć. Jeszcze gorzej, jeśli mimo takiej konieczności, Developerzy tego nie zrobią, trzymając się nieadekwatnego planu działania…
Nie bez przyczyny definicja Scruma jasno określa, że to dopiero w trakcie Planowania Sprintu Developerzy tworzą plan realizacji podjętych do iteracji elementów Backlogu Produktu. Dzięki temu mogą uwzględnić wiedzę o aktualnym stanie produktu, praktyk, narzędzi, swojej dostępności, ewentualnych zależnościach do innych zmian w produkcie, które zamierzają zrealizować w tym samym Sprincie itd.
Mit 62: Developerzy odpowiadają za organizację pielęgnacji Backlogu
Pielęgnacja Backlogu Produktu ma spowodować, że na początku listy będzie dostatecznie dużo elementów gotowych do realizacji, by dało się zaplanować kolejny Sprint. Wymaga to, by Developerzy rozumieli problemy opisane w poszczególnych elementach, potrafili stworzyć plan ich realizacji i byli przekonani, że da się go wykonać w trakcie jednego Sprintu.
A skoro pielęgnacja służy Developerom, to z ich inicjatywy powinna się odbywać, czyż nie? Przekłada się to na bierną postawę niektórych Product Ownerów, którzy uznają, że brak pytań ze strony Developerów oznacza, iż wszystko jest jasne.
Oczywiście to nieporozumienie. Pielęgnacją Backlogu Produktu jest każde działanie z nim związane, w tym ustalanie zawartości i kolejności elementów. Wspomniany na początku cel pielęgnacji też nie jest jedynym. Drugim jest zapewnienie przejrzystości Backlogu Produktu. Trzecim jest dbanie o to, by Backlog odzwierciedlał potrzeby interesariuszy i by rozwój produktu przynosił im maksymalne korzyści. Za to wszystko odpowiada w Scrumie Product Owner.
Mało tego: to Product Owner ma obowiązek upewnić się, że uczestnicy Planowania Sprintu są do zdarzenia przygotowani. Dotyczy to zarówno zapraszanych ekspertów, jak i samego Zespołu.
Przy czym nie oznacza to od razu, że za pielęgnację odpowiada sam Product Owner. O to, by miała miejsce i zaspakajała wszystkie związane z nią potrzeby, ma dbać cały Zespół. A jeśli tego nie robi, odpowiedzialnością Scrum Mastera jest spowodować, by tak się działo.
Mit 63: 15% czasu Sprintu na pielęgnację Backlogu Produktu
Ile powinna trwać pielęgnacja Backlogu Produktu w Scrumie? Wedle jednej tezy to maksymalnie 15% czasu Sprintu. Wedle drugiej te 15% jest czasem minimalnym. A są i tacy, co utrzymują, że pielęgnacja ma trwać dokładnie tyle. I wszyscy się mylą.
Zapis w historycznych edycjach Scrum Guide, który doprowadził do tych nieporozumień, zawierał jedynie sugestię, że zazwyczaj pielęgnacja nie zabiera Developerom więcej niż owe 15% czasu, jakim dysponują w Sprincie. Co oznaczało, że równie dobrze może jej być więcej lub mniej, a co do zasady nawet 100% swego czasu na pielęgnację może poświęcić Product Owner.
Wzmianka o tych 15% w najnowszej edycji Scrum Guide już nie występuje, ale najwyraźniej potrzeba sporo czasu, by jej echo przestało pobrzmiewać w Zespołach Scrum.
Mit 64: przejrzystość wymaga, by wszyscy wiedzieli wszystko o wszystkim
Pełna przejrzystość to dostęp do wszystkich informacji dla każdego w każdej chwili i bez ograniczeń – tak właśnie interpretowany bywa postulat zapewnienia przejrzystości w Scrumie.
Niestety, ta interpretacja jest chybiona i może prowadzić do utraty kontroli nad procesem. Empiryzm wymaga bowiem przejrzystości kluczowych parametrów, które mają istotny wpływ na proces.
Informowanie wszystkich o wszystkim i dążenie do tego, by dysponować zbiorem danych możliwie największym, obniża przejrzystość. To, co istotne, ginie w szumie, a ludzie mają ograniczoną zdolność przyswajania informacji. Bombardowanie ich nowymi danymi może też skutkować utratą skupienia.
Mit 65: Scrum Master ma zapewnić przejrzystość
Ponieważ Scrum Master odpowiada za to, by Zespół posługiwał się empirycznym procesem w sposób opisany w Scrum Guide, a jednym z filarów empiryzmu jest przejrzystość, ani chybi to Scrum Master ma obowiązek ją zapewnić.
Ten ciąg logiczny jest ułomny, bo kończy się chybionym wnioskiem. Scrum Master odpowiada (ang. is accountable) za to, by istniała przejrzystość niezbędna do empirycznej kontroli nad procesem. Nie oznacza to jednak, że ma ją osobiście zapewnić, bo jest zasadnicza różnica między doprowadzeniem do tego, by coś zostało zrobione, a zrobieniem tego samemu.
Dopóki brak przejrzystości dotyczy artefaktów, za które odpowiadają Product Owner lub Developerzy, Scrum Master nie może ich zastępować ani wywłaszczać z tej odpowiedzialności. Gdy to Backlog Produktu ma zbyt niską przejrzystość, Product Owner ma zapewnić jej podniesienie. Gdy brak przejrzystości Backlogu Sprintu lub Przyrostów, o jej zwiększenie zadbać muszą Developerzy. Scrum Master pomaga im, ale tak, by pozostać wciąż Scrum Masterem, a nie stać się Developerem lub Product Ownerem.
Mit 66: każde zdarzenie ma moderować Scrum Master
A skoro już o pracy Scrum Mastera mowa, to często oczekuje się od niego prowadzenia wszystkich zdarzeń w Scrumie. Wszak w definicji metody jest, że ma tego typu usługi świadczyć na rzecz Zespołu.
Jest to oczywista nadinterpretacja. Scrum Master staje się moderatorem, gdy zostanie o to poproszony, lub gdy to niezbędne do zapewnienia skuteczności działania Zespołu. Musi jednak być ostrożny, by nie uzależnić go od siebie. Celem powinno być nauczenie ludzi, jak organizować poszczególne zdarzenia, a nie prowadzenie ich w nieskończoność.
Mit 67: każde zdarzenie w Scrumie wymaga moderatora
Powyższy mit łączy się z przekonaniem, że każde spotkanie (a zdarzenia w Scrumie, z wyjątkiem Sprintu, mają formę spotkań) wymaga moderacji.
W rzeczywistości niewielki Zespół złożony z zaangażowanych ludzi, którzy wiedzą, po co się spotkali, potrafi zwykle organicznie przeprowadzić dyskusję i podjąć różne decyzje bez wyznaczenia roli moderatora. Ona jest potrzebna tam, gdzie uczestnicy mogą się pogubić, rozejść w różne strony lub popaść w chaos. Oraz w przypadku naprawdę dużych grup.
Przykładem zdarzenia, któremu moderacja częściej szkodzi, niż pomaga, jest Daily Scrum. Być może najbardziej moderacji potrzebować będzie w Scrumie Przegląd Sprintu, jeśli biorą w nim udział liczni interesariusze, ale i to nie zawsze okazuje się konieczne.
Mit 68: Zespół Scrum nie może liczyć więcej niż 10 osób
A skoro mowa o wielkości grupy, to warto wspomnieć mit związany z liczbą osób w Zespole Scrum. Aktualnie obowiązuje wersja, że to maksymalnie 10 osób (wliczając Product Ownera i Scrum Mastera). Przed 2020 mit mówił o maksymalnie dziewięciu Developerach. W obu przypadkach źródłem błędnego przekonania był źle interpretowany zapis w definicji Scruma.
Bo faktycznie, przez 2020 była mowa, iż Developerów nie powinno być więcej niż dziewięciu, a edycja z 2020 wskazuje na 10 osób jako zalecaną maksymalną wielkość Zespołu. Niemniej to wciąż jedynie zalecenie. Co oznacza, że Zespół równie dobrze może liczyć np. 11 lub 12 osób.
Mit 69: skład Zespołu Scrum musi być stały
A jak to jest z tym wymogiem, by Zespół Scrum miał stały skład na przestrzeni wielu Sprintów? Cóż, to kolejny mit. Nie ma takiego wymogu i nigdy go nie było. Oczywiście stałe Zespoły są bardzo korzystne, bo mogą wykształcić relacje między poszczególnymi osobami i zwykle działają bardzo sprawnie – Scrum jednak tego nie wymaga.
Ważna jest stabilność Zespołu w trakcie Sprintu, a mówiąc precyzyjniej, iterację planować powinny te osoby, które w niej biorą udział. Chodzi o to, by w trakcie Planowania Sprintu jasne było, jacy Developerzy są dostępni i jakie kompetencje wniosą do Zespołu.
O ile wiec mieszanie składami Zespołów zdecydowanie to odradzam, o tyle, jeśli np. grupa ludzi pracujących nad jednym produktem formuje co Sprint różne Zespoły, żeby lepiej dopasować ich składy do tego, co jest do zrobienia, nie łamią w ten sposób zasad Scruma.
Mit 70: Scrum nie dopuszcza pracy w Zespole na pół etatu
Scrum Guide nie określa, jak mają być formowane Zespoły Scrum, a jedynie wymaga, by były wszechstronne i samozarządzające. Dlatego nie jest prawdą, że w Scrumie nikt nie może być członkiem Zespołu na niepełny etat.
Dzielenie czasu między więcej niż jeden Zespół nie jest korzystne, ale gdy jest nieuniknione, warto zadbać o określanie swej dostępności z pewnym wyprzedzeniem. Wtedy reszta Zespołu łatwiej będzie mogła zaplanować swoje działania wymagające współpracy z taką osobą pracującą na niepełny etat.
Mit 71: każdy Developer musi być w stanie wykonać każdy rodzaj pracy
Zespół Scrum musi być wystarczająco wszechstronny (ang. cross-functional), żeby był w stanie wytworzyć w pełni ukończony i wartościowy Przyrost. Ten wymóg bywa interpretowany jako konieczność, by wszyscy Developerzy posiadali takie same umiejętności i byli w stanie samodzielnie zmierzyć się z każdym problemem.
Jest to ogromne nieporozumienie, bo zaprzecza sensowi istnienia Zespołu jako takiego i potrzebie pracy zespołowej. Bardzo często z tym przekonaniem w parze idzie organizacja pracy w Sprincie taka, że każdy Developer pracuje nad czymś innym i samodzielnie ma realizować kompletną zmianę w produkcie. Powoduje to, że Zespół jako całość pracuje nad wieloma rzeczami naraz i w znacznym stopniu marnowane są możliwości łączenia kompetencji, by zrobić coś lepiej i szybciej.
W praktyce dużo lepiej radzą sobie Zespoły, w których kompetencje posiadane przez poszczególne osoby są zróżnicowane, ale dobrze się uzupełniają. Zespoły te zwykle skupiają się nad jednym czy dwoma problemami naraz, co dodatkowo ułatwia im koordynację prac developerskich.
Mit 72: odpowiedzialności w Zespole Scrum nie można łączyć
Czy Developer może być jednocześnie Scrum Masterem i Product Ownerem? Wykluczone! – zakrzyknie wiele osób, bo to wydaje się połączeniem absurdalnym. Jakie więc połączenia są dopuszczalne? Niektórzy powiedzą, że żadne. Inni, że jedynie Scrum Master i Product Owner nie mogą być jedną osobą.
A jak jest w Scrumie? Nie ma żadnego ograniczenia w tym zakresie. Autorzy Scrum Guide niejednokrotnie rozważali tę kwestię i za każdym razem rezygnowali z dodania zakazów, bo mają świadomość istnienia Zespołów, które tak właśnie działają i są bardzo skuteczne.
Zdecydowanie odradzam łączenie odpowiedzialności Scrum Mastera i Product Ownera, zwykle marne skutki daje też połączenie odpowiedzialności Developera i Product Ownera. Natomiast Scrum Masterzy będący jednocześnie Developerami to poniekąd powszechne zjawisko, ale nie każdy będzie umieć się wywiązać z obu wziętych na siebie dwóch odpowiedzialności.
Mit 73: Zespoły Scrum muszą same decydować o swym składzie
Istnieje przekonanie, że jedynym dopuszczalnym sposobem tworzenia Zespołów Scrum jest pozwolenie ludziom na ich samodzielne sformowanie. Jest to świetny pomysł, do którego gorąco zachęcam, niemniej Scrum tego nie wymaga. Skąd więc wziął się ten mit?
Najpewniej w złym doborze słownictwa. Scrum od początku posługiwał się terminem samoorganizacja (ang. self-organization), interpretując ją jako samodzielne zarządzanie wykonywaną pracą. Tymczasem w teoriach zarządzania nosi to nazwę samozarządzania (ang. self-manamenent), samoorganizacja zaś jest postulatem autonomii Zespołu w kwestii jego składu i warunków pracy.
W edycji Scrum Guide z 2020 nastąpiła zmiana terminu, więc wątpliwości powinny zostać rozwiane.
Mit 74: nikt w Zespole Scrum nie może być przełożonym pozostałych osób
Scrum Guide jasno wskazuje, że w Zespole Scrum nie ma żadnej hierarchii. Stąd już łatwo o wniosek, że istnienie relacji przełożony-podwładni wewnątrz Zespołu Scrum jest zakazane.
Tyle że wcale nie jest. Scrum w ogóle nie zajmuje się kwestią organizacji Zespołów jako takich, określa jedynie, jakie one mają być. Owszem, nie ma żadnej hierarchii wynikającej z podjęcia określonej odpowiedzialności w Scrumie, ale to nie znaczy, że taka hierarchia nie wynika z funkcji, jakie poszczególne osoby pełnią w organizacji.
Zdrowy rozsądek podpowiada, by tego unikać i że będzie to bardziej szkodzić, niż pomagać. Niemniej zakazu jako takiego w Scrumie brak.
Mit 75: Product Owner decyduje o zawartości Definicji Ukończenia
Na koniec wrócę jeszcze do Definicji Ukończenia. Co do zasady, jest ona ustalana przez cały Zespół Scrum, ale czasami ludzie nie potrafią się dogadać. Kto wtedy ma podjąć decyzję, co w Definicji się znajdzie? Pytanie wydaje się oczywiste: właściciel produktu, a więc Product Owner.
Niestety, choć to poniekąd logiczne, nie ma sensu. Ostatnie zdanie musi należeć do Developerów, ponieważ to oni mają spełnić wymogi Definicji Ukończenia.
Gdyby Product Owner wymusił dodanie warunków, których Developerzy nie potrafią zaspokoić, nie powstanie Przyrost. Lepiej więc, by Definicja ujawniała, co są w stanie zrobić, bo wtedy problem stanie się natychmiast widoczny.
Gdyby Product Owner natomiast wymusił usunięcie jakichś warunków z Definicji, nikt nie zabroni Developerom działać, jakby nadal obowiązywały. Dlatego znów lepiej, by Definicja ujawniała, co mają intencję robić – a jeśli jest to nieakceptowalne dla Product Ownera z jakiegoś powodu, musi poszukać innego Zespołu.
Czy to wszystkie mity?
Jasne, że nie. Ich zbiór jest subiektywny, kierowałem się po prostu tym, na co natrafiłem, pracując w różnych organizacjach, doradzając Zespołom, czy wreszcie odpowiadając na pytania w trakcie szkoleń i warsztatów.
Nie da się ukryć, że Scrum obrósł nieporozumieniami solidnie, a część z nich ma swe źródła w zapisach definicji metody, które przez lata mocno się zmieniły. Zachęcam, by dobrze poznać dobrze narzędzia, z których się korzysta i przynajmniej od czasu do czasu sprawdzać, czy coś się w nich nie zmieniło.
Warto też kierować się rozsądkiem, korzystając z książek i publikacji dostępnych w sieci, które mogą być już nieaktualne, bo opublikowano je lata temu, albo – niestety – powielają różne mity. W tym ostatnim przypadku lepiej poszukać bardziej wiarygodnego źródła wiedzy.