„Commitment” na „forecast” – co stoi za tą zmianą?

W 2011 roku Scrum Guide przeszedł cykliczną aktualizację. Jedną ze zmian było zastąpienie słowa commitment (pol. zobowiązanie) na słowo forecast (pol. prognoza). Od tego momentu zespół deweloperski prognozuje, które z zadań z Rejestru Produktu zostaną przez niego dostarczone na koniec iteracji. Była to jedna z najbardziej kontrowersyjnych zmian w Scrum Guide, dlatego też napisałem kilka zdań mojego rozumienia tych słów i co się z nimi wiąże.

Dlaczego nastąpiła zmiana?

Reklama


Powodem zmiany było znaczenie słów. Framework Scrum przewidywał do momentu wprowadzenia zmiany, że zespół deweloperski zobowiązuje się podczas planowania sprintu do realizacji określonych zadań z Rejestru Produktu. Był to tym samym znak dla Product Ownera i interesariuszy, że określone zadania zostaną wykonane. Praktyka pokazała jednak, że zakres sprintu omawiany na planowaniu jest często nie realizowany – na zdjęciu poniżej widzicie wykres z rzeczywistego zespołu; pokazuje on „commitment” rozumiany jako liczba story points wziętych na sprint oraz „przewidywalność” rozumianą jako iloraz commitmentu i velocity. Jak możecie zauważyć, „przewidywalność” zespołu mocno się waha.

Aby zakres/ cel był zrealizowany, często zespół deweloperski musiał iść na ustępstwa w zakresie jakości dostarczanych zadań. Słowo zobowiązanie bardzo często wiązało się z obietnicą wykonania zadania i taki był też jego odbiór przez otoczenie zespołu scrumowego.

Z drugiej strony mamy słowo “forecast”, czyli prognoza. Zespół bazując na sprawdzonych informacjach prognozuje, że dane zadanie zostanie ukończone. Jest to podejście bliższe faktycznej pracy zespołu deweloperskiego zwłaszcza, że zakres sprintu może ulec zmianie w miarę upływu czasu i poznawania niewiadomych. Jest to podejście, które nie wymaga realizacji pełnego zakresu sprintu aby na koniec iteracji osiągnąć cel sprintu oraz zadowolenie zespołu, Product Ownera i interesariuszy z wykonanej pracy. Idąc dalej za znaczeniem słów według scrum.org, mamy do czynienia bardziej z non-materialized forecast (pol. niezrealizowaną prognozą), niż z broken commitment (pol. złamaną obietnicą). Jeżeli prognoza nie zostanie zrealizowana, bardziej odbieramy ją jako element nauki, poznawania otoczenia, a złamaną obietnice odbieramy bardziej jako coś, co dotyczy bezpośrednio nas, coś co zawiodło nasze oczekiwania.

Złamana obietnica ma jeszcze jeden wymiar. “Biznes” zaczyna na podstawie planowanych zadań układać swoje. Czyni założenia, plany, podejmuje decyzję. I wszystko to na podstawie zobowiązania zespolu scrumowego do realizacji określonych zadań z Product Backlogu. Jeżeli zespół nie zrealizuje planu do którego się zobowiązał (ang. commit), “biznes” może czuć się oszukany. Jest to typowe podejście non-agile, kiedy “IT” jest traktowane trochę jak wykonawca określonych zadań, wewnętrzny dostawca. I istnieje założenie, że zawsze będą one wykonane.

Zastąpienie słowa commitment słowem forecast powinno wyeliminować w/w sytuacje. Ale jakie wady kryją się za nowym słowem?

Wady słowa forecast

Poza oczywistą trudnością, jaką jest przyzwyczajenie do słowa zobowiązanie, możemy zauważyć także inne. Ze słowem forecast może wiązać się poczucie, że zespół deweloperski realizuje tylko prognozę. Może istnieć założenie, że brak wdrażalnego przyrostu na koniec każdej iteracji nie jest przy takim podejściu dużym problemem. To jest jest duży problem! I słowo zobowiązanie powinno nam o tym przypominać (a jednak :]).

Według scrum.org, zobowiązanie jest nadal obecny w Scrum i istnieje on na przykład na poziomie samego frameworku Scrum:

  • zobowiązanie do stopnia realizacji poszczególnych zadań. Każde z nich wzięte na sprint powinno spełniać Definicję Ukończenia (and. Definition of Done) i istnieje zobowiązanie zespołu do jego przestrzegania,
  • zobowiązanie do ciągłej inspekcji i adaptacji, które są podstawą nie tylko Scrum, ale też Agile.

Podsumowanie

Obecnie zespół deweloperski na planowaniu sprintu jest proszony o prognozowanie planowanych do wykonania prac. Podejście to pozwala skupić się bardziej na jakości, wartości biznesowej, ciagłym udoskonaleniu procesu pracy niż tylko na wypełnieniu danej obietnicy.

Niezależnie od tego, czy poznawaliście Scruma z zobowiązaniem się czy już z prognozą, warto rozważyć, czy w swoim zespole nie trzymacie się zbyt sztywno podejścia ze starego Przewodnika po Scrumie, albo otoczenie Waszego zespołu tak Was nie traktuje.

Źródła zdjęć: flickr.com udostępnione na licencji CC BY-NC-ND 2.0

Dawid Lewandowicz

Posiadam prawie 20 letnie doświadczenie związane z wytwarzaniem oprogramowania. Na początku swojej kariery pracowałem jako analityk, a później jako certyfikowany kierownik projektów (Prince2 Practitioner) w jednym z największych banków w Polsce. Od 8 lat pracuję jako Agile Coach (CSP, PSPO) z zespołami deweloperskimi oraz infrastrukturalnymi, w tym wspierałem także przejście z tradycyjnego modelu zarządzania na podejście bardziej zwinne (scrum, kanban). Pracuję również z zespołami biznesowymi. Wspieram je bazując na Customer Development Immersive, Entrepreneurship 101 oraz Professional Product Management Training - Blackblot. Dzięki swojemu doświadczeniu posiadam perspektywę tradycyjnych systemów zarządzania (waterfall) oraz opartych o podejście zwinne (agile w różnych wariacjach). Charakteryzuję się niekonwencjonalnymi pomysłami, wielokontekstową analizą prowadzącą do niestandardowych rozwiązań oraz, jak określają mnie współpracownicy, jestem głosem rozsądku połączonym z kwestionowaniem status quo. Jestem również wykładowcą Technik Zwinnych na WMiI UAM, współzałożycielem największego w Polsce portalu o agile (agile247.pl) oraz prowadzę szkolenia i konsultacje w ramach 202procent.pl

Jeden komentarz do wpisu: “„Commitment” na „forecast” – co stoi za tą zmianą?

  1. Framework SAFe bazuje na commitmencie i to dość odległym czasowo jeśli mówimy o zgrubnym planowaniu na 10 tygodni. Z kolei forecast może być odbierany jako coś niezobowiązującego = nieistotnego. Z drugiej strony, którego słowa użyjemy nie powinno mieć większego znaczenia – jeśli team poniesie porażkę to ważniejsze jest czy potrafi dokonać inspekcji i wyciągnąć wnioski.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x