12

W dzisiejszym wpisie odpowiadam na kolejne pytanie w ramach akcji Pytajnikowo.

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 nagrodę dostaje Karola. Wybrałem książkę Pawła Tkaczyka „Grywalizacja”, tradycyjnie już, ufundowaną przez Wydawnictwo Helion/ OnePress.

A oto pytanie, które dostałem:

Cześć,
Przekopałam Twojego bloga i szukam idealnego rozwiązania/-ń na temat: Jak zarządzać efektywnie w Scrumie zgłoszeniami błędów do projektów i błędów niezwiązanych z konkretnymi projektami w firmie tzw. utrzymanie produktu?

W swojej przygodzie ze Scrumem spotkałam się z dwoma możliwościami, które do końca nie były skuteczne:

• Powołanie odrębnego zespołu scrumowego, który miał przechodnich deweloperów, w zależności od ich dostępności. Jednak w praktyce, nikt nie chciał pracować w takim zespole i poprawiać błędów, które zostały „wprowadzone” przez zespoły z innych projektów. Czasami było też tak, że jeden deweloper zaczynał pracę nad jakimś zadaniem utrzymaniowym, potem nie miał czasu, żeby go dokończyć. Wtedy to zadanie przejmowała inna osoba, która z kolei potrzebowała czasu, żeby się wdrożyć. Cały ten proces zajmował bardzo dużo czasu.
• Każdy zespół scrumowy poświęcał w swoim sprincie około 30% czasu na poprawki błędów, a resztę czasu spędzał na zadaniach, związanych z projektem. Tylko, jak oszacować 30% czasu, skoro błędów najczęściej nie da się wycenić z różnych powodów?

Karola

Dzięki za pytanie, Karola! 😉

Na początek, zacznę od tego, że większość problemów, o których wspominasz bierze się najczęściej stąd, że całkiem spora część organizacji, w których wdrażamy Scruma jest do tego nieprzygotowana.

Bo Scrum wymaga zmiany systemu operacyjnego firmy.

Głównie od strony strukturalnej. I, choćbyśmy, nie wiem co robili, zawsze będziemy napotykać problemy, o których wspomninasz (nie tylko w obszarze utrzymania).

Z drugiej strony to, że organizacja nie jest przystosowana do pracy w Scrumie, wcale nie przekreśla możliwości jego wdrożenia.

Nie łudźcie się, że w kilka dni będziecie w stanie zmienić firmę i zacząć wszystko od nowa – ze Scrumem. To iluzja.

Adaptacja firmy wymaga czasu. W przypadku dużych organizacji proces ten trwa średnio 2-3 lata.

Scrum – narzędzie diagnostyczne

Dla mnie, bardzo dużą wartością Scruma jest to, że jak tylko zacznie się go używać w firmie, natychmiast wychodzą na jaw różnego rodzaju dysfunkcje. Obszary, które wymagają zmiany, żeby stosowanie Scruma miało sens i było wydajne.

Scrum jest więc bardzo dobrym narzędziem diagnostycznym. Dzięki niemu, w łatwy i szybki sposób można zobaczyć, co nie działa w firmie, co można w niej zmienić, poprawić, przebudować.

W ten sposób metoda ta może być również wykorzystana jako narzędzie zmiany całej organizacji.

Wiele firm, nie traktuje Scruma w ten sposób. Jak tylko pojawiają się jakieś problemy, co prędzej wracają do starego trybu pracy. A menedżerowie narzekają, że Scrum nie działa lub mówią, że nie pasuje do ich organizacji.

Firmy natomiast, które przyjmują odwrotną perspektywę – wykorzystują „diagnostykę” Scruma do przeprowadzenia zmiany. W ten sposób, pieką dwie pieczenie na jednym ogniu.

Wielu kierowników

Jednym z pierwszych, widocznych efektów niedopasowania organizacji do Scruma jest nadmiarowość kierowników liniowych, przy próbie wdrożenia zespołów interdyscyplinarnych.

Wcześniej każda z ról, czy to analityk, czy programista lub tester – miała swojego przełożonego. Teraz, kiedy wszystkie role tworzą jeden, interdyscyplinarny zespół, sprawa się trochę komplikuje.

Ale to nie wszystko. Dodatkowym wyzwaniem jest właśnie praca zespołów utrzymaniowych.

I tutaj pojawia się pytanie, które zadałaś Karola. Jak zarządzać efektywnie pracami utrzymaniowymi w Scrumie?

Niestety nie ma jednego, idealnego rozwiązania.

Utrzymanie w Scrumie – 5 rozwiązań

Przy okazji prowadzenia różnych projektów wdrożeniowych, na własnej skórze przećwiczyłem co najmniej pięć różnych rozwiązań, i żadne z nich nie było do końca skuteczne. Część z nich bardzo mocno pokrywa się także z Twoimi doświadczeniami.

Podejście 1. (POLECAM)

• Zadania utrzymaniowe są częścią prac, realizowanych przez zespół scrumowy w sprincie.

W praktyce wygląda to tak, że błędy produkcyjne trafiają do Backlogu Produktu i są jednym z zadań, realizowanych przez zespół scrumowy w sprincie.

Podejście to, mimo mankamentów, o których wspomniałaś, i tak jest dużo lepsze od sytuacji, w której błędy produkcyjne są naprawiane przez odrębny zespół w firmie.

Dlaczego? Bo, dzięki „wrzuceniu” zadań utrzymaniowych do sprintu, łatwiej jest nimi zarządzać. Dokładnie wiecie ile czasu wam zajmują. Śledzicie ich realizację na wykresie spalania. Jest większa transparentność prac w projekcie.

Jak już wspomniałem, w tym podejściu, wszystkie zadania utrzymaniowe lądują w Backlogu Produktu, razem z innymi elementami (np. nowymi funkcjonalnościami).

Co oznacza, że Właściciel Produktu musi się im bliżej przyjrzeć, uporządkować je – razem z innymi wymaganiami, które chce rozwijać w sprincie.

W praktyce, najczęściej wygląda to tak, że podczas planowania sprintu, zespół przyjmuje określony bufor na realizację prac utrzymaniowych w sprincie – na przykład 30% – jak zaproponowałaś.

Przy czym, bufor ten wcale nie oznacza, że musicie każdy błąd produkcyjny dokładnie oszacować. 30% to informacja, że tyle czasu jesteście w stanie wygospodarować na zadania, związane z utrzymaniem produkcji w sprincie.

Ja zwykle, oprócz takiego buforu, planuję z zespołami jeszcze jedną taką „poduszkę” – na wszystkie nieplanowane zdarzenia w sprincie. Mam tutaj na myśli głównie trzy typy zdarzeń:

• Sytuacje „podbramkowe”. Chodzi o zadania („wrzutki”), którymi musicie się zająć w trybie natychmiastowym w sprincie (np. padł serwer i musicie go naprawić).
• Zadania, które się „rozrosły” w sprincie. W czasie planowania zakładaliście, że praca nad jakimś zadaniem zajmie wam 5 godzin. Tymczasem, mijają 4 godziny i, wszystko na to wskazuje, że będziecie potrzebowali jeszcze dwa razy więcej czasu na dokończenie tego zadania.
• Zadania, których nie dało się przewiedzieć podczas planowania sprintu. Choćbyście się nie wiem jak bardzo się starali, zawsze będzie coś, o czym nie pomyśleliście w przy planowaniu sprintu. W waszych głowach pojawią się jakieś nowe pomysły, rozwiązania.

Podejście 2. (POLECAM)

• Zadania utrzymaniowe, realizowane są przez tzw. „wirtualny zespół utrzymaniowy”.

To podejście jest pewnego rodzaju wariacją na temat podejścia pierwszego. Mamy zespół scrumowy, którego wybrani członkowie (zwykle 2-3 osoby) na okres jednego sprintu tworzą wirtualny zespół, który zajmuje się tylko pracami utrzymaniowymi.

Nazwa „wirtualny” bierze się stąd, że skład tego zespołu zmienia się między sprintami. Chodzi też o to, żeby podkreślić, że osoby, które wchodzą w skład zespołu wirtualnego tak naprawdę nie są członkami dwóch zespołów, ale jednego – scrumowego. Taki trik. 😉

Stosowałem to rozwiązanie w kilku firmach, i muszę powiedzieć, że działało bardzo sprawnie.

Oczywiście, zawsze jest ryzyko, że w ciągu jednego sprintu ktoś nie będzie w stanie rozwiązać problemu i wtedy może dojść do sytuacji, o której wspominasz w mailu. Pojawi się nowa osoba, która przejmie dotychczasowe zadania, co spowoduje, że czas naprawy błędu znacznie się wydłuży.

Takie ryzyko jest jednak zawsze. Wtedy ta osoba może zostać na przykład o jeden „dyżur” (sprint) dłużej w zespole wirtualnym.

Podejście 3. (NIE POLECAM)

• Zadania utrzymaniowe, realizowane są przez członków zespołu scrumowego, ale nie są częścią prac sprintu.

W tym podejściu, prace utrzymaniowe wykonują te same osoby, które pracują w Scrumie. Jednak utrzymanie nie jest częścią prac, wykonywanych w sprincie.

W praktyce wygląda to tak, że w trakcie planowania sprintu, osoby te zmniejszają swoją dostępność (ang. capacity) do prac w zespołach scrumowych.

Wiem, że niektóre zespoły stosują takie rozwiązanie, ale jest to model pracy, który wam zdecydowanie odradzam. Bo jest mało przejrzysty.

O ile w pierwszym podejściu zespół dokładnie wie kto, ile czasu poświęca na zadania utrzymaniowe, tutaj te informacje giną.

Problemy zaczynają się wtedy, kiedy prace utrzymaniowe zajmują komuś więcej, niż sobie zaplanował. A to, jak sama wiesz, zdarza się dosyć często. Wtedy, siłą rzeczy, taka osoba mniej angażuje się w prace zespołu scrumowego. Co też jest bardzo słabe.

Podejście 4. (NIE POLECAM)

• Zadania utrzymaniowe, realizowane są przez odrębny zespół utrzymaniowy, którego niektórzy członkowie są częścią zespołu scrumowego

W tym podejściu mamy dedykowany zespół utrzymaniowy w firmie, w którym stały skład stanowi tylko kilka osób. Reszta to osoby dochodzące, które na co dzień pracują w Scrumie i sporadycznie są oddelegowywane do prac utrzymaniowych.

To podejście wydaje się bardzo sensowne i stanowi łakomy kąsek dla wielu organizacji podczas wdrożenia. W praktyce jednak, kompletnie się nie sprawdza.

Przećwiczyłem to rozwiązanie w kilku firmach i zawsze prowadzi ono do tych samych problemów. Pierwszy z nich jest dokładnie taki, jak wspominasz w swoim mailu, Karola.

Załóżmy, że w sprincie 12. Tomek (imię przykładowe) trafia do zespołu utrzymaniowego, żeby naprawić jakiś błąd produkcyjny. Dlaczego Tomek? Bo akurat świetnie zna się na obszarze funkcjonalnym, którego dotyczy zgłoszony problem. Tomek trafia więc do zespołu utrzymaniowego, co prędzej bierze się do roboty i szybko się okazuje, że naprawa tego błędu zajmie więcej niż jeden sprint.

Co wtedy? „Wyciągamy” Tomka z zespołu utrzymaniowego i na powrót „wcielamy” do zespołu scrumowego? Jeżeli tak, to ktoś musi dokończyć robotę, którą rozgrzebał. W związku z tym, w zespole utrzymaniowym pojawia się nowa osoba, która przejmuje schedę po Tomku. Zanim to jednak nastąpi, musi się wdrożyć w temat. A to wymaga czasu. Zegar tyka.

Jak to się skończy? Scenariusz, z którym najczęściej spotykam się w firmach wygląda tak, że ktoś nagle wpada na pomysł, że jednak „wyciąganie” osób na jeden sprint nie ma sensu. Lepiej oddelegowywać je na okres pełnego wydania produktu, czyli na przykład 3 miesiące.

Bomba! Tomek trafia na całe 3 bite miesiące do zespołu utrzymaniowego. Po czym wraca i na jego miejsce wchodzi inna osoba z jego zespołu.

Sęk w tym, że rzadko kiedy da się tak zaplanować prace utrzymaniowe, żeby Tomek pozamykał wszystkie zadania zanim wróci do swojego zespołu.

Sytuacja najczęściej prowadzi do tego, że, owszem, Tomek wraca do zespołu scrumowego, jednak jego dostępność jest mniejsza ze względu na czas potrzebny na dokończenie zadań utrzymaniowych.

W teorii, da się z tym żyć. W praktyce, dokładnie pamiętam retrospektywy, w trakcie których, taki „Tomek” narzekał, że tak dłużej nie da się pracować. Z jednej strony, zawracają mu głowę z utrzymaniem, z drugiej „wisi” na nim robota w Scrumie.

Takie podejście się nie sprawdza.

Przejdźmy do kolejnego.

Podejście 5 (POLECAM).

• Zadania utrzymaniowe, realizowane są przez odrębny zespół utrzymaniowy, który ma stały skład i jego członkowie zajmują się tylko utrzymaniem.

To podejście nie jest takie złe. Ma jednak pewien mankament, o którym zresztą wspominasz w swoim mailu, Karola. Niewiele osób, chce pracować na stałe, w takich zespołach. Można rotować pracowników, ale i tak, problemu się nie wyeliminuje.

Powracający problem

Wszystkie podejścia, które zaprezentowałem nie są idealne. Każde z nich ma jakieś mankamenty.

Ja osobiście jestem zwolennikiem realizacji zadań utrzymaniowych razem z innymi zadaniami zespołu scrumowego w sprincie.

Wszystkie inne modele, jakkolwiek można jest stosować w firmie i nie przekreślają możliwości stosowania Scruma – są mało wydajne.

W moim przekonaniu są także pewnego rodzaju rodzaju „obejściem” ducha Scruma.

Zespół Deweloperski, który jest jedną z trzech ról w Scrumie powinien posiadać wszystkie niezbędne kompetencje do tego, żeby co sprint dostarczać kompletny, działający produkt. Jeżeli wyrzucamy prace utrzymaniowe z tego, czym się zajmuje, to również pozbywamy się pewnych kompetencji, które ograniczają jego interdyscyplinarność.

No bo dlaczego błędy dotyczące produktu, który dany zespół rozwija, powinny być naprawiane przez inny zespół w firmie, nie-forumowy?

Problem w wielu wypadkach bierze się stąd, że organizacje bardziej skupiają się na realizacji projektów, niż produktów.

Dopóki ta mentalność nie zostanie odwrócona, zawsze będziemy próbowali stosować różnego rodzaju „obejścia”, żeby poradzić sobie z różnego rodzaju dysfunkcjami w naszych firmach, które Scrum ujawnia.

Zespoły DevOps – mój faworyt!

W trakcie prowadzenia projektów wdrożeniowych w różnych organizacjach i eksperymentowania z podejściem 1-5, muszę powiedzieć, że najlepszym rozwiązaniem, które jest też zgodne z założeniami Scruma jest zburzenie muru, który oddziela świat developerów i administratorów. A więc, połączenie rozwoju z utrzymaniem – stworzenie prawdziwych (!) interdyscyplinarnych zespołów w firmie.

Mam tutaj na myśli koncepcję tzw. zespołów DevOps (skrót od angielskich słów: „development” i „operations”), która wymaga jednak przebudowania struktury organizacyjnej firmy.

Dlaczego DevOps?

Dzięki zespołom DevOps firma skupia się przede wszystkim na rozwoju produktów, a nie projektów. Wzrasta odpowiedzialność pracowników za produkt. Ludzie się z nim dużo bardziej identyfikują.

DevOps to także duża elastyczność pracy. Ponieważ developerzy i administratorzy pracują razem, mogą na bieżąco decydować jak zbalansować zadania utrzymaniowe i rozwojowe w poszczególnych sprintach.

Moje doświadczenia z DevOps

Jak dotąd, pracowałem tylko z jedną organizacją, która na wprowadzenie takiego modelu się zdecydowała. I doszła do niego, w pewnym sensie drogą naturalną. W trakcie procesu wdrożenia, przećwiczyliśmy wszystkie możliwe podejścia do „ogarnięcia” prac utrzymaniowych w Scrumie. I żadne z nich, się nie sprawdzało. Mieliśmy podobne doświadczenia jak te, które opisujesz Karola w swoim mailu.

I dopiero zmiana struktury organizacyjnej i zbudowanie zespołów DevOps dodało Scrumowi skrzydeł i w pełni pozwoli łana wykorzystanie jego magicznych mocy.

Cały proces zajął nam blisko 3 lata.

Obecnie pracuję z inną dużą organizacją, która już na etapie startu projektu wdrożeniowego zadeklarowała, że zmiana struktury organizacyjnej jest warunkiem koniecznym do tego, żeby z metod agile można było efektywnie korzystać.

Chcemy połączyć rozwój z utrzymaniem. Powstaną zespoły DevOps, które w naturalny sposób będą wdrażać koncepcję zespołów interdyscyplinarnych w firmie – zgodnie z duchem Scruma.

Tak. Czeka nas długa droga. I wszyscy potrzebujemy dużo cierpliwości.

Ale poczekać warto!