Usiądźcie wygodnie dziatki. Opowiem wam bajkę. Będzie strasznie. Dobrego zakończenia też nie ma, ale Bajki Braci Grimm też do najweselszych nie należą. Jak to w bajkach z morałem.

Za siedmioma górami, za siedmioma lasami w Software „Spierniqa” pracował sobie Development Team o wdzięcznej nazwie „Misie”. Misie produkowały sobie świetny soft. Klienci byli zadowoleni, Misie spełniały się jako eksperci.

99

Pewnego dnia, Misie zaplanowały sobie release. Zaplanowały jak zawsze, z uwzględnieniem prędkości którą miały w poprzednich sprintach. Z planowania wyszło im coś takiego:

8

Jednak komuś się to nie spodobało. Chciał żeby to, co zostało zaplanowane dostarczono szybciej. Co więc zrobił? To co podpowiadało mu doświadczenie i wykrzyknął gromko „Pracujcie szybciej!”

7

No więc Misie pracowały szybciej. Na wykresie wyglądało to tak. Jak myślicie, czym jest to coś zaznaczone klamerką? To jest NIEZROBIONE, znane też pod nazwą długu technologicznego albo śmierdzącego kodu.

Jaki efekt ma takie „niezrobione”? Najczęściej taki, że kod jest nieczytelny, są tam rozwiązania „na słowo honoru”, przez co pojawia się więcej błędów, więc i częstsze awarie, i wiele innych rzeczy.

Czy Wielki-Zły-Project-Manager osiągnął zlecone mu cele? Oczywiście! Zespół dostarczył szybciej. Więc Wielki-Zły-Project-Manager dostał swój worek pieniędzy i poszedł dalej, do kolejnego projektu.

6

A Misie? Misie zostały z tym coraz brzydszym kodem.

5

Więc zaplanowały sobie kolejny release. Tym razem już praca szła im wolniej, bo musiały przebijać się przez poprzednio stworzony dług technologiczny.

4

To już zdecydowanie się komuś nie podobało. Ponieważ poprzedni Wielki-Zły-Project-Manager już dawno pracował nad innym projektem, zatrudnił do pogodnienia Misiów Ogromnego-Jeszcze-Gorszego-Project-Managera, z jeszcze większym batem, który strzelił z niego i głębokim głosem nakazał Misiom: „Pracujcie szybciej!”

3

Co się stało zapytacie? Ano pracowali szybciej tworząc kolejne pokłady długu i nie mogąc go spłacać. Ale dostarczyli szybciej. Więc Ogromny-Jeszcze-Gorszy-Project-Manager osiągnąwszy swój cel dostał swój worek pieniędzy i poszedł dalej.

2

Kilka releasów później, gdy produkt był już w stanie nie nadającym się do rozwoju, bo każda dopisana linijka generowała błędy i konflikty, nadszedł czas na przepisanie tego rozwiązania. Które kosztuje więcej niż rozwój obecnego do tej pory.

1

Bajka ta niestety nie ma dobrego zakończenia. Misie poszukały sobie pracy gdzie indziej, a do przepisania produktu wzięło się kilkoro praktykantów.

Czy warto więc zatrudniać zmieniających się Wielkich-Złych-Project-Managerów? To pozostawiam Waszej ocenie.

A co by się stało, gdyby ten produkt miał pracującego z zespołem Product Ownera? Kiedy zacząłby naciskać na zespół podczas pierwszego releasu, spowolnienie ugryzłoby go w zad bardzo szybko i okazałoby się, że takie ruchy są nieopłacalne. Ale zmieniający się PM-owie nie mają szansy tego zauważyć.

Jakby tego było mało, wyobraźcie sobie morale tego zespołu, który pod batem ogląda, jak powoli sami niszczą coś, co wspólnymi siłami budowali.

Uwaga dla hejterów: ta bajka nie ma za zadanie zdyskredytowania działań PM-ów i nie oznacza , że wszyscy PM-owie są źli. Jest tu pokazany pewien specyficzny, ale i częsty przypadek, którego ofiarami sa także PM-owie, bo w tym przypadku po prostu wykonują dobrze swoją pracę – osiągają zlecone im cele. Ale o wyznaczaniu i osiąganiu celów w kolejnej bajce. Śpijcie dobrze.

Mentorka o niezwykłej charyzmie. Jeden z najbardziej doświadczonych ekspertów Scruma i pierwszy trener Scaled Professional Scrum w Polsce.