Wyobraźmy sobie taką sytuację – mamy organizację IT, która tworzy jakiś produkt. Z jakiś względów chcemy do rozwoju tego produktu używać frameworka Scrum. Ale w rozwój produktu jest zaangażowanych wielu ludzi – tak więc na horyzoncie pojawia się słowo: skalowanie. Musimy zastosować Scrum w środowisku, w którym jest wiele zespołów.
Zwykle bywa tak, że na początku z naszej drogi radośnie zabieramy się do pracy i wymyślamy pewne struktury. Pojawiają się zespoły, ludzie dostają odznaki PO lub SM, w kalendarzu pojawiają się wydarzenia… Ale prędziej czy później pojawi się pytanie: „hej, a kto jest odpowiedzialny w naszym świecie za dostarczanie zmian?”. I często nie jest wcale prosto na nie odpowiedzieć…
Zróbmy sobie dla potrzeb tego tekstu kilka uproszczeń. Załóżmy, że mamy tylko dwa zespoły. Załóżmy, że te zespoły są dobrze zdefiniowane, mają swój zakres odpowiedzialności, są cross-funkcjonalne (czyli potrafią samodzielnie wytworzyć coś użytecznego) i mają swojego Product Ownera.
Jeżeli każdy z zespołów ma swojego Product Ownera, to często pojawia się pytanie „hej, a kto zarządza rozwojem całego produktu?” – i często pojawia się wtedy rola osoba, która nosi dumny tytuł „Chief Product Owner”, „Super Duper Product Owner” bądź „Product Manager”.
Tutaj mała dygresja: w tym momencie wielbiciele frameworku SAFe mówią „tak, tak, tak!”, natomiast wielbiciele frameworku LeSS lub Nexus protestują „pomyliliście zupełnie nazwy, ten wyższy to jest prawdziwy Product Owner, a niższego wcale nie powinno tutaj być, bo to nie jest PO”. Ale dzisiaj nie wchodzimy w te dyskusje, mamy obrazek taki, jaki mamy:
Moje doświadczenie jest takie – taki układ może działać całkiem sprawnie, jeżeli rzeczy do zrobienia trafiają niezależnie obu backlog’ów obu zespołów i jeżeli zespoły są w stanie dostarczać te zmiany niezależnie od siebie. Wtedy PO obu zespołów ustawiają elementy w swoich backlogach, a zespoły przerabiają elementy tychże backlogów na działający produkt:
Na obrazku mamy zaznaczone trzy aktywności: (1) jakaś funkcjonalność czy zlecenie zmiany wpada do backlogu zespołu. (2) zespół bierze funkcjonalność do wykonania w bieżącym sprincie. (3) zespół dostarcza zmianę do produktu. Oczywiście trzeba jakoś ogarnąć kwestię integracji zmian z obu zespołów, ale są tutaj duże szanse na powodzenie.
Problem zaczyna się wtedy, gdy na horyzoncie pojawiają się duże zmiany, które muszą być wykonane przez obydwa zespoły. Czyli nasz obrazek będzie wyglądał mniej więcej tak jak poniżej – mamy duże zmiany do wprowadzenia, które wpadają na wspólną listę i muszą być dekomponowane na mniejsze zmiany dla zespołów. Pojawiają się wtedy również zależności między zespołami…
Czyli nasz świat wygląda teraz tak – w uproszczeniu, bo w rzeczywistości często tych zespołów jest więcej niż dwa.
Z reguły w tym momencie pojawia się również trudne pytanie: „hej, a kto jest odpowiedzialny za dostarczenie takich dużych zmian?”
Ale czym jest ta odpowiedzialność?
Zatrzymajmy się na moment nad tym pytaniem. Jest w nim zawarte słowo „odpowiedzialność”, które może być bardzo różnie zrozumiane. Możemy je rozumieć jako:
- odpowiedzialność za przekazanie zespołom informacji, że ta zmiana jest ważna i trzeba nad nią pracować albo na kiedy trzeba ją wykonać
- odpowiedzialność za zagwarantowanie że zmiany wykonane przez zespoły pokryją wszystkie wymagania lub rzeczy do zrobienia (żeby nie było tak, mieliśmy zbudować samochód, a na końcu okazuje się, że mamy podwozie, karoserię, ale nikt nie pomyślał o zbudowaniu silnika…)
- odpowiedzialność za to, że zespoły przekażą sobie, co jest im potrzebne i będą się na bieżąco ze sobą komunikować
- odpowiedzialność za to, że wszystkie zespoły zakończą pracę na czas
- odpowiedzialność za raportowanie, czyli dostarczanie jasnej informacji o tym, gdzie jesteśmy i kiedy powinniśmy skończyć
Spędziłem dość dużo czasu w organizacjach, w których te odpowiedzialności były skupione w osobie Project Managera. Taki Project Manager nawet jeżeli nie robił tego wszystkiego sam, to upewniał się, że zostało to wykonane. Czyli dzień w dzień sprawdzał różne rzeczy. Czy wiemy co robimy i dlaczego to robimy. Czy wszystkie wymagania i potrzeby są zaadresowane. Czy zaangażowane osoby mają wszystkie niezbędne informacje. Czy prace postępują w odpowiednim tempie. I tak dalej, i tak dalej….
Ale halo, halo, mamy XXI wiek, mamy zwinność, mamy samoorganizację, mamy turkus, nasi Project Managerzy porobili już certyfikaty SAFe’owe, musimy zrobić to teraz inaczej!
Inaczej – ale jak?
Odpowiedzialności mają granice
Zauważmy jeszcze jedną rzecz. Jeżeli myślimy o odpowiedzialności – to przeważnie mamy w głowie jakieś granice tej odpowiedzialności. Bohater pewnego filmu krzyczał: „No tak, a nie odpowiadamy tylko za trzęsienia Ziemi gradobicie i koklusz!” – czyli postawił jakieś granice swojej odpowiedzialności.
Jeżeli jestem odpowiedzialny za dostarczenie jakiejś funkcjonalności, to mogę czuć się odpowiedzialny na tyle, żeby pracować nad nią w godzinach pracy – a mogę czuć się na tyle odpowiedzialny, żeby pracować nad nią również po godzinach. Jeżeli jestem odpowiedzialny za uzyskanie jakiejś informacji, – to mogę napisać maila (i uznać, że sprawa załatwiona) – ale też mogę zadzwonić.
Popularne kiedyś hasło „I want you to go the extra mile” oznacza nie tylko oczekiwanie bardziej intensywnej pracy, ale również oczekiwanie, że ktoś będzie poszerzał granice swojej odpowiedzialności.
Przerzucanie gorącego ziemniaka
Wróćmy teraz do naszego przykładu!
Organizacje, które próbują odpowiedzieć na pytanie „to kto jest teraz odpowiedzialny za dostarczenie dużych zmian?”, przeważnie zaczynają od próby przeniesienia starego sposobu pracy do nowej rzeczywistości. Czyli szukamy pojedynczej osoby, która w nowym świecie będzie nam pokrywała dotychczasową rolę Project Managera. Ale – ciekawa rzecz! – kiedy zaczynamy o tym rozmawiać, bardzo często te rozmowy przypominają przerzucanie się gorącym ziemniakiem. Nikt tak naprawdę nie chce go przygarnąć…
Często na początku pojawia się koncepcja, aby to ChiefPO, jako starszy nad armatą, był odpowiedzialny za dostarczenie całej funkcjonalności. Ale ChiefPO bardzo często mówi: „hej, ale ja jestem od strategii i koncepcji, to nie jest moja funkcja żeby sprawdzać czy zespoły się ze sobą dogadały”. Musimy szukać dalej.
Jak nie ChiefPO, to może zwykły, zespołowy PO? Ale który, bo jest ich wielu? Pojawia się tutaj czasami koncept „LeadPO” – czyli za dostarczenie funkcjonalności X będzie odpowiedzialny ten Product Owner, którego zespół dostarcza największą część tej funkcjonalności. Albo który po prostu miał pecha przy ciągnięciu zapałek… Product Ownerzy zwykle mają to do siebie, że są odpowiedzialni i im zależy na rozwiązaniu, więc nie protestują tylko biorą nowy obowiązek na swoje barki. Widziałem koncept „LeadPO” w trzech różnych organizacjach. W żadnej z tych trzech organizacji nie działało to dobrze.
Jak nie Product Owner, to może Scrum Master? Przecież to jest osoba, która jest liderem zespołu… Scrum Masterzy reagują różnie. Z jednej strony często pomagają zespołom w dogadywaniu się i dostarczaniu zmian – ale z drugiej strony często reagują alergiczne, kiedy pojawia się zdanie „to ty musisz dopilnować, żeby rzeczy były zrobione na czas”. Często mówią wtedy coś o złożoności, o odpowiedzialności zespołu, o empiryzmie – i z reguły nikt tego za bardzo nie rozumie… Jasny jest tylko fakt, że nie chcą wziąć tej odpowiedzialności na siebie.
Czasami pojawia się jeszcze jeden pomysł. To może wróćmy do starej, dobrej koncepcji i wyciągnijmy z szafy tego Project Managera? Niech zespoły zajmą się dostarczaniem swoich kawałków funkcjonalności, a nad nimi postawmy kogoś odpowiedzialnego za dogadywanie się, synchronizację i dostarczanie w terminie?
To kto powinien być odpowiedzialny? Osoba czy zespół?
Współpracowałem z Project Managerami, którzy wykonywali naprawdę świetną robotę. Komunikowali. Zbierali dane. Synchronizowali. Dbali o jasność komunikacji. Wyciągali sprawy na światło dzienne. Pytali „czego jeszcze potrzebujesz?”. I robili to z dużym zaangażowaniem. Mam dużo szacunku dla ich wysiłku!
Ale obserwowałem też takie zjawisko, że dużemu zaangażowaniu Project Managera towarzyszyło zmniejszenie się zaangażowania zespołu i „zamknięcie się” zespołu w granicach wytwarzanego przez nich komponentu. Donald Reinertsen opowiadał kiedyś historię o wizycie w dwóch fabrykach tworzącej części do samolotów. W pierwszej z nich pracownicy na pytanie „co tutaj robicie?” odpowiadali, że projektują układ hydrauliczny wspomagający hamowanie. W drugiej na to samo pytanie padła dumna odpowiedź: „my projektujemy Boeinga 777!”.
Wielu zespołom dużo bliżej do tego pierwszego obrazka – tworzymy swój komponent i czujemy się odpowiedzialni za to, żeby działał poprawnie.
Układ, w którym jedna osoba jest odpowiedzialna za dostarczenie, jest układem prostszym do stworzenia i zarządzania. Ale kryje on niebezpieczeństwo polegające na tym, że ludzie tworzący rozwiązanie skupiają się wyłącznie na dostarczeniu swojego kawałka pracy.
Czy to źle? To zależy. Jeżeli jesteśmy pewni, że możemy rozłożyć naszą pracę na części i po złożeniu ich razem wszystko będzie poprawnie działać – to taka dekompozycja może działać całkiem sprawnie. Ale jeżeli nasza rzeczywistość się zmienia bardzo szybko, jeżeli zmieniają się wymagania odbiorcy, jeżeli potrzebne są ustalenia między zespołami – to zamknięcie się w granicach swojego komponentu może mieć bardzo smutne konsekwencje. I bardzo często wtedy pojawia się magiczne zdanie „Nie wiem, czemu fa funkcjonalność nie działa u klienta. Mój komponent działa poprawnie”.
Zrozumienie DLACZEGO robimy pewne rzeczy bardzo pomaga w podejmowaniu trafnych decyzji w zmieniających się warunkach i okolicznościach.
Jeden za wszystkich, wszyscy za jednego!
Scrum Guide mówi jasno i dobitnie: „Cały Scrum Team ponosi odpowiedzialność za wytworzenie wartościowego, użytecznego Incrementu co Sprint”. Znajdziemy w tym frameworku również pewną dekompozycję tych odpowiedzialności:
- Product Owner jest odpowiedzialny za określenie co ma być zrealizowane oraz w jakim celu to robimy
- Deweloperzy są odpowiedzialni za stworzenie i dostarczenie działającego rozwiązania
- Scrum Masterzy są odpowiedzialni za pomoc zespołowi w tworzeniu używalnego przyrostu
Mamy więc tutaj odpowiedzialność zbiorową (ze wskazaniem za jakie aspekty pracy odpowiadają poszczególne osoby), a nie odpowiedzialność pojedynczej osoby.
I kiedy rozmawiam o tym modelu, widzę w moich rozmówcach dwie różne reakcje. Są osoby, które mówią: „o, to jest super pomysł, chciałbym tak pracować”. I są osoby, które mówią: „nie ma mowy, bez jednej, konkretnej osoby odpowiedzialnej za dostarczenie to podejście nie zadziała. To się nie uda”.
Dlaczego to jest takie trudne?
W przeszłości, kiedy słyszałem słowa „to się u nas nie uda”, to bardzo łatwo było mi łączyć to zdanie z podejrzeniem niedojrzałości zespołu („ten zespół jeszcze nie dojrzał do wzięcia odpowiedzialności”) lub z podejrzeniem niedojrzałości menedżerów („ta osoba nie chce przekazać odpowiedzialności zespołowi”). Teraz coraz częściej dostrzegam, że trudności we wzięciu odpowiedzialności wynikają z tego, że organizacje, projekty czy też produkty są zaprojektowane w pewien określony sposób.
No bo trudno jest mówić o tym, że „jako zespół XYZ weźmiemy na siebie odpowiedzialność za dostarczenie” jeżeli nie wiem, w jakim celu wykonujemy swoje zadania. Trudno jest brać odpowiedzialność, jeżeli termin dostarczenia został narzucony z góry i uważamy go za kompletnie nierealny. Trudno jest brać odpowiedzialność, jeżeli brakuje w zespole jakieś kompetencji, a nie mamy wpływu na strukturę zespołów. Trudno jest brać odpowiedzialność, jeżeli do dostarczenia potrzebujemy zmian od innego zespołu czy też zewnętrznego dostawcy i nie mamy wpływu na terminy dostarczenia tych zmian. Trudno jest brać odpowiedzialność, jeżeli po wykonaniu zmiany nadajemy ją gołębiem pocztowym w nadziei, że w następnym kwartale znajdzie się ona na produkcji. I jeszcze pewnie sporo trudności udałoby się znaleźć…
Tak więc wdrażanie frameworku Scrum to nie tylko wdrażanie wydarzeń i artefaktów – ale również przekazanie odpowiedzialności za dostarczanie zmian z pojedynczej osoby do zespołu lub wielu zespołów. I nie jest to zmiana ani szybka, ani łatwa…
Dwa pytania
Wypadałoby zakończyć ten tekst jakąś puentą – ale zamiast niej będą dwa pytania, które są dla mnie ważne. Lubię zadawać te pytania ludziom i zespołom, z którymi pracuję.
Pierwsze pytanie: jeżeli mówisz „odpowiedzialność za dostarczenie”, to co konkretnie masz na myśli?
I drugie: co najbardziej przeszkadza tobie lub twojemu zespołowi w podjęciu tej odpowiedzialności?
Odpowiedź na pierwsze pytania pozwala nam lepiej się zrozumieć. Odpowiedź na drugie – pozwala zwiększyć swój zakres odpowiedzialności.
W poukładaniu w głowie pewnych rzeczy dotyczących odpowiedzialności bardzo pomogła mi rozmowa z Mariuszem Petlicem – dzięki serdeczne!