- Brawa na Sprint Review — 06/09/2024
- Kanban — Jak zacząć? — 30/08/2024
- Definicja Ukończenia kontra Kryteria Akceptacji — 26/08/2024
Zawsze przy omawianiu ról pojawia się klasyczne pytanie “Czy można łączyć role”? Odpowiedź krótka jest taka, że niektóre tak, ale nie jest to zalecane. Takie pytanie pojawia się zwykle w kontekście pomysłów, żeby implementować Scrum po taniości. Bardzo rzadko jest tak, że zespół po prostu jest mały i pracuje w prostej domenie, więc nie ma potrzeby obsadzać każdej roli inną osobą. Sprawdźmy zatem, których ról nie można łączyć, a które role można łączyć i dlaczego to jest zły pomysł. Zaczniemy od najprostszego przypadku.
Scrum Master i Product Owner
Tutaj sprawa jest bardzo prosta. Tych ról nie wolno łączyć. Jeżeli młodym adeptom Scrum nie brzmi to od razu logicznie, to po prostu Scrum tego zabrania. Dlaczego? Z powodu konfliktu interesów. Połączenie Scrum Master i Product Owner widziałem w praktyce i kończy się to zawsze wygraną Product Ownera. Product Owner jest odpowiedzialny za ROI, czyli generowanie jak największej wartości z pracy zespołu. Naturalnym efektem będzie naciskanie na oszacowania zwłaszcza jeśli do tej pory w organizacji mieliśmy project management.
Kolejną rzeczą będzie wymuszanie zobowiązania (commitment) na dostarczenie większej ilości zakresu niż zespół prognozuje (forecast) i ogólne wymaganie fixed scope & fixed time na raz. Oczywiście mniej lub bardziej świadomie skończy to się burgerem z wiewiórki. Nadgodziny też są ok z punktu widzenia Product Ownera dopóki za nie nie musi płacić. Zasady frameworku Scrum nie są ważne dla niego. Bo niby dlaczego miałyby być? Dla człowieka z biznesu ważne jest, żeby zespół IT robił jak najwięcej i jak najszybciej. Metoda nie ma znaczenia. Scrum Master w takich sytuacjach powinien chronić zespół i utrzymywać framework Scrum. Ale jeśli jest to jedna i ta sama osoba, to kto pohamuje zapędy Product Ownera? Nikt.
Pierwszy raz możemy przeczytać o zakazie łączenia roli Scrum Mastera i Product Ownera w Scrum Guide wersja 2009 na stronie czwartej.
“The ScrumMaster should never be the Product Owner.”
W 2011 roku na temat łączenie roli Product Ownera i Scrum Mastera wypowiedział się jasno Ken Schwaber we wpisie Product Owners not proxies.
“The Product Owner cannot be the Scrum Master. They both have clear interests and habits. Changing their individual habits is hard. Changing them so they can see both points of view is impossible. They first have to learn the new way of doing their job with agility.”
Scrum Master i Developer
To jest najbardziej klasyczny pomysł. Bardzo często ktoś wpada na pomysł, żeby jednemu z Developerów dać dodatkową rolę Scrum Mastera. Ten pomysł idzie łeb w łeb z przydzieleniem Scrum Mastera do przynajmniej trzech zespołów na raz, bez względu na faktyczne potrzeby. Po co dodatkowy etat? Widać to czasem w ogłoszeniach o pracę z organizacji gdzie Scrum jest najwyżej na poziomie mechaniki. W wymaganiach pojawia się znajomość Microsoft Visual Studio, albo Spring itp, czyli wymóg wiedzy technicznej u Scrum Mastera. Przecież Scrum Master jeśli nie prowadzi spotkań, to nic nie robi. 15 Daily Scrum i to cała jego robota.
Spotykamy też bardzo częsty pomysł, że pełnienie roli Scrum Master to 20% czasu, więc 80% czasu zostaje na Developera. Wszystkie te pomysły wynikają z braku zrozumienia Scrum i roli Scrum Mastera. To jest dokładnie to samo magiczne myślenie, które powoduje, że managerowie przypisują ludzi do projektów lub zespołów po 33,3%. Rzeczywistość weryfikuje taką konfigurację bardzo szybko. Skutek jest taki, że Scrum Master-Developer będzie podejmował pracę w Sprincie i na przykład przypisywał do siebie zadanie ze Sprint Backlog, ale będzie miał duży problem ze skończeniem go. Kolejne spotkania i warsztaty, kolejne Przeszkody (ang. Impediment) do usunięcia będą powodowały, że pojawi się Task Switching Waste i postęp będzie niewielki. Jeśli Zespół Developerski jest zaangażowany w Sprint, to taka sytuacja będzie mu przeszkadzała. Będą woleli, żeby Scrum Master-Developer nie blokował na sobie zadań, bo to przeszkadza im w utrzymaniu odpowiedniego tempa i postępu w Sprincie. Jego praca może bardzo szybko zostać ograniczona do przeglądu kodu. U takiej osoby na koniec dnia może się pojawić poczucie “nic dzisiaj nie zrobiłem” i braku satysfakcji z pracy. Jeżeli mieliśmy do czynienia z osobą, która ma pasję do developementu, to zacznie się wypalać zawodowo. Utrzymywanie roli na siłę Scrum Master-Developera spowoduje, że taka osoba odejdzie z pracy. Mianowanie najlepszego specjalisty z zespołu na scrum Mastera spowoduje spadek wydajności całego zespołu, czasami nawet do zera. Jeśli w dodatku się wypali w nowej roli i go stracimy, to mamy bardzo duży problem.
I ponownie możemy o tym przeczytać w Przewodniku po Scrumie z 2009 roku na czwartej stronie.
“Tip: The ScrumMaster may be a member of the Team; for example, a developer performing Sprint tasks. However, this often leads to conflicts when the ScrumMaster has to choose between removing impediments and performing tasks.”
A jakie są zagrożenia? Podchodząc do sprawy stereotypowo, to można powiedzieć, że specjaliści IT nie słyną z umiejętności miękkich. Komunikacja to ich pięta achillesowa. To znaczy, że prawdopodobnie Developer w roli Scrum Mastera nie będzie wykonywał tej pracy dobrze. Nie będzie negocjował, rozwiązywał konfliktów, cierpliwie tłumaczył i uczył całą organizację. Na Retrospekcje Sprintu znajdzie sobie jeden wygodny sposób i będzie się go trzymał. Spotkania też będą odbywały się według pewnego schematu z naciskiem na wypełnienie formatek. Spojrzenie na dynamikę zespołu, budowanie środowiska itd. też nie będą widziane jako ważne rzeczy.
Jakie antywzorce i dysfunkcje możemy zaobserwować u Scrum Master-Developera? Przede wszystkim jako osoba znająca się na technologii będzie mniej lub bardziej świadomie narzucać rozwiązanie. Do tego możemy dołożyć argumentację, że “tak byłoby bardziej scrumowo”. A Scrum Master jest mistrzem Scrum, więc kto może temu zaprzeczyć? Stracimy samoorganizację. Scrum Master-Developer zna technologię, więc może też zacząć samodzielnie szacować wielkość P.B.I.. Tylko jeden krok dalej jest samodzielne zobowiązywanie się do zakresu Sprintów.
Następna dysfunkcja objawia się pielęgnacją Product Backlog w parze Scrum Master-Developer i Product Owner. Zaraz za tym idzie działanie jako przekaźnik pomiędzy Development Team a Product Ownerem. Po co Developerzy mają rozmawiać z P.O., jeśli S.M. sam może wszystko obgadać. I w ten sposób tracimy poczucie odpowiedzialności, zaangażowanie i samoorganizację zespołu. De facto w tych sytuacjach Scrum Master-Developer zachowuje się jak kiepski Project Manager.
Może też powstać duet managerski S.M. i P.O., co zaprzepaści ideę, że wszyscy w Scrum Team są równi. Wyjdzie tak jak w Folwarku Zwierzęcym u Orwella “Wszystkie zwierzęta są sobie równe, ale niektóre są równiejsze od innych.”
Kolejny antywzorzec pojawi się w sytuacji presji wywartej na zespół. Scrum Master-Developer przestanie służyć zespołowi jako Scrum Master, podwinie rękawy i skupi się tylko na pracy w Sprincie. A to może być moment, w którym Zespół Developerski najbardziej potrzebuje Scrum Mastera.
Co zrobi Scrum Master-Developer kiedy jest problem do rozwiązania lub decyzja techniczna do podjęcia. Prawdopodobnie nie powstrzyma się od zasugerowania rozwiązania. Nawet mimo chodem rzucone “Zrobiłbym tak […], ale sami zdecydujcie” wyłącza kreatywność i bottom-up knowledge. Jednym z najtrudniejszych elementów rozwoju dobrego Scrum Mastera z doświadczeniem developerskim jest oduczanie reagowania kiedy to nie jest potrzebne i akceptowania opcji, którą wybrał Zespół Developerski. Znowu Developerom może to być nawet na rękę, bo nie muszą wyjść ze strefy komfortu, ani wejść w konflikt. Natomiast niestety nie rozwiną się w ten sposób, ani nie wzmocnią procesu grupowego.
Product Owner & Developer
Ostatnia kombinacja jest rzadko spotykana, bo nie ma zbyt wiele sensu. Kiedyś niepomny założeń coachingowych powiedziałem “prędzej spotkam jednorożca niż taką kombinację” i odezwał się uczestnik szkolenia na wprost mnie, że właśnie jest kimś takim. Z perspektywy czasu nadal wątpię, że był tam element Product Ownera. Ten uczestnik był analitykiem. Product Owner powinien być przedstawicielem biznesu. Powinien mieć wiedzę o działaniu produktu, potrzebach interesariuszy, rynku i użytkownikach oraz władzę w samodzielnym podejmowaniu decyzji. Trudno, żeby analityk biznesowy czy systemowy spełniał te kryteria. Czy przygotowywanie Product Backlog może naprawdę być uważane za pracę developerską? Według mnie nie. Czy taka osoba będzie posiadała umiejętności wyznaczania porządku na Product Backlogu i negocjacji z interesariuszami? Bardzo rzadko.
Jakie dysfunkcje i antywzorce można w tej sytuacji obserwować? Product Owner-Developer tworząc PBI będzie myślał technologią zamiast biznesem i narzucał rozwiązania. User Story w stylu “Jako Product Owner chcę mieć pole tekstowe o długości 32 znaków” będą pojawiały się dosyć często. Obowiązki Product Ownera zajmą tyle czasu, że zabraknie czasu na pracę w Zespole Developerskim i wypełnienie tego zobowiązania. Znowu podobniej jak Scrum Master-Developer, Product Owner-Developer będzie samodzielnie szacował, rozpisywał zadania i naciskał na obniżenie oszacowań.