Poradniki

Jak nie przegadać “zwinnego” tygodnia i nie programować tylko po godzinach?

23.06.2013, Tomasz Czubkowski

Nasza przygoda z metodologią Agile miała cztery klasyczne etapy:

1. Nieświadoma niekompetencja

W 2009 roku wprowadziliśmy na rynek oprogramowanie CONTMAN DIRECTOR i rozpoczęliśmy realizację kilku skomplikowanych projektów obiegu dokumentów (workflow). Mimo ogromnego zaangażowania każdej ze stron (nas jako dostawcy oraz Klienta), projekty te kończyły się frustracją obu stron i niepowodzeniem.

Działaliśmy standardowo. Na początku prezentowaliśmy Klientowi rozwiązanie, a Klient wybierał naszą ofertę. Robiliśmy długotrwałą analizę, po której następowało pół roku programowania, a po tym instalacja. Czekaliśmy na oklaski… a tu katastrofa. Nie to Klient miał na myśli.

Ponieważ w większości projektów płatność za wdrożenie była po odbiorze, dostawaliśmy prosty komunikat: “Proszę poprawić albo nie zapłacimy”. Więc ponownie robiliśmy analizę, tym razem jeszcze bardziej skrupulatną, tym razem rysowaliśmy ekrany, opisywaliśmy wszystko w dokumentacji, pracowaliśmy kolejne miesiące, potem instalacja i… znowu porażka. Znowu nie to o co chodziło naszemu Klientowi.

Rosła frustracja, kierownicy projektów rezygnowali z pracy, programiści składali wypowiedzenie, a niedotrzymane terminy to było najmniejsze z naszych zmartwień.

Pewnego razu zdarzył się projekt, pozornie nieróżny od wcześniejszych. Z wyjątkiem tego, że Klient chciał rozpocząć jego realizację natychmiast i skończyć w październiku, a my zwyczajowo zaczęliśmy od analizy. Termin podany przez Klienta minął, a nam nie wystarczyło już czasu na jego realizację. Klient zrezygnował, wybierając ofertę innej firmy, która wzięła się za robotę, a nie za gadanie.

Ta kropla przelała czarę i, jako osoba odpowiedzialna za ten stan, otrzymałem jasny sygnał z rynku, że nie tędy droga. Projekty na rynku zaczęły być realizowane przez firmy, które brały się za robotę bez zbędnego gadania i realizowały projekty przy zdecydowanie mniejszych budżetach. Było to dla nas kompletnie niezrozumiałe i traktowaliśmy Klientów jak lemingi rzucające się w przepaść, no bo jak można robić taniej i szybciej, jeśli my znamy się najlepiej i wiemy, że się nie da. Absurd.

2. Świadoma niekompetencja

W jasny sposób wiedziałem, że robimy coś źle, ale nie wiedziałem dlaczego. Słyszałem wtedy by zmienić naszą strategię i zamiast kompetencji obniżyć jakość – wejść w temat z najniższą ofertą, a potem “się zobaczy”, bo przecież Klient już nie zrezygnuje. Tak działać nie chcieliśmy.

Mniej więcej w tym czasie część naszych programistów zaczęła mówić o Agile’u. Być może sami mieli dosyć chaosu w pracy, być może tak widzieli swoją drogę do mistrzostwa. Część z nich kładła mi książki na biurko, ale ich nie czytałem, bo mi się nie chciało. Miałem przecież szefa programistów i szefa wdrożeń, więc Agile to powinna być ich sprawa, ich problem. Spokój swojego sumienia kupowałem akceptacją nowych technologii, rozwiązań, produktów Atlassiana (Jira, Confluence, Hipchat) czy czasoumilaczy (rzutki). Kompletnie mimo uszu puszczałem inne sugestie typu: “bądźmy zwinni”, “miejmy Product Ownera i Scrum Mastera” itp. Byłem ślepy i głuchy.

Do momentu aż nie zwolnił się szef programistów i zostałem z tym cyrkiem sam. Cyrkiem oraz olbrzymią stratą na projektach realizowanych waterfall (czyli tak jak dotychczas, na tzw. “hura”).

Trzeba było coś przeczytać, więc Krzysiek Wiśniewski polecił mi Zwinnego Samuraja Jonathana Rasmussona, którego przeczytałem w jeden wieczór i który był bardzo istotnym elementem mojej przemiany. Wyznaczyłem bez zastanowienia Product Ownera, Scrum Mastera i zaakceptowałem podstawowe ceremonie. Dałem sobie wcisnąć, że jesteśmy tak bardzo specyficzni, że Scrum nie jest dla nas, a tylko Kanban odzwierciedla nasze ciągłe zmiany i patrzyłem jak się to wszystko kręci. Nie kręciło się.

Jedynym spotkaniem, które mnie interesowało było demo, czyli bardzo nieudolny Sprint Review (który notabene nie jest demem). Na tym demie widziałem, że programiści wykonali wszystko, tylko nie to, co zakładali, programują praktycznie wyłącznie po godzinach, w godzinach pracy tylko gadają, w większości nie na temat, a nasze dema to istny stres dla wszystkich stron. Cyrk był do kwadratu.

3. Świadoma kompetencja

Nie było wyjścia, trzeba było sięgnąć po posiłki, czyli szkolenia Agile, konferencje, książki oraz przede wszystkim po zewnętrzny audyt, prowadzony przez niezależnego fachowca – konsultanta.

Audyt był dosyć bolesny. Dowiedzieliśmy się, że nasz Agile jest na niby. Przede wszystkim oberwało się mi. Okazało się, że ludzie się mnie boją i nawet paluszki na stole podczas demo tego nie zmienią. Że nie mamy rasowego Product Ownera, Scrum Master błądzi we mgle, a ceremonie są na niby.

Pozostały mi dwie opcje: zwolnić się albo zmienić. Pierwsza opcja nie wchodziła w grę, więc nie pozostało nic innego jak zmienić wszystko.

Więc zmieniliśmy wszystko.

Najbardziej bałem się ceremonii, a konkretnie ich ilości. Wydawało mi się, że czas będzie tylko na ceremonie, a nie będzie go na programowanie. Zacząłem więc od uporządkowania kalendarza, od ustalenia bardzo precyzyjnych, niedługich, powtarzalnych spotkań, starając się zrobić wszystko ze sztuką (Daily Scrum, Groomingi, Sprint Review, Retrospekcja), wymagając od siebie i od pozostałych szacunku dla terminów i dla naszego wspólnego czasu. Spotkania były święte i wkrótce zakładane maksimum 50 minut wystarczało nawet na Groomingi. Jak zwykle kluczowe były: powtarzalność, konsekwencja i pilnowanie czasu.

Po drugie zrozumiałem, że do czasu zatrudnienia lub wyedukowania “rasowego” Product Ownera, to ja jestem Product Ownerem. Wydawałoby się, że to prosty wniosek, ale dojście do niego zabrało mi zbyt wiele czasu. Podjęcie się tego zadania wymagało pełnego uczestnictwa w zespole Agile’owym, więc musiałem uczestniczyć w każdej ceremonii, mieć wiedzę o każdym realizowanym zadaniu. Musiałem żyć życiem zespołu. Znikły problemy komunikacyjne, Sprint Review stał się przyjemnością, skierowaną już raczej do innych pracowników firmy, bo tak naprawdę wiedziałem o wszystkim.

I co najważniejsze – postanowiłem realizować Scrum. Odbyłem z zespołem szczerą rozmowę i ustaliliśmy warunki, w których wezmą odpowiedzialność za sprint (w naszym przypadku tygodniowa iteracja programistyczna). Ustaliliśmy realne tempo zespołu. Założyliśmy na początku 30% mocy zespołu na zadania niezaplanowane. Aktualnie jest to 20% i zmierzamy do 10%. Do tego doliczamy 10% czasu na likwidację długu technicznego i… zaczęła się magia, czyli:

4. Nieświadoma kompetencja

Aktualnie wszystko kręci się jak w szwajcarskim zegarku, cały zespół uczestniczy w precyzyjnych ceremoniach, a moje obowiązki Product Ownera przejęła nowa osoba, która w pełnym zakresie dba o backlog. Tempo zespołu jest wysokie jak nigdy i podlega systematycznemu zwiększeniu. Cele sprintu są systematycznie osiągane dzięki realnej roli Scrum Mastera, liczba zadań nieplanowanych jest minimalna i traktowana jako patologia, z która trzeba walczyć. A dotychczas nienawidzone Sprint Review stało się przyjemnością. Nie ma problemów komunikacyjnych, zamówienia Klientów są realizowane w terminie, a zespół sam rozwiązuje swoje problemy, łącznie z podnoszeniem kompetencji i likwidacją niekompetencji każdego rodzaju. Wyceny są adekwatne, zadania są realizowane w założonym czasie, a programiści nie rezygnują z pracy; wprost przeciwnie – mamy coraz lepszych ludzi, którzy bez przerwy się rozwijają.

Jestem zadowolony, choć jeszcze nie do końca. Czas przejść tę samą drogę z resztą firmy. Głęboko wierzę, że Agile można być w każdym innym, poza programowaniem, obszarze firmy. Chciałbym też, aby nasi Klienci zrozumieli, że Agile daje im dokładnie to, co jest potrzebne w zakładanym czasie i budżecie.

Ale to już temat na następny post.

ZapiszZapisz

#contmanway
Więcej w kategorii >
23.05.2018, Autor: Magdalena Tuchowska
Zmiana pracy to jedno z bardziej stresujących wydarzeń w naszym życiu. Przejście przez pierwsze trzy miesiące w nowej firmie bez opieki przewodnika jest jak ...
Czytaj więcej
Aktualności
Więcej w kategorii >
31.07.2018, Autor: Piotr Szpakowski
W ostatnich dniach w sieci pojawiło się kilka wpisów m. in na portalu forsal.pl czy też cashless.pl przypominających o planowanym na październik przejęciu cz...
Czytaj więcej
Case Studies
Więcej w kategorii >
31.07.2018, Autor: Piotr Szpakowski
W ostatnich dniach w sieci pojawiło się kilka wpisów m. in na portalu forsal.pl czy też cashless.pl przypominających o planowanym na październik przejęciu cz...
Czytaj więcej
Po godzinach
Więcej w kategorii >
13.09.2016, Autor: Dawid Tomaszewski
Ansel Adams kiedyś powiedział: „prawdziwa fotografia nie musi być wyjaśniana, ani nie może być zawarta w słowach”. Każdy z nas widział zdjęcie, na które pier...
Czytaj więcej
04.09.2018, Autor: Krzysztof Grześkowiak
Na przeprowadzenie refinementu składa się nie tylko dobre opisanie czy omówienie zadania, ale też sprawne moderowanie spotkania. Po właściwym wprowadzeniu pr...
Czytaj więcej