Nasza rola w projekcie scrumowym nie ma znaczenia! Wszyscy tak mówią, ale czy faktycznie tak jest? Czy stanowisko, które zajmujemy nie predysponuje nas do czucia się ważniejszymi od innych? Dziś spróbujemy odpowiedzieć na pytanie, czy istnieje coś takiego jak hierarchia w Scrum.
Hierarchia w Scrum
Scrum Guide, czyli wyrocznia zasad stosowanych w Scrum, nie definiuje jak powinna wyglądać hierarchia w zakresie poszczególnych ról scrumowych. Nie znajdziemy w nim żadnych sugestii co do tego, że jedna z ról jest ważniejsza od drugiej. Dlaczego więc często uważa się, że Product Owner czy Scrum Master są ważniejsi od członków Development Teamu?
Próbowaliśmy kiedyś, w ramach dyskusji o najważniejszej roli Scrum, odpowiedzieć sobie na tak postawione pytanie. Zachęcamy do zapoznania się z naszymi rozważaniami na ten temat, bo nie jest to wcale uniwersalny pogląd.
Na prowadzonych przez nas szkoleniach i warsztatach zawsze wspominamy o „płaskiej hirerachii Scrum”. Często też napotykamy na wygłaszane wątpliwości. Niektóre z nich mogą wynikać z tego, że wczytując się w Scrum Guide znajdziecie, między innymi, następujące cytaty:
„Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu…”
„… osoby chcące zmienić priorytet elementu Backlogu Produktu, muszą zwrócić się do Właściciela Produktu.”
„… cała organizacja musi respektować jego decyzje” – Scrum Guide
„Ja jestem najważniejszy!”
Zdarza się, że Product Owner lub Scrum Master są traktowani jak wyrocznie.
Powodów takiego stanu rzeczy może być wiele i dużo tu zależy od osobowości ludzi, których mamy w Zespole Deweloperskim. Różnice pomiędzy zespołem biernie oczekującym na zadania do realizacji, a tym aktywnie żyjącym backlogiem będą oczywiste. W tym drugim przypadku istnieje mniejsza szansa na zaistnienie „problemu” hierarchii.
W zespole wymagającym prowadzenia za rękę, osoba na stanowisku PO czy SM będąca przełożonym może być zbawieniem. Zespół ten przecież czeka na wyznaczenie kolejnych zadań. To oczywiście tylko pozorna korzyść, bo dla biernego zespołu nie ma przecież miejsca w metodykach agile. To z kolei sugeruje nam, że mamy problem i to fundamentalny. Problem z agile mindset.
Inaczej spojrzymy na sytuację, w której pracujemy z aktywnym zespołem gotowym do realizacji nawet najtrudniejszych zadań. Zespołem świadomym swoich umiejętności i metodyki. W takim, osoba narzucająca wykonanie jakiegoś zadania w określony sposób będzie odebrana bardzo negatywnie. Bo przecież nie ma hierarchii w Scrum! Zespół Deweloperski jest przecież samoorganizujący się.
Interesariusz
A może to interesariusz albo odbiorca naszej pracy powinien być traktowany jako pośredni przełożony? Oczywiście nie będzie on odpowiedzialny za skład zespołu, sprawy HR-owe czy zasobowanie na naszym projekcie. Klient ma jednak swoje wymagania i oczekuje produktu dostarczającego mu wartości biznesowej.
Interesariusz to często osoba, która w hierarchii firmy zajmuje np. stanowisko managerskie. Zdarza się, choć nie powinno, że z pominięciem Product Ownera przyjdzie do zespołu realizującego i poprosi o realizację niezbędnego z jego punktu widzenia w danym czasie wymagania. Co w takiej sytuacji powinniśmy zrobić? Odmówić wykonania zadania, czy przyjąć je i wbrew ustalonym priorytetom rozpocząć jego realizowanie?
Odpowiedź jest oczywista – samodzielnie bądź przy pomocy Scrum Mastera skierować go do naszego Product Ownera, żeby wyjaśnił z nim kwestie kolejności realizowania wymagań. Nie jest to jednak łatwe, jeśli ktoś czuje się „ważniejszy”.
Zespół, a nie hierarchia
Jako #białko stoimy na stanowisku, że każda z ról w Scrum jest tak samo istotna. Żadna z nich – Scrum Master, Product Owner, Zespół Deweloperski – nie może istnieć bez pozostałych, które z jednej strony pomagają jej w wykonywaniu obowiązków, z drugiej strony dostarczają jej zadań, a z trzeciej konsumują wyniki jej pracy. Te zależności występują w każdą stronę.
Nie potrafię sobie wyobrazić projektu, na którym pracuje wyłącznie Zespół Deweloperski. Że o samym SM bądź PO nie wspomnę. Bez rozdwojenia (roztrojenia?) jaźni nie jest możliwe wykonywanie wszystkich zadań roli SM i PO dbając jednocześnie o wytworzenie wartościowego Inkrementu. Podział zadań na 3 role dowiódł swojej słuszności, o czym świadczyć może poniższy fragment:
„Model zespołu proponowany w Scrumie został zaprojektowany tak, aby optymalizować elastyczność, kreatywność i produktywność. Taki model Zespołu Scrumowego dowiódł swojej rosnącej skuteczności w wymienionych uprzednio przypadkach oraz każdym innym rodzaju złożonej pracy” – Scrum Guide
Za sukces jest odpowiedzialny cały zespół. Osiągajmy go więc jako zgrany Scrum Team i bądźmy świadomi tego, że gramy do jednej bramki. Jeżeli każdemu z nas zależy na zadowoleniu naszego klienta, to powstające rozwiązania będą spójne, efektywne i przydatne.
A jeśli czujemy nieodpartą chęć bycia przywódcą… pozostają nam dwie drogi: zmiana pracy albo zrozumienie tego, po co tutaj jesteśmy.
