Przeprowadzałem niedawno kolejne szkolenie z tematu Wprowadzenie do Agile. I wciąż zaskakuje mnie jak techniki zwinne są płytko rozumiane wewnątrz zespołów rozwijających oprogramowanie. Większość osób rozumie jaki cel mają konkretne spotkania Scrumowe. Jednak jest to tylko zrozumienie frameworka – nie mówi nic o podstawach za tym stojącym.
Chciałbym więc w tym artykule przekazać kilka porad, w jaki sposób pracować bardziej zwinnie. Dzięki temu osiągamy więcej, pracując mniej niż wcześniej.
Minimalizacja Work-in-progress
Pracując w swoim otoczeniu biznesowym mamy możliwość brania coraz to większej ilości zadań. Robię X, ale jednocześnie ktoś poprosił o Y to też nad tym pracuje, a Z leży już rozgrzebane od tygodnia. Wydaje nam się, że dzięki temu osiągamy więcej. Pracujemy efektywnie, bo jednocześnie dowozimy kilka różnych funkcjonalności. Duży błąd.
(By Christoph Roser at AllAboutLean.com)
W 1961 roku John Little udowodnił prawo, nazwane później jego nazwiskiem – prawo Little’a. Mówi ono, że średni czas przebywania pojedynczego zadania w systemie bezpośrednio koreluje z ilością zadań. Im więcej mamy zadań, a nie zwiększamy mocy przerobowych (załóżmy, że nie robimy nadgodzin), tym dłużej zadania trwają. Redukując ilość trwających zadań zmniejszamy czas dostarczenia.
Brzmi to banalnie, ale w dzisiejszych czasach multi-taskingu i prokrastynacji nie widzimy, ile czasu schodzi nam na dokończenie pojedynczego zadania. Wszystko jest rozgrzebane, ale nic nie kończymy. Tylko kończenie zadań, zanim rozpoczniemy nowe, pomoże nam działać optymalniej – szybciej dostarczać wartość i skupiać się na rzeczach ważnych. Jest nawet takie powiedzenie, brzmiące dość coachingowo 😉
„Stop Starting and Start Finishing”
Praca w małych partiach
Największym wrogiem minimalizacji Work-in-progress są ogromne zadania:
- Praca trwa nad nimi godzinami, dniami, a nawet tygodniami.
- Zanim skończymy jedno zadanie wskakuje kolejne, którym musimy się zająć.
- Trudno jest ustalić kryterium zakończenia zadania.
- Często zdarzają się przestoje, ponieważ pojawiły się dodatkowe zależności.
- Mają dużo błędów, które opóźniają ich wykonanie.
Aby zminimalizować ilość trwającej pracy najlepszym sposobem jest praca na małych partiach. Bardzo dobrze obrazuje to gra Penny Game:
- Osoby są umieszczone jedna po drugiej
- Pierwsza osoba odwraca monety
- Może przełożyć odwrócone monety dopiero, gdy uzbiera odpowiednia ilość w partii
- Ilość w partii zmienia się co rundę, odpowiednio: wszystkie / 20 / 10 / 5 / 1 moneta
Po zakończonej grze jasno widać, że najszybciej praca przebiega, gdy przekazujemy pracę do następnej osoby wcześniej, niż później. Przy przesuwaniu wszystkich monet gra trwa kilka minut, przy 1 monecie może zamknąć się poniżej minuty. I tak samo jest w naszej codziennej pracy.
Nie twórzmy ogromnych zadań, ponieważ mają one tendencję do przedłużania się. Skupiajmy się na kawałku, który jesteśmy w stanie jak najszybciej zakończyć. Mając ściśle opisane kryteria zadania wiemy co i jak mamy zrobić. Rzadziej wystąpią niespodziewane sytuacje i problemy. Rozdzielanie większych funkcjonalności na małe części zwiększa tempo i jakość dostarczonej pracy.
Pomoc kolegom z zespołu
Praca w zespole dostarczającym to praca wspólna, mająca na celu dostarczanie nowych funkcjonalności. Nie jest tutaj ważna pojedyncza efektywność – liczy się efektywność całego zespołu. Łatwo o tym zapomnieć, szczególnie jeśli jesteśmy rozliczani jako pojedyncze osoby za wykonane zadania.
Np. często słyszy się o takim pojęciu jak „górka testerska”. Czyli mamy jednego testera w zespole, który nie wyrabia się z testowaniem funkcjonalności, których dostarczamy. Z drugiej strony developerzy wrzucają co raz to nowe zadania jeszcze tylko zwiększając ilość pracy testera. Nikogo nie interesuje, ile zadań jest rozpoczęte – ważne, by wyrabiać kolejne zadania. A to wcale nie posuwa nas do przodu, a nawet jeszcze bardziej opóźnia dostarczanie.
(By Newcastle Systems at newcastlesys.com/blog/warehouse-bottlenecks-that-need-your-attention)
Dlatego zamiast skupiać się na efektywności pojedynczej osoby warto spojrzeć szerzej i zastanowić się co jest naszym wąskim gardłem w procesie. I ten problem starać się rozwiązywać. Możemy przecież spytać naszego testera, czy nie pomóc mu w testowaniu konkretnego obszaru, którego sami nie pisaliśmy. Albo przeanalizować z nim poszczególne zadania przed rozpoczęciem pracy, by uniknąć trywialnych błędów. Zdejmiemy z niego część obowiązków a dzięki temu przyśpieszymu cały proces.
Nastawienie na wspólny rezultat
O wiele łatwiej jest stworzyć atmosferę pomocy wewnątrz zespołowej, kiedy sam sposób pracy do tego zachęca. Wynika to z prostego faktu – jeśli jestem rozliczany jedynie za to, co sam robię nie patrząc na innych to takie działanie będzie dla mnie najbardziej optymalne. A to powoduje okopywanie się w swoich zadaniach i brak wsparcia dla współpracowników.
Najlepszym rozwiązaniem w tym kierunku jest stworzenie zespołów nastawionych na rezultat. Praca w takim zespole narzuca kooperację członków i wymusza wspólne działanie w celu rozwoju danego produktu. Nie potrzebujemy spotkań by móc się wymieniać wiedzą – mamy tych ludzi obok siebie. A przede wszystkim zwiększymy odpowiedzialność za całość, a nie jedynie za poszczególne części.
Dobrym sposobem by posuwać się w stronę takich zespołów jest spisanie i trzymanie się zasad Definition of Done. Narzuca to myślenie nastawione na cały zespół, a nie na pojedynczą osobę. Pozwala widzieć naszą pracę z wyższej perspektywy i skupiać się na tym,by była zawsze całkowicie zakończona. Trudniej jest wtedy sobie powiedzieć, że „ja swoją część zakończyłem”.
Samodoskonalenie
Jeśli jest pewien wskaźnik, po którym jestem w stanie poznać, że zespół jest na drodze ku zagładzie to byłby to brak samodoskonalenia się. Entropia jest nieubłagana – jeśli co jakiś czas nie pracujemy by zaadaptować się do nowych realiów to chaotyczność rzeczywistości będzie coraz bardziej opóźniała nasze prace.
I nie mam tutaj na celu typowych spotkań typu Retrospektywa. One są tylko jednym z wielu sposobów na samodoskonalenie się. Sam również mam wątpliwości co do efektywności samych retrospektyw w zespołach - często zamienianych na grupową terapię smutków i zażaleń lub wewnętrzne podsumowanie sprintu.
Samodoskonalenie można postrzegać jak wdrożenie w życie schematu nazwanego Cyklem Deminga.
(By Karn Bulsuk at pl.wikipedia.org/wiki/Cykl_Deminga)
Do tego nie potrzeba żadnych specjalnych spotkań, ceremonii, inicjatyw. Widzimy, że coś nie działa odpowiednio i staramy się to zaadresować. Metodą małych kroków poprawiamy rzeczywistość wokół nas. Z dnia na dzień nasza praca staje się o wiele przyjemniejsza, ale przede wszystkim bardziej efektywna.
Wizualizacja
Większość osób pośród nas jest wzrokowcami (książka). Nie widząc naszej pracy bardzo trudno jest nam ją sobie wyobrazić czy nią zarządzać. Pewnych rzeczy nie da się uświadomić zespołowi bez odpowiedniej wizualizacji. Można nie wierzyć, że bierzemy zbyt dużo zadań, kiedy nie widzimy ich realnie „na sobie”.
Odpowiednio dobrze dobrane narzędzia bądź techniki pozwalają nam z tymi problemami walczyć. Możemy zauważyć, że podążamy w złym kierunku bądź podejmujemy błędne decyzje. Mając zgrupowane zadania widzimy kto jest najbardziej obłożony i komu trzeba pomóc. Możemy przeciwdziałać ad-hocom wrzucanym z zewnątrz, bo będą inaczej oznaczone. Widząc więcej wiesz więcej.
Możemy zastosować np.:
- Limit Work-in-Progress – by nie przekraczać zbyt dużej ilości rozgrzebanych zadań
- Macierz zależności – by zwizualizować które komponenty łączą się ze sobą
- Wydrukowanie Definition of Ready / Done – by zawsze przypominały o sposobie pracy w zespole
- Oznaczenie pracy nieplanowanej – by później się zastanowić nad powodami jej wystąpienia
- Naklejenie kartki z blokerem – by pokazać, że kolejny dzień nie możemy nad czymś pracować
- Barometr zespołu – by dostrzec jakie jest morale zespołu
W zasadzie ogranicza nas jedynie własna wyobraźnia. Bądź narzędzie, które używamy. Dlatego też jestem zwolennikiem pracy przy tablicy fizycznej, kiedy zespół jest kolokowany fizycznie – łatwiej jest dokonywać takich zmian jakie nam są potrzebne. Przy systemie informatycznym jest to o wiele trudniejsze (ale nie niemożliwe).
Podsumowanie
Spisałem 6 porad z mojej strony jak się posuwać w stronę bardziej płynnej pracy. Nie są to zbyt trudne kwestie, by nie zacząć ich wdrażać w życie w ciągu najbliższych dni / tygodni. Pomogą Ci podejść do problemów bardziej zwinnie i lepiej się adaptować do zmian. A one zawsze nadejdą.
A Ty, co mógłbyś mi poradzić w kwestii pracy zwinnej?
