Czy stać Cię na marnotrawstwo?

Jakiś czas temu Igor Springer w artykule Gdzie Scrum nie może tam Kanban pośle opisywał czym jest Kanban i jakie są jego podstawowe zasady.

Dzisiaj chciałbym przyjrzeć się 7 marnotrawstwom, które definiuje Kanban.
Domyślnie są to: Zapasy (Inventory), Nadprodukcja (Overproduction), Zbędne przetwarzanie (Extra processing), Transport(Transportation), Oczekiwanie (Waiting), Zbędny Ruch (Motion), Braki oraz ich naprawa (Defects).

Mary and Tom Poppendieck w niezłej książce “Lean Software Development: An Agile Toolkit” przełożyli 7 marnotrawstw Kanbana na realia wytwarzania oprogramowania. I tak oto mamy:

• Niedokończone zadania (Partially done work),
• Niepotrzebne/dodatkowe funkcjonalności (Extra features, overproduction),
• Uczenie się na nowo (Relearning)*,
• Przekazywanie (Handoffs),
• Oczekiwanie (Waiting),
• Wielozadaniowość i zmienianie zadań (Task Switching),
• Błędy (Defects)

Niedokończone zadania (Partially done work)

Wiele osób i zespołów developerskich ma tendencję do rozpoczynania zadań przy jednoczesnym niedomykaniu spraw do końca. W efekcie tracimy unikalną szansę na benefity płynące z krótkiej ścieżki informacji zwrotnej (patrz: Potęga szybkiego feedbacku), zwiększanie pracy w toku (Work In Progress) i narażanie się na kolejne marnotrawstwo: Wielozadaniowość i zmienianie zadań. Zmiana perspektywy z “co dzisiaj zrobię” na “co dzisiaj ukończę” bez wątpienia może przynieść wiele pożytku.

Z niedokończonymi zadaniami wiąże się jeszcze jeden ciekawy efekt opisany przez rosyjską psycholog i psychiatrę Blumę Zeigarnik, zwany potocznie efektem Zeigarnik: Skłonność do doświadczania natrętnych myśli o niekompletnym celu. Lub inaczej mówiąc – lepiej pamiętamy rzeczy, których nie skończyliśmy, a to oznacza, że niepotrzebnie zaprzątają one nam głowę.

I pamiętajmy o jednym: dopóki funkcjonalność nie jest skończona, nie przynosi żadnej wartości dla klienta, niezależnie od tego, ile czasu dotychczas spędziliśmy na jej realizacji.

Wielozadaniowość i zmienianie zadań (Task Switching)

Niedokończone zadania prowadzą nas do kolejnego marnotrawstwa: nieefektywnej wielozadaniowości, najczęstsze zdarzenia, które ją powodują to:

• „Super pilne zadanie” – czyli rzuć wszystko i zrealizuj teraz TO zadanie
• Awarie i błędy
• Spotkanie w środku dnia albo po prostu spotkanie, które nie zostało wcześniej zaplanowane
• „Sprawdź tylko jeden drobiazg”

We wszystkich tych przypadkach koszt powrotu do poprzedniego zadania jest ogromny i na dłuższą metę jest męczący.

Ciekawy eksperyment rozpoczął kilka miesięcy temu Pinterest, ustalając zasadę, że we wtorki, środy i czwartki zespół developerski nie ma żadnych spotkań i może skupić się na swojej pracy. Oczywiście spowodowało to, że w poniedziałki i piątki tych spotkań było relatywnie więcej (to, że usunęliśmy z kalendarza spotkanie nie oznacza, że było ono niepotrzebne, dalej jest potrzeba je zrobić, ale mamy do dyspozycji tylko poniedziałek lub piątek). Jak na razie Pinterest trzyma się swojego eksperymentu.

Uczenie się na nowo (Relearning)

W książce „Lean Software Development: An Agile Toolkit” w miejsce „Relearning” autorzy skupili się na „Extra processes”, natomiast w wielu publikacjach i artykułach możemy znaleźć wspomniane „Relearning” i to właśnie to marnotrawstwo chciałbym tutaj przybliżyć.

Uczenie się na nowo to nic innego jak strata czasu na to, żeby przypomnieć sobie dlaczego dana funkcjonalność została napisana / zaprojektowana w ten, czy w inny sposób. W najlepszym wypadku wiąże się to ze stratą czasu, w najgorszym – mamy tzw. “potworki”, których nikt nie chce dotykać “żeby niczego nie zepsuć”, gdyż ryzyko potencjalnej regresji jest bardzo duże.

Uczenie się oczywiście przynosi wartość, ponieważ możemy albo dostarczyć lepszy produkt, albo dostarczyć dobry produkt szybciej, natomiast gdy musimy się uczyć na nowo, tzn. że gdzieś nam uciekła wartość tego, że już się tego nauczyliśmy.

Przygotowywanie rozwiązań jest bardzo ważne, ale równie ważne jest aby pamiętać, że kiedyś w przyszłości będziemy musieli do tego miejsca wrócić (zmiana wymagać, poprawa błędów) i nie chcielibyśmy tracić czasu na dochodzenie do rozwiązania od nowa.

Przekazywanie (Handoffs)

Przekazywanie informacji lub efektów pracy przez jednego członka zespołu do drugiego może spowodować utratę lub zmianę informacji. Wszyscy pamiętamy zabawę z dzieciństwa głuchy telefon i byłoby dobrze, gdyby na wspomnieniach z dzieciństwa się skończyło.

Niestety, cały czas uczestniczymy w tej „zabawie” w życiu zawodowym (oraz prywatnym) z lepszym lub gorszym skutkiem.Prosty przykład: komunikowanie wymagań klienta, które przechodzą od przedstawiciela klienta do analityka, następnie kierownika zespołu, a na koniec do programisty i testera.

Oczekiwanie (Waiting)

I tutaj dochodzimy do kolejnego marnotrawstwa: oczekiwanie na efekty prac innych osób. Jeśli jesteśmy zależni od efektów pracy innej osoby, lub po prostu mamy dalej pociągnąć temat – planujemy sobie kiedy zaczniemy realizować nasze obowiązki, rezerwujemy sobie czas. W sytuacji, gdy druga osoba nie dowozi obietnic, w najlepszym przypadku tracimy czas na przeorganizowanie naszego planu działania i naszego kalendarza, w najgorszym – jesteśmy przyblokowani i tracimy czas bezproduktywnie (tzw. “Idle time” – nie mylić z tzw. “Slack time”, który potrafi być bardzo pożytecznym elementem w pracy zespołowej).

Błędy (Defects)

W tej samej książce “Lean Software Development: An Agile Toolkit” Mary and Tom Poppendieck piszą:
Ilość czasu straconego spowodowanego przez błędy = (wpływ błędów) x (czas, kiedy błąd nie został wykryty)
Wydatki poniesione na naprawienie usterki wykrytej na wczesnych etapach są znacznie niższe niż koszty utrzymania i obsługi błędów wykrytych na działającym już systemie. Wracanie po dłuższym czasie do funkcjonalności znacząco podnosi ryzyko wpadniecia w pułapkę „uczenia się na nowo”.
Pamiętajmy też, że naprawiając jedną usterkę możemy nieświadomie spowodować regresję w innej części produktu.

Niepotrzebne/dodatkowe funkcjonalności (Extra features, overproduction)

Każda funkcja (bez względu na to jak dobra/przydatna), która nie jest wymagana przez klienta lub użytkownika końcowego, jest nadmiarowa. Na pierwszy rzut oka wydawałoby się, że nie ma nic w złego w tym, że się wykazaliśmy i zrobiliśmy coś “ekstra”. Pamiętajmy tutaj o jednym: niepotrzebna funkcjonalności to nic innego jak więcej kodu do utrzymania, zwiększenie ryzyka występowania błędów (nowy obszar w produkcie, który trzeba testować) i tego, że obsługując te błędy w przyszłości nie będziemy mogli poświęcić tego czasu na funkcjonalności, na których powinniśmy skupić swoją uwagę.

Podsumowanie

Analizując z jakimi marnotrawstwami mamy do czynienia w naszej organizacji / zespole warto mieć świadomość, że nie jest celem samym w sobie zlikwidowanie wszystkich strat, bo to po prostu niemożliwe.

Mamy przecież tzw. niezbędne marnotrawstwa – nie dodające wartości, ale niezbędne do wykonania zadań w sposób jakościowy. Takie działania mogą polegać na testowaniu, planowaniu, raportowaniu itp.

Zdecydowanie za to powinniśmy się przyjrzeć tym marnotrawstwom, które nie są wartościowe i są po prostu niepotrzebne. Miejmy na uwadzę wszystko to, co nie przynosi wartości i może zostać natychmiast usunięte z procesu, a sam temat strat i marnotrawstw świetnie nadaje się na retrospektywę.

Rysunki pochodzą z bloga: SketchingPM.com