Witamy po długiej przerwie. Niniejszym wznawiamy cykl “Pierwsze Dni Scrum” i wchodzimy w obszar wykraczający poza uniwersalne reguły Scrum, lecz ważny dla wszystkich zespołów stosujących Scrum w obrębie inżynierii oprogramowania, a mianowicie ZPI – zwinny praktyki inżynierskie. Ale zacznijmy od początku:

Dlaczego szybkie dostarczanie “działającego oprogramowania” nie wystarczy?

Wyobraźmy sobie taką sytuację: nasz Właściciel Produktu ma świetny pomysł na biznes i dokładnie wie jak przekazać swoją wizję zespołowi, zespół dobrze rozumie jak działa Scrum i sprawnie się samoorganizuje pod opieką doświadczonego Scrum Mastera, który tydzień w tydzień rozbija w pył wszelkie przeszkody organizacyjne. Mijają sprinty, przyrosty przyrastają, pierwsi Klienci kupują, PO jest zadowolony, zespół jest zadowolony, management się cieszy. Bajka…

Błogostan trwa kilka miesięcy, lecz stopniowo, jakby nie wiadomo skąd, pojawia się coraz więcej zgrzytów:

• znajdujemy coraz więcej błędów i ich naprawianie zajmuje coraz więcej czasu,
• coraz częściej naprawienie jednego błędu powoduje zepsucie czegoś innego,
• dodanie nawet prostych funkcji zajmuje dużo dłużej niż na początku,
• tempo prac (velocity) maleje mimo ulepszeń organizacyjnych wprowadzanych po retrospekcjach.

PO i management myśli sobie, że zespół przestał się starać, więc próbuje zastosować techniki pseudo-motywacji rodem z call center banku detalicznego, wysyłając sygnał, że zespół nie zasługuje na zaufanie i szacunek i musi być zdalnie sterowany i kontrolowany przez czujnych managerów. Zespół próbuje wyjaśnić, że powodem jest wzrastająca złożoność systemu i że to nie ich wina, ale kierownictwo odbiera to jako wymówki. Motywacja spada, produktywność jeszcze bardziej, Klienci zaczynają oglądać się za konkurencją.

Sytuacja tylko się pogarsza szczególnie, że nikt nie zaadresował prawdziwego problemu, gdyż:

Czy da się utrzymać wysokie tempo prac zaniedbując jakość kodu?

Czy znalazłeś się kiedyś w sytuacji, kiedy konieczność szybkiego dostarczania użytkownikom nowych funkcji zdominowało wszystko inne, w tym jakość wewnętrzną (mierzoną np. liczbą WTF/min podczas code review), a nawet zewnętrzną (liczba błędów i niedociągnięć widocznych dla użytkowników)? Czy szef powiedział Ci kiedyś, że “ma poprawnie działać dla użytkowników, a w środku choćby na zapałki” albo “wystarczy jakość na 80%, byle byśmy szybko dostarczyli nowe funkcje“.

To może być rozsądna strategia biznesowa, zakładając, że decydenci w pełni rozumieją konsekwencje swoich decyzji. Jest to problem, bo świetni biznesmeni i managerowie produktu rzadko są jednocześnie doświadczonymi architektami a doświadczeni architekci rzadko świetnie rozumieją reguły biznesu.

Jak w tej sytuacji optymalnie wykorzystać wiedzą i doświadczenie obu stron?

Dług techniczny

Na ratunek przychodzi pojęcie długu technicznego (ang. technical debt), które pozwala obu stronom popatrzeć na postawiony wyżej problem w ich naturalnym języku. Metafora ta została użyta po raz pierwszy przez Warda Cunninghama w 1992 roku. Ward porównał w ten sposób pośpieszną produkcję kodu do szybkiej ekspansji, finansowanej kredytem. Dzięki niemu możemy szybciej osiągnąć nasze cele, lecz w naszej długoterminowej strategii musimy uwzględnić spłatę zaciągniętego długu i liczyć się z tym, że zbyt długie zwlekanie ze spłatą spowoduje narośnięcie kosztownych odsetek. Jeżeli nie poświęcimy czasu na przywrócenie odpowiedniej jakości kodu, coraz trudniej będzie go utrzymywać i rozwijać.

Takie postawienie sprawy pozwala zrównoważyć obie perspektywy. Z jednej strony inwestowanie w jakość może nie mieć uzasadnienia ekonomicznego i architektom łatwiej to zaakceptować, jeśli za cel postawią sobie optymalizację wartości biznesowych, a nie tylko techniczne aspekty produktu. Z drugiej strony odbiorcy staną się świadomi konsekwencji ścinania zakrętów i chętniej zainwestują w jakość widząc jej bezpośredni wpływ na długofalowe utrzymanie wysokiego tempa rozwoju.

Dlaczego nie zawsze dbamy o jakość kodu?

Bo to trudne.

Dlatego, choć nie mam przed oczami statystyki na ten temat, wiem, że większość zespołów nie dba o jakość kodu z zapałem niezbędnym do utrzymania wysokiego tempa rozwoju.

Aby zwiększyć swoje szanse musimy ukształtować nasze otoczenie w taki sposób, by czynniki wspierające znacznie przeważały nad przeszkodami. Przydatny model opisuje Jurgen Appelo w swojej książce “Jak zmienić świat“. Według modelu ADKAR przeszkodą blokującą udaną zmianę może być między innymi:

• Brak świadomości problemu (Awareness) – brak bolesnego doświadczenia zespołu, Właściciela Produktu i kierownictwa w zakresie długofalowych konsekwencji zaniedbania jakości kodu. Co gorsza może się okazać, że w przeszłości osoby te wykopały się z dołka niskiej jakości za pomocą dużej dawki morderczego wysiłku z domieszką szczęścia i teraz uważają, że heroiczny wysiłek i improwizacja niwelują potrzebę systematyczności i proaktywnego inwestowania w jakość.
• Brak motywacji lub aktywna demotywacja (Desire) – jeśli osoba posiadająca władzę w organizacji explicite stawia inne korzyści ponad jakością trudno wykrzesać w sobie chęć dyskutowania. Odpowiedzialny profesjonalista znajdzie sposób, by pokazać jak wysoka jakość wpłynie na sukces w języku odbiorcy i czym grozi jej zaniedbanie, ale często łatwiej jest po prostu podporządkować się obowiązującym oczekiwaniom i zrzucić odpowiedzialność z własnych barków.
• Brak wiedzy i umiejętności (Knowladge i Ability) – inżynieria złożonych systemów jest po prostu trudna. Nawet doświadczeni specjaliści muszą włożyć dużo wysiłku w stosowanie dobrych praktyk i ciągłe poznawanie nowych. Bez wiedzy i umiejętności dobre chęci nie wystarczą.
• Brak mechanizmów utrwalających (Reinforce) –  wszystkich powyższych przeszkód nie wystarczy zaadresować raz i o nich zapomnieć. Dla długofalowego sukcesu potrzebne są długofalowe mechanizmy wspierające i utrwalające pozytywne aspekty naszych praktyk oraz niewelujące zagrożenia.

Jak się pozbyć długu technicznego i zapobiegać nierozsądnemu jego zaciąganiu?

Chcesz uniknąć przeistoczenia Twojego zespołu w grupę szambonurków? Przy rosnącej złożoności systemu nie jest to łatwe. Na pewno czeka Cię duży wysiłek. Nagrodą za ten wysiłek jest sukces Twojej organizacji i budowanie Twojej reputacji jako wysokiej klasy profesjonalisty.

Aby odwrócić, albo chociaż spowolnić, zaciąganie długu technicznego albo spłacić wcześniej zaciągnięty dług potrzebne są świadome działania. Jest milion różnych podejść, niżej wybraliśmy dla Ciebie najważniejsze:

Pisząc nowy kod możesz:

• automatyzować testy jednostkowe, integracyjne i funkcjonalne oraz uruchamiać je przy każdej zmianie za pomocą serwera Continuous Integration,
• stosować programowanie zorientowane na testy (Test Driven Development),
• programować w parach,
• dbać o (samo)edukację w zakresie technik pomagających utrzymywać wysoką jakość kodu,
• utrzymywać wysoką czytelność kodu (mierzoną chociażby zrozumiałością dla innych członków zespołu) jako jedno z ważnych kryteriów jakości.

Pracując z istniejącym kodem możesz:

• refaktoryzować, aż do usunięcia prawie wszystkich brzydkich zapachów i osiągnięcia czystego kodu, z którego dumny byłby nawet Wujek Bob.
• stosować statyczną analizę kodu (i poprawiać wykryte usterki),
• badać pokrycie kodu przez testy,
• stosować przeglądy kodu.

W ramach kolejnych dni z cyklu porozmawiamy więcej o wybranych technikach i korzyściach, jakie one wnoszą, a tymczasem zostawimy Cię z dwoma pytaniami.

Pytania do Was:

• Jak często rozmowy między “IT” a “biznesem” na temat jakości kodu i innych spraw technicznych udaje się w Twojej organizacji zakończyć porozumieniem uwzględniającym potrzeby wszystkich zainteresowanych?
• Co robisz na co dzień, by zminimalizować narastanie długu technicznego lub sukcesywnie spłacać dług który nagrabiliście sobie wcześniej?

Skontaktuj się z nami, jeśli chcesz podzielić się swoimi doświadczeniami lub chciałbyś skorzystać z naszej pomocy w osiąganiu Twojego sukcesu.

Marcin Zajączkowski i Michał Parkoła

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Umiejętność wyciągania wniosków z własnych doświadczeń jest podstawą uczenia się i rozwoju. Krótka pętla zbierania danych, planowania ulepszeń i wprowadzania ich w życie jest niezbędnym elementem empirycznego podejścia, jakim jest Scrum.

Tak samo jak co Sprint dostarczamy kolejne ulepszenia w naszym produkcie tak powinniśmy co sprint ulepszać środowisko naszej pracy, stosowane metody i narzędzia oraz wszystkie inne czynniki (na które mamy wpływ), które pozytywnie lub negatywnie wpływają na naszą efektywność.

W Scrum okazją do przejścia tego procesu są Retrospekcje, które odbywają się pod koniec każdego Sprintu.

Szkielet Retrospekcji

Jak piszą boginie retrospekcji Esther Derby i Diana Larsen w książce “Agile Retrospectives“, każde takie wydarzenie powinno w takie czy innej formie zawierać następujące kroki:

1. Ustal uwagę (Set the Stage) – przywołaj cel retrospekcji i podstawowe zasady (zakaz obwiniania jednostek, ulepszanie systemu, …). Ustal ramy czasowe i organizacyjne.
2. Zbierz dane (Gather Data) – zawsze staraj się zebrać i wspólnie przyjąć do wiadomości jak najwięcej faktów na temat przebiegu sprintu. Od liczby i rodzaju napotkanych bugów po nastrój poszczególnych członków zespołu w kolajnych dniach.
3. Zrozum sytuację (Generate Insight) – zadbaj o to, żeby cały zespół wypracował wspólne zrozumienie tego, co oznaczają zebrane fakty i jak można ich użyć by poprawić sytuację.
4. Zaplanuj działanie (Decide What to Do) – na podstawie wspólnego zrozumienia sytuacji zaplanujcie konkretne zmiany, które mogą pomóc Wam skuteczniej i przyjemniej pracować. Plany te powinny być możliwie konkretne, uwzględnione w planie kolejnego sprintu i najlepiej powiązane z pomiarem, który jednoznacznie odpowie na pytanie, czy zmiana przyniosła oczekiwane efekty.
5. Podsumuj retrospekcję (Close the Retrospective) – podziękuj wszystkim za uczestnictwo i powtórz, co zostało zaplanowane.

Powyższe kroki można zrealizować mniej lub bardziej wprost lub wpleść je w różnorodne plany retrospekcji, o jakich można przeczytać lub pomyśleć. Retrospekcje nie muszą (i nie powinny) być zawsze takie same, jednak lekkomyślne pominięcie któregoś z tych elementów może zatrzeć granicę między wartościową retrospekcją a czystą rozrywką lub wręcz destruktywną sesją narzekania.

Pomysły na retrospekcje

Skąd brać pomysły na skuteczne i angażujące retrospekcje? Jak słusznie zauważa Paweł Brodziński, czasem Scrum Master powinien powściągnąć swoje kreatywne zapędy i zaczerpnąć pomysły z samego zespołu. Nawet “obiektywnie lepsza” metoda przegra w konkurencji z podejściem wywiedzionym z naszego realnego środowiska.

Jeśli mimo to szukasz inspiracji, istną kopalnią pomysłów jest wspomniana wyżej książka. Wiele schematów retrospekcji można też znaleźć w internecie. Tutaj przytoczymy zaś trzy:

Mad, sad, glad – zadaj wszystkim razem i każdemu z osobna trzy pytania:

1. Z czego jesteś zadowolony (glad)?
2. Co Cię smuci (sad)?
3. Co Cię wkurza (mad)?

Statek: żagiel i kotwica – wyobraźcie sobie, że Wasz projekt to okręt żeglujący w kierunku nowego lądu:

1. Co jest wiatrem wypełniającym Wasze żagle i pchającym do przodu?
2. Co jest kotwicą, która Was spowalnia?
3. Czy gdzieś przed Wami czai się rafa, która może doprowadzić do katastrofy?

Luźna dyskusja – czasem retrospekcja nie wymaga wydumanego formatu. Może wystarczyć nieformalna rozmowa. Jednak nawet wtedy warto zadbać o to, żeby:

1. podczas sprintu, na bieżąco zbierać tematy do omówienia na retrospekcji (inaczej wiele ważnych zagadnień jest po prostu zapominana),
2. zadbać o to, żeby rozważać problemy w kontekście myślenia systemowego, a nie szukać winnych (w samym zespole lub poza nim),
3. sprowadzać rozmowę do faktów bardziej niż opinii,
4. wyjść z retrospekcji z konkretnymi zadaniami i uwzględnić je w planie następnego sprintu.

Analiza Problemów

Podczas retrospekcji oraz przy innych okazjach przydatne są często dwie popularne techniki analizy problemów, opisane niżej:

5xDlaczego (Five Whys) – gdy zidentyfikujemy problem, zamiast przystępować do jego rozwiązywania, pytamy dlaczego on wystepuje. Gdy znajdziemy przyczynę, pytamy dlaczego ona występuje i tak dalej pięć razy lub do momentu gdy jesteśmy w miarę pewni, że natrafiliśmy na źródłowy problem, a nie tylko na kolejne poziomy jego objawów.

Ość Ishikawy – to diagram w kształcie szkieletu ryby pozwalający rozważyć wiele przyczyn składających się na występowanie danego problemu. Jest przydatny, gdy na nasz problem wpływa wiele różnych czynników jednocześnie. Każdy z nich możemy analizować głębiej, tak jak w metodzie 5xDlaczego, aż do zbudowania wystarczająco pełnego obrazu sytuacji.

Appreciative Inquiry

Częstym błędem popełnianym przez zespoły podczas retrospekcji (a także przez wszelkiej maści coach’ów i konsultantów) jest zbytnie koncentrowanie się na problemach. Często dużo lepsze efekty można osiągnąć koncentrując się na pożądanych efektach oraz silnych stronach zespołu i procesu, które można rozszerzyć i wzmocnić.

Metoda ta jest często lekceważona, bo “przecież my tu mamy konkretne problemy, więc koncentrowanie się na pozytywach to forma mydlenia oczu…“. A jednak okazuje się, że metoda ta, poprawnie przeprowadzona, ma zaskakującą moc. Nigdy nie zamiatamy problemów pod dywan, jednak gdy stosujemy takie doceniające podejście często okazuje się, że zamiast bezpośrednio zmagać się z problemami możemy je zniwelować lub w ogóle obejść dzięki spojrzeniu na sytuację z innej perspektywy.

Duże retrospekcje

Retrospekcje są wartościowe nie tylko dla pojedyńczych zespołów. Jeśli stoisz przed problemem zorganizowania retrospekcji dla większej organizacji skontaktuj się z nami, a w międzyczasie przeczytaj jak duże retrospekcje wyglądają w szwedzkiej firmie Spotify.

Ćwiczenie dla Was:

1. Jeśli do tej pory tego nie robicie, to spróbujcie wpleść w swoje retrospekcje kroki opisane w “Agile Retrospectives”.
2. Jeśli nie zbieracie danych, na podstawie których prowadzicie retrospekcje to zacznijcie to robić.
3. Jeśli Wasze retrospekcje wyglądają zawsze tak samo to spróbujcie zmienić format i wypróbować inne metody – zaproponowane przez sam zespół lub z któregoś ze wspomnianych wyżej źródeł.