Co trzeba zmienić w firmie, żeby stosowanie Scruma było wydajne? – 3 rzeczy

Cykl: Zwinna Firma
28 września 2015

9

W dzisiejszym wpisie odpowiadam na pytanie Sławka, które nawiązuje do tematu wdrażania Scruma w organizacji projektowej.

Przypominam, że dla autorów najciekawszych pytań i pomysłów, które pojawiają się na moim blogu lub w podcast’cie, czekają fajne nagrody. Tym razem jako nagrodę wybrałem książkę Kenneth S. Rubin Scrum. Praktyczny przewodnik po metodzie Scrum, ufundowaną przez Wydawnictwo Helion/ One Press.

A oto pytanie, które dostałem:

Nie mogę mieć pewności, jak często podobne sytuacje mają miejsce, bo ze swojej perspektywy pytam czysto hipotetycznie, ale mam nadzieję, iż w Twojej praktyce się zdarzały.

Załóżmy więc, że mamy do czynienia z organizacją projektową, która dostarcza jakieś oprogramowanie. Developerzy pracują w Scrumie, nie mając w zasadzie widoczności na poziomie projektu. Pracują w sprintach, realizując określone zadania, według własnej prędkości.

Wyżej jednak, na szczeblu organizacji i programu, planowanie i zarządzanie projektami odbywa się kaskadowo. Optymalnie byłoby, aby w proces planowania projektu włączony był ktoś, znający styl pracy zespołu, jego wydajność itd., lecz niestety nie żyjemy w tak idealnym świecie, i często planowanie odbywa się na poziomie ogólnym, narzucając jakieś ramy czasowe ad hoc, bez urealnienia szacunków o opinie środowiska developerskiego.

Tak więc uznajmy, iż Project Manager dostał z góry narzucony termin realizacji projektu – 12 miesięcy. Jednocześnie, prawdziwy czas realizacji, gdyby został oszacowany przez zespół scrumowy, byłby dłuższy i wynosił 18 miesięcy. Deweloperzy szacują poszczególne wymagania i wychodzi na to, że w rok nie będą w stanie dostarczyć w pełni działającego oprogramowania.

Jak w takich sytuacjach wygląda rozwiązywanie tego typu konfliktów? Uświadomienie kogoś tam u góry z reguły pomaga, czy też są próby manipulowania szacunkami zespołu scrumowego? Czy jednak praktyka pokazuje, że odseparowanie Scruma od kaskadowego zarządzania projektem operacyjnie często jest problematyczne?

Sławek

Najpierw odpowiem krótko, a później zabiorę się za wyjaśnienia 😉 Osobiście, odradzam stosowanie Scruma i jednocześnie „operacyjne” zarządzanie projektem w tradycyjny sposób. Oczywiście można tak robić i wiele firm tak właśnie pracuje. Jednak jest to rozwiązanie bardzo nieefektywne. I zawsze go klientom odradzam.

Dlaczego źle szacujemy projekty?

Problemy z szacowaniem, o których wspominasz, wbrew pozorom, wcale nie są aż tak hipotetyczne. Można je spotkać w większości współczesnych organizacji. Wynikają one z kilku błędów, które w naszych firmach notorycznie popełniamy.

  • Pierwszy z nich polega na tym, że ludzie, którzy realizują projekty nie biorą udziału w ich wycenie. Projekty, najczęściej szacowane są przez tzw. _ekspertów_, którzy później praktycznie w ogóle nie mają z nimi do czynienia.
  • Drugi błąd polega na tym, że nie bierzemy pod uwagę spadku trafności oszacowań wraz z wydłużaniem się okresu, który obejmują. Innymi słowy, próbujemy przewidywać projekty, których czas trwania jest bardzo długi – od 9 miesięcy wzwyż.
  • Szacujemy punktowo, nie zakresowo. Wyjaśnię to na prostym przykładzie. Inaczej spakowałbyś się na urlop, gdybyś wiedział, że temperatura kraju do którego się wybierasz może wynieść trzydzieści stopni, zakładając, że współczynnik błędu wynosi dziesięć stopni, niż gdyby, przy takiej samej temperaturze, współczynnik błędu wyniósł tylko jeden stopień. Na tym polega problem procesu szacowania w większości naszych projektów. Ciągle podajemy wartość punktową. Projekt zajmie nam siedem miesięcy, i koniec. Nie mówimy natomiast, że przedsięwzięcie w wariancie optymistycznym może potrwać siedem miesięcy, a w wariancie pesymistycznym dziewięć. I na tym gorszym scenariuszu powinniśmy budować całą naszą strategię działania. Bo to on ma największe znaczenie.
  • Kolejny błąd polega na tym, że te pierwsze, migawkowe wyceny w projekcie traktujemy zbyt serio i na ich podstawie planujemy realizację całego przedsięwzięcia. Później, nikt już nie sprawdza jak faktycznie mają się one do rzeczywistości. Bardzo często, kiedy pytam w firmach, czy te pierwsze, mgliste prognozy są w jakikolwiek sposób weryfikowane, dostaję odpowiedź, że owszem, tak powinniśmy to robić, ale nikt tego nie praktykuje. W efekcie, cała wycena projektu sprowadza się do tej pierwszej prognozy – jednej liczby, która decyduje o wszystkim.

Często mówi się, że „mądry człowiek umie przewidzieć, co się wydarzy”. Być może naprawdę mądry człowiek rozumie, że nie potrafi przewidzieć, co się wydarzy w odległej przyszłości.

Nassim Nicholas Taleb, „Czarny Łabędź”

Dysfunkcje, które nie powinny mieć miejsca

Sytuacje, o których wspominasz w swoim mailu, a więc „odgórne narzucanie estymat” przez kierownika projektu, czy próby manipulowania prognozami zespołu, wywieranie nacisku, żeby te estymaty były „odpowiednie” – to wszystko są pewne dysfunkcje, które przy planowaniu projektów nie powinny mieć miejsca.

Co zrobić, żeby je wyeliminować? Najlepiej jest stosować podejście Maxa Kolonki i „mówić jak jest”. Bez owijania w bawełnę. Dysfunkcji nie należy zamiatać pod dywan, ani udawać, że ich nie ma. Trzeba o nich mówić otwarcie, bo tylko wtedy jest jakaś szansa, że uda się je wyplenić.

Tymczasem, w naszych firmach, bardzo często brakuje nam odwagi, żeby nazywać rzeczy po imieniu. Tracimy czas na spotkaniach, kręcąc się w kółko, bo nie jesteśmy w stanie powiedzieć, że takie, czy inne zachowanie po prostu nie powinno mieć miejsca. Jest poważną dysfunkcją w naszej organizacji.

I wprowadzenie Scruma wcale nie załatwi sprawy. Wiele firm myśli, że jak już będzie miała tego „agile’a”, to wszystko, jak za dotknięciem magicznej różdżki się zmieni. Tak nie jest.

Czy da się stosować Scruma, prowadząc projekty kaskadowo?

Kiedyś przeczytałem na blogu Marii Czubaszek, że dawniej przekonywano (zwłaszcza młodych), że można się bawić bez alkoholu. – Bo można! – odpowiedziała córka jej sąsiadki – Tylko, po co się tak męczyć? Podobnie jest ze stosowaniem Scruma i prowadzeniem projektu w tradycyjny, kaskadowy sposób.

Oczywiście, że można tak robić. Tylko, po co się tak męczyć? Musimy pamiętać, że naszym celem nie powinno być stosowanie tej, czy innej metody agile w firmie. Cel jest inny. Chodzi przecież o zwinne dostarczanie produktów naszym klientom, o szybkie reagowanie na zmieniające się potrzeby rynku – o responsywność. O to wszystko, czego nie da się zapewnić, stosując metody kaskadowe.

Silnik od Ferrari do Syreny

To jest trochę tak, jakbyśmy chcieli włożyć silnik od Ferrari do poczciwej Syreny. Gdyby była inna obudowa, owszem, moglibyśmy jechać dużo szybciej. Ale, co z tego, skoro warunki nam na to nie pozwalają. Organizacja to zbiór takich właśnie warunków, które umożliwiają efektywną pracę silnika – Scruma, czy innej zwinnej metody. Bez dobrej „budy” nie osiągniesz tego, co w innych warunkach byłoby możliwe bez problemu.

Co trzeba zmienić w firmie, żeby stosowanie Scruma miało sens?

Są trzy „grube” tematy, od których zależy, czy stosowanie Scruma będzie przynosiło faktyczną wartość w firmie:

1. Definicja produktu

Tu bardzo często leży pies pogrzebany. Wdrożenie Scruma w firmie wiąże się z odpowiedzią na krótkie pytanie: co jest produktem, który rozwijamy? Niby proste pytanie, ale ile razy zadaję je różnym osobom w firmach z którymi pracuję, tylekroć padają różne odowiedzi. Najczęściej niejednoznaczne.

Bo, czy produktem jest wynik danego projektu? Czy może produktem jest kilka projektów, które łączy wspólny cel (program)? A może produktem są różne elementy projektów? Niektórzy mówią, że dla nich produktem jest utrzymanie konkretnego systemu. Jeszcze inni, że jest to dokument specyfikacji funkcjonalnej albo dobrze przeprowadzona analiza biznesowa.

Co jest więc TYM produktem? Jeśli „produktem”, który rozwijacie w Scrumie jest jakiś projekt, to bardzo możliwe, że nie ma on żadnej wartości biznesowej do klienta. Dostarczacie wartość dla IT, ale nie dla Biznesu.

Scrum jest metodą organizacji pracy zespołu, który pracuje nad rozwojem danego produktu.

To, czy dany produkt rozwijany jest w ramach konkretnego projektu, czy nie – z punktu widzenia Scruma, nie ma żadnego znaczenia.

Myśląc o definicji produktu, trzeba mieć cały czas w tyle głowy to, że w Scrumie wcale nie chodzi o dostarczanie projektów. Chodzi o to, żeby dostarczać produkty, które mają wartość dla klienta. Dla Scruma pojęcie projektu w ogóle nie istnieje. A to zmienia bardzo dużo.

Bo produktem w naszych firmach, który ma jakąś wartość dla Biznesu, bardzo rzadko jest jeden, konkretny projekt. Najczęściej tworzy go grupa projektów, skupionych wokół jakiejś domeny biznesowej, w ramach której produkt jest dostarczany. Wtedy produktem są najczęściej elementy kilku projektów.

Produkt w Scrumie

2.Struktura organizacyjna

Zwornikiem pracy w Scrumie są interdyscyplinarne zespoły, które same organizują swoją pracę. To jest jeden z warunków stosowania tej metody.

Praca w takich zespołach przy utrzymaniu się tradycyjnej struktury prowadzi do dwóch zjawisk: 1) jeden zespół ma kilku kierowników liniowych i 2) czasowego „wypożyczania” ludzi do pracy w Scrumie.

Obie sytuacje, z punktu widzenia funkcjonowania zespołu są złe:

  • mamy tutaj do czynienia z „nadmiarowym” zarządzaniem (kilku kierowników liniowych do jednego zespołu scrumowego),
  • trudno jest zbudować prawdziwy zespół (ludzie są regularnie „wyciągani” do pracy nad innymi zadaniami, zleconymi przez właściwych kierowników liniowych)
  • może dochodzić do konfliktu interesów pomiędzy potrzebami Właściciela Produktu i kierowników liniowych.

I całkiem spora liczba firm, wdrażając Scruma, w takiej „dwu-biegunowości” funkcjonuje. Bo da się. Jeżeli bardzo dokładnie zdefiniujecie wzajemne interfejsy, określicie kto, za co odpowiada i jaki jest przepływ informacji – można tak żyć. Ale jest to rozwiązanie, które na dłuższą metę się nie sprawdza. Jest niewydajne.

3. Zarządzanie popytem.

Wdrożenie metod agile w firmie wcale nie zakłada, że musicie pozbyć się wszystkich projektów, które realizuje w tradycyjny sposób. Trudność polega na tym, że nie da się tak zorganizować procesu zarządzania popytem, żeby był inny dla projektów, prowadzonych w sposób tradycyjny, a jeszcze inny dla projektów agile.

Chodzi o to, żeby mieć jeden, wspólny Backlog dla wszystkich projektów realizowanych w firmie, także tych tradycyjnych. Proces zarządzania popytem musi być w pewnym sensie uniwersalny dla wszystkich inicjatyw, realizowanych w firmie. A to wymaga całkiem sporego wysiłku, żeby te dwa światy ze sobą „pożenić.

Te trzy zmiany implikują kolejne, ale później jest już tylko łatwiej 😉