Dziś chcemy opisać jeden z najbardziej rozpowszechnionych problemów branży – kiedy Scrum próbuje się stosować w warunkach z góry ustalonego i niepodlegającego negocjacjom budżetu, a często i zakresu. Czy Scrum Master jest w stanie pomóc projektowi fixed price? Czy w ogóle jest sens stosować tę metodykę? A może jest lepsze narzędzie?
Fixed Price Scrum
Bardzo często mamy do czynienia z projektami fixed price, które mają z góry ustalony budżet, a zazwyczaj też zakres i terminy. Znacznie utrudnia to jakiekolwiek odejście od sztywnego planu. A to, jak wiemy jest przeciwieństwem podejścia zwinnego.
Jest to typowa sytuacja w dużych korporacjach, gdzie taki projekt jest częścią dużego Portfolio, a wszystkie decyzje są podejmowane kilka poziomów wyżej przez ludzi, którzy zazwyczaj nawet nie znają osób faktycznie wytwarzających produkt. Razem z tym, coraz więcej korpo próbuje „bawić się” w Scruma, wprowadzając go właśnie do projektów fixed price. Biednemu Scrum Masterowi nie zostaje nic poza byciem administratorem oraz prowadzącym spotkania, gdyż nie ma żadnego umocowania żeby zadziałać więcej. Nie lepiej jest z Product Ownerem, który w takich sytuacjach zazwyczaj zostaje de facto Delivery Managerem.
W tym tekście chciałbym poruszyć dwie kwestie: jedną z poziomu taktycznego, drugą – ze strategicznego. Po pierwsze – czy możemy jakkolwiek polepszyć wydajność zespołu pracującego w takim właśnie fixed price’owym projekcie? Czy jako Scrum Master będziemy w stanie pomóc temu zespołowi? Strategiczne pytanie dotyczy całej organizacji na wyższym poziomie: czy da się zmienić strukturę na taką, która umożliwi działanie Scrumowe, czy też jednak w korpo inaczej się nie da?
Rozwiązanie na poziomie taktycznym
Zacznijmy więc od poziomu taktycznego. Jak wiemy, Scrum służy do wytwarzania produktów i pomaga rozwiązywać złożone problemy poprzez adaptacyjno-iteracyjne podejście. Czyli jest przeznaczony do produktów, a nie projektów. Tutaj możemy wejść w niepotrzebną walkę o semantykę, ponieważ duża część projektów w korpo polega na wytwarzaniu jakiegoś produktu bądź jego części/komponentu. Nie biorąc pod uwagę zespołów zajmujących się wyłącznie utrzymaniem, wydaje się, że możemy działać całkiem Scrumowo. Jedynym problemem jest to, że nasz budżet oraz terminy są ustalone z góry.
Słynna książka „Jak robić dwa razy więcej dwa razy szybciej” wprowadziła swoim tytułem w błąd tysiące ludzi, ponieważ działając w Scrumie często tak naprawdę będziemy robili mniej, wolniej i drożej. Oczywiście, z oczekiwaniem, że na końcu jakość i trafność produktu nam to zrekompensuje.
Spójrzmy na następny przykład: mamy dwie osoby, które zarządzają swoimi finansami na różne sposoby. Jedna skupia się w pierwszej kolejności na oszczędzaniu i ulepszaniu skuteczności/efektywności swoich wydatków i inwestycji. Rzetelnie pilnuje swego budżetu, wyszukuje zniżki i wyprzedaże na wszystkie niezbędne towary, unika wydatków które nie są konieczne. Druga osoba podchodzi do tego bardziej luźno: wydaje więcej na rozrywkę, bo uważa, że wtedy lepiej się odpręża i jest bardziej produktywna. Więcej inwestuje w swój rozwój i liczy, że z czasem to się opłaci. Oczywiście nie robi tego zupełnie bez planu i weryfikacji (patrz: empiryzm), ale na pewno jest mniej „sztywna”.
Ta druga osoba ma nastawienie podobne do scrumowego. Jeżeli więc jej podejście nie jest dla nas dostępne, warto spróbować pierwszego. Czyli skuteczniej wykorzystywać dostępne środki. Tu tak zwany Scrum Master, który nie jest do końca Scrum Masterem, bo nie działamy w Scrumie, powinien pomóc zespołowi ze znalezieniem dostępnych dla nich ulepszeń. Może można zautomatyzować coś, co jest robione ręcznie, ulepszyć komunikację, zrezygnować ze spotkań lub procesów, które nie mają dużej wartości i tak dalej. Na pewno warto przeprowadzać regularne Retrospektywy oparte o fakty. Choć ograniczenia wywodzące się ze struktury organizacji wciąż są, i mogą być frustrujące, to jednak zespół, który skupi się na tym, żeby z płynem czasu ulepszać to co się da będzie zostawał skuteczniejszy.
Rozwiązanie na poziomie strategicznym
Popatrzmy na ten sam problem z punktu widzenia strategicznego. Jeżeli korporacja ma szereg projektów opartych o wytwarzanie/rozwijanie pewnego produktu, lecz z jakiegoś powodu nie dają one możliwości zwinnego działania. Często wywodzi się to ze złego modelu skalowania zwinności. „Zróbmy transformację zwinną, ale tak żeby nic nie zmieniać!”
Skalowanie z użyciem rozległej i scentralizowanej hierarchii uniemożliwia samozarządzanie się zespołów. Jest to raczej rebranding waterfalla. Skupiamy się na tym, żeby wygodnie było Delivery Managerom bądź inny managerom, a nie na tworzeniu lepszych produktów.
Rozwiązaniem na poziomie strategicznym jest zmiana modelu skalowania. Jest to również coś, co zazwyczaj nie potrafi zmienić zwykły Scrum Master. Ba! To coś, co w ogóle nie może być zmienione bez inicjatywy ludzi „z góry”. Natomiast, jako dobry case study polecamy nasz wywiad z Pawłem Kozłowskim z U2I. Tam też poza samym modelem skalowania znajdziemy inspiracje do modelu działania całej firmy. Bo o wiele łatwiej pracować scrumowo, jeśli naszym klientom wynajmujemy całe Scrum Teamy na godziny (czytaj: Sprinty), niż gdy sprzedajemy im konkretną pracę wycenioną w man-day’ach.
Projekty fixed price możemy spotkać nie tylko w dużym korpo. Równie często widzimy to w małych biznesach opartych o małe marże. Rozwiązanie taktyczne będzie takie same. Natomiast strategicznie nie mamy skalowania, bo mamy pojedyncze zespoły. Tak więc tym bardziej musimy zastanowić się nad zmianą modelu biznesowego. Jest to również trudna do rozstrzygnięcia kwestia, która wymaga podejścia indywidualnego i nie zawsze się opłaca. Na szczęście tak się składa, że mamy doświadczenie z wsparciem takich projektów, produktów, zespołów i transformacji. Jeżeli borykacie się z podobnymi problemami, polecamy się.
