Punkty widzenia
Pięć oznak, które występują w organizacjach tylko pozornie zwinnych (agile)
Zwinne organizacje – blog o Agile
Można już dzisiaj z przekonaniem powiedzieć, że nomenklatura wprowadzona przez agile, w szczególności Scrum, na stałe zadomowiła się w polskich organizacjach. Prawie wszyscy pracujemy w sprintach, co dwa tygodnie przeprowadzamy statusy, nie, przepraszam – sesje planistyczne, korzystamy z pakietów systemów do zarządzania zwinnego typu Jira, a na korytarzach spotykamy się z Product Ownerami. Niemniej jednak w wielu przypadkach zmiany wprowadzone do modelu operacyjnego organizacji są powierzchowne i nie przynoszą oczekiwanych rezultatów w postaci dostarczania klientowi końcowemu przyrostów wartości w krótkim czasie. Niniejszy artykuł przedstawia pięć często powtarzających się oznak, które wskazują na to, że organizacja jest jedynie pozornie zwinna.
Oznaka 1: Wszyscy pracujemy w sprintach (ale w zespołach funkcjonalnych)
Zdecydowana większość organizacji, które rozpoczęły swoją przygodę z agile nie zmieniała w związku z tym sposobu projektowania swoich struktur. Nadal dominującą jednostką organizacyjną w przedsiębiorstwach jest zespół funkcjonalny, czyli składający się z osób wykonujących tę samą pracę, przykładowo z projektantów UX. Oznacza to, że do realizacji danego projektu (budowy nowego przyrostu produktu) wymagana jest współpraca wielu zespołów. W momencie, gdy każdy z tych zespołów pracuje w swoim własnym rytmie, koordynacja takiego projektu staje się bardzo skomplikowanym przedsięwzięciem. Dochodzi do sytuacji, w których projekt jest zablokowany, ponieważ tzw. Product Owner (nie jest to jednak Product Owner z definicji Scrum) spóźnił się ze zgłoszeniem zadania do jednego z zespołów i musi poczekać kolejne dwa tygodnie na kolejną sesję planistyczną. W organizacjach tego typu istnieje również tendencja definiowania bardzo rygorystycznych warunków wejścia do sprintu zespołu funkcjonalnego oraz niedopuszczania pracy niezaplanowanej na początku sprintu, co również prowadzi do zmniejszenia tempa projektu, a zatem do rzadszego dostarczania klientowi nowej wartości.
| Opisana oznaka jest często spotykanym wyzwaniem w dużych organizacjach, których produkty wymagają pracy wielu ludzi, przy różnych komponentach, składających się na architekturę całego rozwiązania. Aby taka organizacja mogła sprawnie działać zgodnie z pryncypiami agile, zarządzający powinni zastanowić się nad modelem koordynacji pracy zespołów. Dobrym punktem wyjścia mogą być metody skalowania agile takie jak SAFe oraz LeSS. Obydwie metodyki kładą nacisk na cross-funkcjonalne zespoły wytwórcze, ale można w nich również znaleźć dobre praktyki koordynacji bardziej tradycyjnych zespołów pracujących nad jednym projektem lub produktem. |
Oznaka 2: Bierzemy udział we wszystkich wydarzeniach Scrum (ale są one stratą czasu)
Wprowadzenie wydarzeń Scrum jest jedną z najprostszych zmian, które są przeprowadzane w organizacjach przechodzących na zwinny model pracy. Jednak w wielu przypadkach czas na spędzony na tych spotkaniach nie jest produktywny. Istnieją dwie główne przyczyny takiego stanu rzeczy – brak samoorganizacji oraz brak cross-funkcjonalności. Jest tak ponieważ Scrum działa jak naczynia połączone, a zdefiniowane wydarzenia zostały opracowane właśnie z myślą o zespołach cross-funkcjonalnych i samoorganizujących się. Jeżeli nie zostaną spełnione podstawowe założenia dla zespołu, czas spędzony na spotkaniach można zaksięgować jako stratę.
Członkowie zespołów, które nie mogą się samoorganizować, tj. mają z góry narzucony zakres prac i sposób jej realizacji, będą mocno sfrustrowani koniecznością uczestnictwa w wydarzeniach Scrum. Jeżeli muszą podążać za z góry określoną i sztywną roadmapą, planowanie ma ograniczony sens, a review nie przynosi wartości w postaci nowych pomysłów, które trafią do backlogu. Po co przeprowadzać retrospektywę, jeżeli zespół nie ma wpływu na konfigurację, w której pracuje? Jak widać, w zespołach niesamoorganizujących się wydarzenia Scrum zaczynają pełnić funkcję kontrolną, zamiast wspierać główne filary agile, czyli inspekcję i adaptację.
Przeprowadzanie wydarzeń Scrum w zespołach funkcjonalnych, których członkowie pracują równocześnie nad wieloma różnymi projektami również jest stratą czasu. W takich przypadkach planowanie ogranicza się do sprawdzenia, czy wszyscy są w odpowiedni sposób zutylizowani, na review nikt nie jest zainteresowany pracą swoich kolegów i koleżanek, a na retrospektywach nie ma o czym rozmawiać, ponieważ współpraca jest ograniczona do korzystania ze wspólnej bazy wiedzy w danym obszarze funkcjonalnym.
| Aby czas pracowników spędzony na wydarzeniach Scrum był produktywny, kierownictwo organizacji powinno odejść od zarządzania opartego o wydawanie poleceń i kontrolowanie, na rzecz modelu opartego na zaufaniu i wartościach, np. model Zarządzania 3.0 Jurgena Apello. Uwagi wymaga również struktura organizacyjna – jej kształtowanie powinno iść w kierunku tworzenia zespołów cross-funkcjonalnych, które mogłyby niezależnie zarządzać swoim backlogiem. |
Oznaka 3: Mamy Product Ownera (ale nie może on podejmować decyzji)
Wprowadzenie nowych tytułów w organizacji jest kolejną dość prostą zmianą, na którą decyduje się wiele organizacji starających się przejść na nowy model operacyjny. Niemniej jednak, by praca w systemie Scrum mogła przebiegać sprawnie Product Owner powinien posiadać pewną charakterystykę. Niestety, bardzo często Product Ownerzy nie mają umocowania do podejmowania decyzji kierunkowych dotyczących ich produktów, przez co często backlog nie jest przygotowany do sesji planistycznej, co z kolei powoduje obniżenie tempa pracy. W takiej sytuacji poziom motywacji Product Ownera również spada. Podobny problem zachodzi, gdy Product Owner ze względu na natłok innych obowiązków nie jest w stanie poświęcić backlogowi i zespołowi wystarczająco dużo czasu.
| W Scrum Guide czytamy: „Aby Właściciel Produktu mógł odnieść sukces, cała organizacja musi respektować jego decyzje”. To śmiały krok dla wielu organizacji, ale absolutnie niezbędny, by korzyści płynące z agile mogły być zrealizowane. By kierownictwo miało komfort oddania decyzyjności w ręce jednej osoby, należy stworzyć odpowiednie warunki i wyznaczyć ograniczenia. Kluczem do sukcesu jest zbalansowanie kwestii czasu poświęcanego zespołowi oraz umocowania w organizacji. |
Oznaka 4: Co dwa tygodnie prezentujemy nowy przyrost (ale kolejne wydanie produkcyjne będzie za 6 miesięcy)
Kolejnym wyzwaniem dla młodych organizacji zwinnych jest podejście do definicji zakresu projektu, czy kolejnego przyrostu produktu. W naszych przedsiębiorstwach dalej często pokutuje przekonanie, by możliwie jak najszerzej definiować zakres, „tak na wszelki wypadek”. Taka sytuacja występuje również często w sytuacjach, gdy dany produkt będzie wykorzystywany przez wiele różnych typów użytkowników, co powoduje chęć zaadresowania wszystkich wymagań na raz. W wyniku takiego przeświadczenia nadmuchujemy zakres naszych projektów, przez co dużo rzadziej udostępniamy użytkownikom nową wartość i nie korzystamy z ich opinii w celu kształtowania produktu. Ponadto, podejmujemy również dodatkowe ryzyko zbudowania funkcjonalności, które nie będą dla użytkowników wartościowe.
| W naszych organizacjach należy szerzyć ideę MVP, czyli budowy rozwiązań o możliwie najwęższym zakresie, z których użytkownicy mogą zacząć korzystać, by następnie na bazie ich opinii rozwijać je dalej. Podejście zwinne jest klientocentryczne, ponieważ koncentruje się na budowie takich funkcjonalności, które będą rozwiązywać prawdziwe problemy klientów, a nie takich, które istnieją jedynie w naszej opinii. |
 |
Oznaka 5: Mamy cel (ale nikt nie ma pojęcia, co będzie się działo w bliskiej przyszłości)
Zespoły zwinne w organizacjach nieco bardziej dojrzałych często mają stawiane pewne cele, przykładowo może to być zwiększenie konwersji sprzedaży. Taki cel jest dość ogólnie określony i niektóre zespoły trafiają na problem w zdefiniowaniu na poziomie operacyjnym, co zrobić, by go osiągnąć. W takiej sytuacji, kiedy przychodzi do planowania, często „na szybko” wymyślane są zadania, czy też nawet funkcjonalności do zrealizowania w kolejnym sprincie. Niestety doprowadza to do dość dużej nieefektywności i straty znaczącej części budżetu. Pomysły rzucane na poczekaniu podczas sesji planistycznej nie są wystarczająco dobrze przemyślane, przez co ich realizacja w zbliżającym się sprincie jest często niemożliwa ze względu na piętrzące się nowe zawiłości. Bezpośrednią przyczyną tego problemu jest brak wykorzystania artefaktu, jakim jest backlog, który byłby wyznacznikiem przyszłości dla zespołu.
| Podejście zwinne nie jest synonimem chaosu. Agile faworyzuje przystosowywanie się do zmian w miejsce podążania za ściśle określonym planem. Niemniej jednak nie dyskredytuje istnienia strategii i tym bardziej planowania. Narzędziem, które wspomaga planowanie w metodyce Scrum jest Product Backlog, który powinien zawierać wszystkie pomysły na usprawnienie naszego produktu. Dzięki takiej liście zespoły mogą w ustrukturyzowany sposób podejść do budowy kolejnych przyrostów produktu. Na szczycie backlogu powinny znajdować się pomysły, które właściciel produktu uważa za najważniejsze dla osiągniecia celu zespołu. Dzięki temu zespół skupia się właśnie na najważniejszych sprawach i odpowiednio przygotowuje się do sesji planistycznej (podczas tzw. refinementu). W rezultacie, planowanie jest efektywne, a zespół wie, jak poszczególne pomysły przekładają się na realizację nadrzędnego celu. |
Niniejszy artykuł przedstawia jedynie kilka wybranych oznak, które występują w naszych organizacjach i wskazują na ich jedynie pozorną zwinność. Z pewnością w różnych przedsiębiorstwach oznaki te przyjmują odmienną barwę i natężanie, ale na pewno są to dość powszechne wyzwania. Zarówno z nimi, jak i z wieloma innymi problemami na drodze transformacji będziemy się zmagać jeszcze kilka lat, by finalnie doprowadzić nasze miejsca pracy do pełnego przejścia na model zwinny.
Więcej o promowaniu zwinnego podejścia w organizacji można przeczytać w artykule Artura Kożucha 10 sposobów jak promować podejście agile wewnątrz organizacji?.
Autor:
Bartłomiej Leszczyński, Menedżer w zespole doradztwa agile, Deloitte
Kontakt:
Artur Kożuch
Senior Manager w Zespole Strategii i Transformacji Technologii
Kontakt marketingowy:
