Dobry, zły i brzydki, czyli kolejna wersja retro

Retrospektywa na koniec sprintu to punkt obowiązkowy, każdego porządnego zespołu korpoagilowego. Czym jest zespół korpoagilowy?

KorpoAgile

Takie zespoły działają zazwyczaj w ekstremalnie nieprzyjaznym środowisku. Jeżeli dodatkowo są tylko częścią większego projektu prowadzonego według starego dobrego waterfalla to muszą radzić sobie z problemami, które w normalnej sytuacji nie istnieją. Dlatego, też uważam, że typowe „retro” nie jest dla nich odpowiednim podejściem. Przez typowe rozumiem takie retro, które opiera się na trzech pytaniach dotyczących omawianego przedziały (sprint, release, itp.) w kontekście zespołu:

  • Co było dobre?
  • Co było złe?
  • Co możemy poprawić, zmodyfikować by było lepiej?

W przyjętym przeze mnie podejściu ogólna metoda działania jest bardzo podobna, ale skupia się na elementach pochodzących z zewnątrz. Dlatego też nie powinno ono być stosowane za każdym razem. Raczej jak warstwa korpogówienka będzie już widoczna, ale jeszcze nie zastygnie, by być trudną do usunięcia. Zanim przejdziemy do szczegółów jeszcze jedna uwaga. Może zdarzyć się tak, że po spotkaniu będziemy mieli bardzo negatywne i jednocześnie agresywne nastawienie do otoczenia. To nie jest nic złego. Nic nie wkurwia bardziej niż procedurki, papierki, tabeleczki, raporciki i podobne zdrobnienia. BTW, wiecie, że osoby chore na raka bardzo często wiedzą, jaka jest diagnoza, zanim zobaczą papiery, ponieważ personel medyczny zaczyna używać zdrobnień w stosunku do dokumentacji i procedur? Taki myk.

Nie należy jednak dawać po sobie, jako zespole, poznać, że najchętniej byśmy całe korpo potraktowali napalmem. Zemsta najlepsza jest na zimno, a jeszcze lepsza, gdy dokonamy jej narzędziami samej korporacji.

Przygotowania

Oczywiście do retro należy się przygotować. Poza bezpośrednimi przygotowaniami warto przez pewien czas zbierać „haki” na otoczenie zespołu. Nie działają wirtualki – ticket w Jirze + dokładne trackowanie czasu przestoju. Nieaktualna biblioteka powoduje problem, ale procedura nie pozwala na aktualizację – ticket + podpinanie do niego wszystkich powiązanych problemów. Poganiacz ma jakieś chore pomysły – mail z kulturalną informacją, do czego doprowadzi jego niedojebanie mózgowe.
Działa to też w drugą stronę. Należy stworzyć listę spraw rozwiązanych i załatwionych.

Dobry

Zaczynamy od miłych rzeczy. Lista spraw, które udało nam się rozwiązać albo załatwić. Najistotniejszym elementem tej części jest omówienie, JAK zostało to osiągnięte. Dobrze by efektem było pojawienie się krótkiej listy procedur, które były nam pomocne. Każda korporacja ma swoje procedury. Dużo procedur i nie sposób znać je wszystkie. Zatem warto dzielić się odkryciami w tym zakresie. Przykład z życia – kilku nowych pracowników miało nieprawidłowe adresy email. Pomylone imiona, nazwiska itp. Okazało się, że można to naprawić za pomocą procedury „ślubnej”, bo ta dotyczyła aktualizacji danych w związku z ich zmianą po ślubie. Odkrycia tego dokonał zespół dopiero po tym, jak jedna z koleżanek wzięła ślub, a w geście rozpaczy jeden z „nowych” napisał do kadr z pytaniem, czy jak on weźmie ślub, to też mu poprawią dane.

Zły

Złe rzeczy przytrafiają się każdemu. My jednak chcemy odszukać i jak najszybciej wyeliminować te zmiany, które nastąpiły w otoczeniu i mają bezpośredni wpływ na nasz projekt. W tej części ważne jest określenie natury problemu. Niektórych rzeczy nie przeskoczymy. Jeżeli zmiana jest na wysokim szczeblu i dotyka całego ustroju firmy, to trudno będzie z tym walczyć. Można jednak skupić się na wszystkich tych elementach, które w jakiś sposób bezpośrednio nas dotykają. Moim ulubionym przykładem jest tu hasło idące od PM ze strony klienta „wrzućcie to na produkcję, to jest polecenie służbowe”. Do tego worka trafią też wszystkie inne rzeczy, które były jawnym złamaniem ustalonych zasad. Na koniec tworzymy listę rzeczy, które trzeba koniecznie naprawić.
W niektórych przypadkach naprawa oznacza napisanie dupokrytki, a w innych zmianę procedur wewnątrz zespołu tak by tego typu „atak” można było łatwiej odeprzeć. Warto też wydzielić zdarzenia, które powodowały, iż pojawiały się opóźnienia. Następnie tworzymy listę uporządkowaną według pilności. To są rzeczy do zrobienia na już.

Brzydki

W tej kategorii lądują wydarzenia systemowe, ale też wszelkie propozycje, które mogą mieć zły wpływ na projekt, a nie są jeszcze pewne. W ich przypadku należy przedyskutować zagrożenia i wypracować wspólne stanowisko. Ważne jest ,by dobrać też odpowiednie metryki, które w razie czego pozwolą na negocjację, a w ostateczności na wykazanie, że nie my zjebaliśmy.
Oddzielną grupę stanowią usprawnienia. Czasami mamy możliwość dokonania pewnych zmian na styku zespół-korporacja. Takie rzeczy też powinny znaleźć się na tej liście. Oczywiście wyposażone w odpowiednie metryki i uzasadnienie.

Podsumowanie

Tego typu retrospektywa dobrze sprawdza się, gdy chcemy w jakiś sposób ustalić „interfejsy” pomiędzy zespołem a otoczeniem. Zespoły IT mają już to do siebie, że nie za dobrze wpisują się w sztywne ramy korporacyjnych procedur. Dodatkowo jakość ich pracy w ogromnym stopniu zależy od czasu, w jakim pojawia się informacja zwrotna. Istotną różnicą jest też abstrakcyjność pracy, która w połączeniu z ponadprzeciętnymi zarobkami, jest polem do popisu dla różnego typu niedojebanych PM średniego szczebla. Szczególnie wtedy, gdy trzeba zrzucić na kogoś odpowiedzialność.

Mając w zanadrzu odpowiednie argumenty, które zespół przygotował wcześniej, może on obronić się przed tego typu atakami. Z agile jak z ciążą albo jest w całej organizacji, albo go nie ma. Pojedyncze zespoły prowadzone w ten sposób, szczególnie w firmach nie technologicznych, zawsze będą musiały bronić swojego podejścia.

2 myśli na temat “Dobry, zły i brzydki, czyli kolejna wersja retro

Napisz odpowiedź

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

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax