Ograniczenia w dostępności członków Zespołu Scrumowego oraz rozwój wielu produktów w jednym czasie.

Dlaczego postanowiłam te dwa zagadnienia połączyć w jednym artykule? Pozornie są niezależne, jednak dla mnie łączy je jedno słowo – PRIORYTETYZACJA!  Poniżej postaram się rozwinąć tę ideę.

Zdarza się, że członkowie Zespołów Scrumowych, z którymi współpracuję mierzą się z problemem, który powraca w rozmowach podczas Planningu. Chodzi o dylematy i pytania typu: „Czym mamy się aktualnie zajmować i w jakiej kolejności? Czy ważniejsza jest nasza praca dla Scrum Teamu czy może inne inicjatywy, w które jesteśmy zaangażowani a może nasze BAU?”. Schody zaczynają się wtedy, gdy na te pytania nie ma jasnych odpowiedzi lub gdy z różnych źródeł otrzymujemy rozbieżne komunikaty.

Zacznijmy od rozwinięcia tematu zaangażowania Scrum Teamu w wiele różnych zagadnień w jednym czasie. Może znacie tę pokusę organizacji, by wykorzystać potencjał zespołu i skupić jego prace wokół więcej niż jednego produktu. Apetyt na dodatek rośnie w miarę jedzenia. Niestety nie bez przykrych konsekwencji. Kłania się nam jedno z przykazań Kanban – limituj pracę w toku! Scrum też nie bez powodu mówi, by skupić się na rozwoju jednego produkt. Dlaczego? Zjednoczenie wokół wspólnego celu spaja zespół i koncentruje jego wysiłki wokół tego, co najważniejsze i co daje największą wartość biznesową. Przeciwnie dzieje się w Scrum Teamach, które nie mają komfortu pracy przy rozwoju jednego produktu. W ramach zespołu tworzą się podziały i napięcia związane z potrzebą ciągłego czuwania nad utrzymaniem odpowiednich priorytetów. Różne produkty wiążą się także z koniecznością współpracy z interesariuszami z różnych obszarów organizacji, których interesy nieraz bardzo trudno pogodzić. Przeciążeni ilością interakcji, powiązań i zależności Produkt Ownerzy tracą entuzjazm oraz wiarę w słuszność działania organizacji. I mają rację, bo trzymając kilka srok za ogon tylko pozornie dostarczamy więcej. W praktyce niestety dostarczamy mniej. Niska efektywność to jeden z kosztów takiego działania. Marnotrawienie czasu na przełączanie się między tematami, zarządzanie konfliktami, pilnowanie zależności to strata dla organizacji.

W ekstremalnych przypadkach, gdy zespół jest dedykowany do wielu różnych działań, mamy do czynienia z rozpadem zespołowości na rzecz pracy indywidulanej jego członków. Planowanie jest wtedy potwierdzeniem planów działania poszczególnych osób lub podgrup a Backlog – zbiorem nie powiązanych produktowo inicjatyw. Zespół ma trudność w określeniu Celu Sprintu, gdyż w tym samym czasie realizuje kilka inicjatyw, o takim samym priorytecie.

Takich scramowych patologii należy unikać. Warto jednak o nich mówić, by zwiększać świadomość ich negatywnego odziaływania. Część organizacji wdrażając Scruma skupia się na budowaniu zespołów i implementacji metod, nie wprowadzając zmiany w podejściu do priorytetyzacji. Szkoda, bo ucząc się zarządzania priorytetami w oparciu o wartość biznesową zyskujemy pewność, że aktualnie pracujemy tylko nad tym, co najważniejsze.

W tym momencie trzeba wspomnieć o roli Product Ownera. To on powinien decydować o tym, które PBI będziemy realizować oraz w jakiej kolejności. W zakresie priorytetyzacji powinien być jedynym źródłem wiedzy dla Deweloperów. Sytuacja staje się trudna, gdy członkowie Scrum Teamu pracują w nim na część etatu. W takiej sytuacji informacje na temat tego, czym się będą zajmować spływają nie tylko od Product Ownera. Dodatkowe zadania spływają od innych osób – chapter lidera, tribe lidera, szefa departamentu, klienta lub samego prezesa, któremu trudno jest przecież odmówić 😉 Jak w takiej sytuacji pracownik i cały Scrum Team mają zarządzić priorytetami? Jedyna nadzieja w tym, że wyżej wymienione osoby zlecające prace są w stanie porozumieć się w kwestii priorytetów. Jest to pewien kompromis, który generuje koszt w postaci czasu poświęconego na zarządzenie tą sytuacją. Przewidywalność zespołu z ograniczeniami w kontekście dostępności jego członków jest dużo niższa a dotrzymanie zobowiązań tym mniej realne, im większa jest zmienność w dostępności ludzi. Wyobraźmy sobie sytuację, w której jeden z członków zespołu pracuje jeszcze dla dwóch innych Scrum Teamów. Dodatkowo wykonuje   zadania BAU stanowiące 20% całego czasu pracy. Jeśli jest obowiązkowy i pojawia się na wszystkich ceremoniach we wszystkich 3 Zespołach Scrumowych, to ile czasu pozostaje mu na realizację zadań? Z drugiej strony, jeśli wpada tylko na chwilę i włącza się jedynie, gdy jest mowa o jego obszarze kompetencji, to co wnosi do zespołu poza dostarczeniem wyodrębnionego elementu funkcjonalności lub kodu? To przykład funkcjonujący w organizacjach, które są produktowe tylko z nazwy. Operacyjnie działają bowiem w oparciu o założenia projektowe. I znowu wracamy do tematu dużego apetytu organizacji do wdrażania wielu zmian w jednym czasie, nie zwracając uwagi na ograniczoną ilość pracowników i ich kompetencji

Nie jestem zwolennikiem skrajnych rozwiązań. Nie uważam, że w Backlogu nie możne znaleźć się nic poza tym, co rozwija produkt. Podobnie nie uważam, że każdy członek zespołu musi pracować wyłącznie na rzecz Scrum Teamu. Trzeba jednak wyraźnie zaznaczyć, że przekroczenie pewniej granicy w naginaniu Scruma do realiów organizacji przekreśla sens stosowania frameworku. Dla przykładu zastanówmy się, czy szacowanie w zespole, w którym połowa składu jest zaangażowana na 50% będzie miarodajne? Dostępność członków zespołu jest w tym przypadku warunkowana ogromną ilością zmiennych. Czy ma więc sens podejmowanie takiej próby? Oczywiście możemy przyłożyć się mocno do capacity planningu, ale to też przecież nie daje nam żadnej gwarancji. Dobrze wiemy, że dostępność 50% przy zmiennych priorytetach potrafi skurczyć się nawet do zera. Jeśli mamy do czynienia z takim przypadkiem warto zacząć prezentować interesariuszom zaangażowanie zespołu. Najlepiej robić to w podziale na rozwój produktu i inne prace (na przykład utrzymaniowe) a także uwzględniając deklarowaną i faktyczną dostępność członków zespołu. Dane prezentowane systematycznie powinny uświadomić wady założenia oraz być impulsem do zmiany.

Spotkałam się z opiniami, że dzielenie się pracownikami między zespołami to naturalny proces tworzenia zespołów scrumowych. Jego członkowie nie od razu są oddelegowani do pracy w Scrum Teamie na 100%. Nawet jeśli tak jest, to organizacja jeszcze przez jakiś czas angażuje te osoby w realizację zadań nie związanych z rozwojem konkretnego produktu. Dzieje się tak z przyzwyczajenia lub z braku innych pracowników o specyficznych kompetencjach. Nie jest dobrze, gdy taki stan się przeciąga. Jeszcze gorzej, gdy staje się permanentny i akceptowany w organizacji. Jeśli zespół na stałe realizuje wiele różnorodnych tematów, nie ma zagwarantowanego, niezmiennego i przewidywalnego składu, to warto zastanowić się czy Scrum tu w ogóle pasuje? A może organizacja oczekuje innego rodzaju efektywności, który nie wpisuje się w założenia Scruma? Zawsze warto rozważyć, czy nie chodzi nam po prostu o to, by zlecana praca była kolejkowana oraz realizowana przez zespół, jak najszybciej, przy uwzględnieniu znanych i respektowanych priorytetów? Wykorzystanie Kanbanowych narzędzi wizualizacji, synchronizacji i limitowania pracy w toku może okazać się w takim przypadku wystarczające. Jednak fundamentem powodzenia tej i każdej innej metody pracy zwinnej jest dbałość o odpowiednią priorytetyzację. Taką, która jest skorelowana ze strategią organizacji, w transparentny sposób komunikowana i respektowana.