O zwinnym remontowaniu

Przez kilka wakacyjnych dni razem z dwójką przyjaciół remontowaliśmy niewielkie mieszkanie. I nieoczekiwanie sposób naszej współpracy zaczął mi bardzo mocno przypominać słowo „agile”…

Rozpocznijmy od przedstawienia projektu: naszym celem było wyremontowanie mieszkania, ponieważ zmieniała się nieco jego funkcja. Zespół do wykonania prac składał się z trzech osób. Mieliśmy inwestora (vel właściciela produktu…), 6-dniowy termin na wykonanie zadania oraz dość ściśle określony budżet projektowy.

Jeszcze przed rozpoczęciem projektu nastąpiła faza wstępnej analizy – razem z inwestorem usiedliśmy i wypisaliśmy wszystko, co chcemy zrobić w ramach tego remontu. Na liście pojawiły się pozycje takie jak: „wynieść rzeczy z piwnicy”, „malowanie przedpokoju” czy „instalacja nowej umywalki”. Spróbowaliśmy również rozplanować te czynności na dni – ale szybko się poddaliśmy, bo przy tym planowaniu pojawiło się zbyt wiele niewiadomych (Kiedy firma przywiezie nam nowe drzwi wewnętrzne? Czy Marek zrobi nam elektrykę? Czy ktoś kupi i zabierze stare meble?) oraz zbyt wiele zależności (cekolować można po wstawieniu drzwi, malować można po cekolowaniu, wykładzinę układamy na końcu, i tak dalej, i tak dalej). Sporo niewiadomych oraz zależności między zadaniami – brzmi znajomo, nieprawdaż?

Zresztą to dobrze, że nie zrobiliśmy tego odgórnego harmonogramu, ponieważ w trakcie remontu bardzo dynamicznie pojawiały się nowe sprawy i dochodziły nowe zadania.

Także zamiast robić harmonogram w MS Projecie, wykorzystaliśmy kawałek ściany oraz żółte karteczki żeby zrobić remontowy „Kanban Board”:

Wykonaliśmy jeszcze szybkie szacowanie projektu posługując się metodą ekspercką:
– Jak myślisz, zdążymy z tym do wtorku?
– Jak drzwi szybko zamontują i nic nie wyskoczy… Raczej chyba zdążymy…

I zabraliśmy się do roboty.

Pierwszą rzeczą, która zauważyłem po rozpoczęciu pracy, była całkowita samoorganizacja zespołu projektowego. Wchodziliśmy do mieszkania, przebieraliśmy się w ubrania robocze i każdy brał się za wybrany fragment pracy – „pomaluję teraz łazienkę”, „będę cekolował dziury”, „złożę tę szafkę do kuchni”. Nie było żadnego narzucania ani przydzielania zadań – każdy wybierał to, co umiał robić i czym mógł popchnąć pracę do przodu. Czasami tylko pojawiała się sugestia jakiś modyfikacji planu: „może poczekaj z tym malowaniem, bo teraz będę kurzył, lepiej będzie jak zaczniesz za godzinę”.

Mając zespół, który sam sobie wybiera zadania, istnieje niebezpieczeństwo, że ludzie będą podejmować zadania, które im się podobają – ale bez patrzenia na to, co rzeczywiście jest potrzebne i ważne. W naszym przypadku bardzo mocno nas przed tym chroniła świadomość celu i terminu projektu. Wszyscy wiedzieli, że mamy ograniczony czas oraz co musimy w tym czasie wykonać.

Tak naprawdę cele pojawiły się na dwóch poziomach – był cel ogólny: „do wtorku musimy skończyć wszystko”. I były też cele na każdy dzień – idąc rano do miejsca pracy rozmawialiśmy o tym, co chcemy dzisiaj skończyć i trochę projektowaliśmy sobie kolejne dni: „jak dzisiaj będziemy mieli już wszystko wycekolowane, to jutro będzie można przeszlifować i pomalować pierwszy raz”. Ten plan był bardzo ogólny, ale wystarczający do naszych potrzeb.

Gdybyśmy mieli zrobić ryzykowną analogię do Scruma, to tak naprawdę nasze sprinty były jednodniowe – rano ustalaliśmy cel na dany dzień, a na koniec dnia pracy oglądaliśmy efekty, co udało się zrobić. To oglądanie efektów (czyli nasze Review) było jak najbardziej zespołowe – robiliśmy to wszyscy razem.

Jak zwykle przy remontach pojawiały się nowe zadania – w trakcie prac zdecydowaliśmy o wymianie wszystkich kontaktów i gniazdek elektrycznych, okazało się że po demontażu pawlacza trzeba wyrównać i pomalować sufit, a malowanie kafelek trzeba było powtarzać trzy razy. Dorzucaliśmy te zadania do zakresu projektu patrząc tylko na jedną rzecz – czy zdążymy skończyć wszystko, co potrzebne, przed ostatecznym terminem. Ale w trakcie prac okazywało się również, że niektóre rzeczy albo nie są potrzebne, albo spokojnie możemy wykonać je później.

Bardzo naturalną rzeczą było uczenie się zespołu oraz wzajemna pomoc. „Ile wody dajesz do tego cekolu?”. „Który wałek bierzesz do tej farby to kafelków?”. „Pomożesz mi przykleić taśmę pod sufitem, bo w dwójkę robi się to dużo szybciej?”.

I na koniec dwa równie ważne czynniki: komunikacja w zespole oraz wspólne podejmowanie decyzji. Rano rozmawialiśmy o tym, które prace chcemy skończyć. A trakcie dnia wymienialiśmy informacje na bieżąco: „Jadę do sklepu po uszczelki, czegoś potrzebujecie?”. „Słuchajcie, tę wnękę malujemy kolorem czy na biało?”. „Wracamy na obiad do domu, czy zamawiamy jakąś pizzę?”.

Te wszystkie rzeczy – samoorganizacja, świadomość celów długo- i krótkoterminowych, uczenie się, komunikacja, pomaganie sobie – pojawiły się w zespole bardzo naturalnie. Po prostu zaczęliśmy tak współpracować. Nie było potrzeby organizowania spotkania na temat „ways of working” ani wspólnego ustalania zasad pracy grupowej. Wyszło samo.

A patrząc na efekt naszej pracy, jestem głęboko przekonany, że wykonanie całości prac w terminie było skutkiem nie naszych umiejętności i zdolności (bo nie oszukujmy się, jesteśmy amatorami, a nie profesjonalną ekipą remontową…), ale było efektem dobrej współpracy w zespole oraz nastawienia na osiągnięcie celu.

I zastanawiam się tylko, dlaczego przy dużych, korporacyjnych projektach odeszliśmy tak daleko od takiej naturalnej współpracy, że musimy się jej teraz na nowo uczyć – nazywając ją modnym słowem „agile”?