Jarek ŁojkoWe wpisie Kanban – tablica czy metodyka wspominałem fabrykę Toyoty z początków XX wieku jako protoplastę prostego systemu Kanban. Jednak ówczesny jej menedżer i twórca Toyota Production System, Taiichi Ohno, jest szeroko kojarzony także z inną koncepcją. Swoim sposobem myślenia stworzył on podwaliny metody Lean Management minimalizującej zjawisko określane jako muda. Japończyk określił swoje podejście do zarządzania następującymi słowami.
W oparciu o zasady Systemu Produkcyjnego Toyoty powstała następnie cała koncepcja zarządzania procesem produkcyjnym – Lean Manufacturing. Ta z kolei dała podwaliny Lean Managementowi (pol. szczupłe zarządzanie) czyli pojęciu jeszcze szerszemu, stosowanemu poza przemysłem i typowymi fabrykami. Podejście Lean skupia się na ciągłym udoskonalaniu i eliminowaniu marnotrawstw, a co za tym idzie redukcji czasów procesów i podniesieniu ich efektywności.
Co to jest muda?
Muda (jap. ムダ) to właśnie japońskie określenie marnotrawstwa. Jego dosłowne znaczenie to zbędny, bezużyteczny. Innymi słowy muda to wszystkie czynności i działania, które nie dodają żadnej wartości i nie spełniają potrzeb klienta, a pochłaniają cenny czas i inne zasoby.
Niektóre z nich można zaobserwować gołym okiem w naszym codziennym życiu i są dla nas dosyć oczywiste. Przykładowo jeżeli zrobimy za duże zakupy spożywcze. Zanim zdążymy je skonsumować to zapewne część produktów się przeterminuje i wyląduje w koszu marnując nasze pieniądze.
Są też inne, mniej oczywiste rodzaje strat, ale również bardzo negatywnie wpływające na nasze zasoby i efektywność. W Lean Management wyróżnia się aż 9 rodzajów mudy.
Muda w Lean Management vs Lean Software Development
Metoda Lean Software Development stworzona i spopularyzowana przez Mary i Toma Poppendiecków za sprawą książki o tym samym tytule, to zastosowanie zasad Lean Managementu w wytwarzaniu oprogramowania. Podstawową jej zasadą jest również eliminowanie wszelkiego rodzaju czynności nie dodających wartości.
Autorzy książki mapują różne rodzaje marnotrawstw z Lean Manufacturing z ich odpowiednikami w procesie software developmentu. Przejdźmy do szczegółowego omówienia zarówno jednych jak i drugich.
Nadprodukcja, nadmiarowe funkcjonalności
Nadprodukcja jest w uproszczeniu wszystkim tym co wykonujemy nie wtedy, kiedy jest potrzebne. Muda pojawia się, gdy przekazujemy więcej, szybciej czy wcześniej niż jest to wymagane w danym momencie. Jest zatem przeciwieństwem zasady “just in time”.
Przykładem z korporacyjnego życia wziętym może być:
- Generowanie z wyprzedzeniem różnego rodzaju raportów, do których potem nikt nie zagląda. Co gorsza na ich podstawie nie podejmuje się też żadnych decyzji, a zatem dane w nich zawarte są zbierane dla samego zbierania. Jakby tego było mało to zazwyczaj szybko się dezaktualizują. A zatem co jakiś czas trzeba przygotować nowy raport…
Można by pokusić się o stwierdzenie, że wszelkiego rodzaju audyty, jeżeli nie prowadzą do optymalizacji i poprawy procesów, również są mudą. - Wysyłanie niezliczonej liczby maili. Zerknij na swoją skrzynkę pocztową i odpowiedz sobie szczerze na jedno pytanie. Ile wiadomość było faktycznie wartościowych i potrzebnych, a ile to po prostu nadmiar komunikacji?
W kontekście Lean Software Development i tego rodzaju mudy mówi się o nadmiarowych funkcjonalnościach (Extra Features). Jeżeli dany kawałek kodu nie jest potrzebny w tym momencie to nie powinniśmy zużywać na niego naszego cennego czasu i budżetu rozwoju produktu.
Przypomina mi się w tym momencie pewna sytuacja z życia wzięta. W jednym z zespołów, w którym pełniłem rolę Scrum Mastera, pewien developer wpadł na “genialny” pomysł. Otóż nie uprzedzając nikogo zaimplementował w systemie CRM widget wyświetlający prognozę pogody. Od tak, po prostu uznał, że będzie to fajna funkcjonalność, więc czemu by nie. Akurat zostało mu trochę czasu w Sprincie, bo skończył wszystkie swoje zadania. Jak możesz się domyśleć jego pomysł nie spotkał się z wielkim entuzjazmem Product Ownera i nie został wdrożony na produkcję, gdyż po prostu nie był nikomu potrzebny. Spowodował jedynie wzrost złożoności systemu i zmarnowanie cennego czasu i pieniędzy.
Nie zawsze dokładanie nowych funkcjonalności podnosi wartość produktu. Czasami jest wręcz odwrotnie. Jak to kiedyś ładnie ujął Antoine de Saint Exupéry,: “Perfekcję osiąga się wtedy, gdy nie można już nic odjąć, a nie dodać.”
Widywałem również implementacje całych frameworków czy bibliotek developerskich służące tylko temu, aby wyświetlić kilka prostych danych użytkowników z bazy. Gdy dane narzędzie jest akurat popularne to często Developerzy próbują je wdrożyć “przy okazji”, bo “chcą się pobawić” ;).
Nadprodukcja to strata. Ogranicz ją w swoim zespole, a zdziwisz się ile zwolni się czasu na rozwój tego, co na prawdę istotne.
Zbędne zapasy i nieukończona praca
Wiele osób (w tym ja) ma tendencje do chomikowania, zbierania i odkładania na półkę niepotrzebnych rzeczy. Przykładowo książek, które nawet im się nie podobały.
Z punktu widzenia lean, zbędne zapasy to kolejny rodzaj mudy.
W naszej pracy najczęściej gromadzimy tony dokumentów czy prezentacji zarówno w wersji papierowej jak i elektronicznej. Nagminną praktyką jest tworzenie dodatkowych przestrzeni w Confluence o nazwie “Archiwum” i odkładanie tam wszelkich śmieci, które od dawna nie są już nikomu potrzebne. No ale przecież “nigdy nie wiadomo”…
Odnosząc ten rodzaj mudy do Lean Software Developmentu mówimy o nieukończonych pracach (Partially Done Work). Innymi słowy w tej kategorii zmieszczą się wszystkie rozgrzebane zadania czy historyjki użytkownika, które nie spełniają Definition of Done. Chyba nie muszę tutaj dodawać, że nie ma czegoś takiego jak “prawie Done”, bo prawie robi wielką różnicę ;).
Dopóty, dopóki całość wytwarzanego kodu nie jest zintegrowana i umieszczona na odpowiednim środowisku, nie możemy mieć pewności, że faktycznie działa i przynosi zamierzoną wartość biznesową. Nie wiemy także czy nie spowoduje dodatkowych problemów i błędów, za to na pewno podniesie poziom złożoności systemu. A zatem ograniczanie mudy w postaci nieukończonych prac to także redukowanie ryzyka.
W jednym z moich zespołów Developerzy dosyć często wpadali w pułapkę “prawie gotowych” User Stories. Niedokończone zadania określane były mianem “spadochroniarzy”, którzy “sfruwali” sobie po prostu automatycznie do następnego Sprintu… Zespół nie widział w tym większego problemu, dopóki nie użyłem wobec niego następującej analogii. Przecież przy każdym desancie spadochroniarzy, część z nich wplątuje się w gałęzie drzew, wpada do wody czy łamie nogi i trzeba później zużyć dodatkowe zasoby na ich ratowanie…
Jeżeli podobna sytuacja pojawia się w twoim zespole postarajcie się po prostu zaplanować mniej w kolejnej iteracji. Zgodnie z zasadą jedna historyjka DONE jest warta więcej niż tysiąc IN PROGRESS (=almost DONE).
Oczekiwanie to także muda
Wszystko, co powoduje przestoje w procesie i wymusza bezproduktywne oczekiwanie, to kolejny rodzaj mudy. Częstym przykładem tego typu marnotrawstwa w korporacjach jest z pewnością oczekiwanie na wszelkiego rodzaju dostępy do systemów, podpisy, akceptacje czy decyzje. Opóźnianie decyzji i konsekwencje z tym związane, to też decyzja…
Pamiętam swój początek w roli Scrum Mastera w jednej z firm, gdzie czekałem na służbowy komputer ponad dwa tygodnie… Chyba nie muszę tłumaczyć jak jego brak wpłynął na efektywność moich działań w pierwszych dniach w nowym miejscu pracy. Moje rozwiązanie, czyli praca na prywatnym sprzęcie, było chyba jeszcze gorsze niż sama muda, bo złamałem prawdopodobnie wszystkie możliwe zasady bezpieczeństwa ;).
W jednym z moich Zespołów Scrumowych, celem poprawienia jakości, dopisaliśmy pewnego dnia do naszej Definition of Done dodatkowy punkt. Historyjka nie mogła być uznana za zakończoną, jeżeli nie zostało wykonane code review przez innego Developera. Zespół ustalił, że będzie je wykonywał jeden, najbardziej doświadczony członek zespołu Szybko okazało się, co było zresztą do przewidzenia, że stworzyliśmy tak zwane wąskie gardło.
Jako, że limitowaliśmy też pracę w toku (WIP limit), to zadania i historyjki, które nie przeszły jeszcze pozytywnie inspekcji kodu, blokowały Developerów przed rozpoczęciem prac nad kolejnymi. Z kolei wspomniany senior Developer został już w drugim, trzecim dniu Sprintu zasypany prośbami o review. Spowodowało to, że czas oczekiwania na przegląd znacząco się wydłużał i był bezpowrotnie marnowany.
Jak najprościej zweryfikować czy w twoim zespole nie występuje muda związana z oczekiwaniem? Polecam zajrzeć na tablicę kanbanową w Jirze. Im więcej kropek namaluje się u dołu danej karty, tym dłużej wisi ona już bez zmian w danym statusie. Jeżeli widzisz coś podobnego jak na obrazku poniżej, zbadaj dlaczego tak się dzieje i czy czasami nie zetknąłeś się z tym rodzajem lean’owego marnotrawstwa.
Nadmierne przetwarzanie
Kolejny rodzaj marnotrawstwa to sytuacja gdy wykonywana czynność nie tworzy żadnej wartości dodanej lub nie jest konieczna w danym procesie. Lean tego rodzaju aktywności nazywa nadmierny przetwarzaniem (Extra Processing). Przykładowo może być to wielokrotne przepisywanie tych samych danych, dublowanie wniosków, raportów czy… liczenie ponownie na kalkulatorze tego, co zostało policzone już w Excelu (naprawdę niektórzy tak robią).
Wielu Agile Coachy i Scrum Masterów zapewne uśmiechnie się pod nosem jeżeli wspomnę przygotowywanie wszelkiego rodzaju prezentacji dla menedżerów, dyrektorów i tak zwanego C-Levelu. Same dane czy informacje merytoryczne to dopiero pierwszy krok. Wszystko trzeba jeszcze przecież ponownie, obrobić, przerobić, pokolorować i poupychać na korporacyjne slajdy. Najlepiej w pięknym szablonie, na stworzenie którego ktoś poświęcił kilka miesięcy swojego życia.
W tym miejscu przypomina mi się też proces rozliczania przepracowanych godzin dla jednej z organizacji. Aby otrzymać wypłatę za miniony miesiąc musiałem wypełnić trzy różne dokumenty z raportem godzinowym. Jeden w szablonie pośrednika, drugi w szablonie klienta, trzeci w szablonie mojego przełożonego, który prowadził własną ewidencję. Poza przygotowaniem dokumentów niezbędne było jeszcze oczywiście wprowadzenie (po raz czwarty!) tych samych informacji w systemie.
Odnieśmy ponownie zasady Lean Management do Lean Software Development.
W kontekście wytwarzania oprogramowania nadmierne przetwarzanie ma swoje odzwierciedlenie w nadmiernych procesach (Extra Processes).
Aż chciało by się zacytować w tym miejscu Manifest Agile i “Ludzie i interakcje ponad procesy i narzędzia” oraz “Działające oprogramowanie ponad obszerna dokumentacja”.
To właśnie proces tworzenie nadmiernej dokumentacji jest często rozpatrywany pod kątem marnotrawstwa. Jeżeli jej przygotowywanie jest sztuką dla sztuki i nie służy nikomu na dalszym etapie procesu to znak, że mamy do czynienia z kolejną mudą.
Oczywiście jeżeli dokumentacja jest przydatna do pisania scenariuszy testowych, kodowania czy przygotowywania instrukcji i manuali dla klienta to nie możemy wrzucić jej do tego samego worka co inne, bezwartościowe procesy. Innymi słowy, jeżeli ktoś na nią czeka i wykorzystuje w konkretnym celu to nie ma powodów do obaw. Nie zmienia to jednak faktu, że w duchu zarówno Lean jak i Agile będzie stałe poszukiwanie coraz lepszych i skuteczniejszych metod przekazywania informacji w niej zawartych.
Innym, często spotykanym w dużych organizacjach, przykładem nadmiernych procesów jest przepisywanie zadań czy incydentów pomiędzy różne programy do zarządzania projektami typu Jira, Asana, Redmine itp. Widywałem niejednokrotnie zespoły, które korzystały z dwóch różnych, niezintegrowanych ze sobą programów i wszystkie zadania musiały być zdublowane. Jeden służył przykładowo do rozplanowania Sprintów, a drugi do raportowania czasu pracy.
Najbardziej utkwiła mi jednak w pamięci inna historia. W pewnej firmie zespół wsparcia tak bardzo przyzwyczaił się do tworzenia ticketów i nadmiernego ich przetwarzania, że kompletnie odciął się od rzeczywistości poza nimi. Doprowadziło to do jednej groźnej sytuacji, w której pomimo poważnej awarii nikt nie podjął się prac nad incydentem. Został on odrzucony, bo nie było wypełnionej odpowiednio formatki, brakowało mailowego potwierdzenia od przełożonego, że incydent musi dostać wysoki priorytet, zgody od Product Ownera oraz opinii Lead Developera…
Transport i zbędny ruch
Kolejna muda to przemieszczanie czegokolwiek z miejsca na miejsce bez dodawania żadnej wartości.
Każda wizyta w polskim urzędzie to niestety dobitne doświadczenie tego rodzaju marnotrawstwa na własne oczy. Wszechobecny, bezsensowny transport najróżniejszych wniosków i dokumentów jest w nich niestety standardem. Papiery krążą w kółko od jednego urzędnika do drugiego, od okienka do okienka, od okienka do kasy, od kasy do gabinetu… Urząd to trochę taki synonim mudy, bo można ją tam spotkać w każdym możliwym zakresie.
Przypomina mi się również historia z mojego studenckiego stażu sprzed lat. Do moich zadań należało między innymi noszenie papierowych faktur z działu marketingu do księgowości. Problem w tym, że oba te departamenty były ulokowane w osobnych biurowcach i taka wycieczka w obie strony trwała około 15-20 minut. Niepotrzebny transport może dotyczyć nie tylko papierów i wydruków z print room’ów (które nie wiedzieć czemu zawsze są ulokowane kilometry od twojego biurka), ale także maili czy plików.
Odpowiednikiem bezwartościowego transportu w Lean Software Development jest “żonglowanie” zadaniami (Task Switching) w różnych projektach. Każde przełączenie się członka zespołu pomiędzy dwoma różnymi kontekstami powoduje wytrącenie ze skupienia oraz zużywa cenną energię i czas na wejście w ten stan ponownie.
Wydawałoby się, że robiąc dwa projekty na raz przy pomocy tych samych Developerów zrobimy je szybciej. Nic bardziej mylnego, jakby to powiedział Radek Kotarski. Lepszym rozwiązaniem jest pełne skupienie i dokończenie jednego, a następnie rozpoczęcie prac nad drugim.
Jeżeli wciąż nie wierzysz, albo masz w swoim zespole osobę, która uważa, że ma legendarną podzielność uwagi, zaproponuj jej następujący eksperyment złożony z dwóch rund.
Runda 1
- Poproś swojego mistrza multitaskingu o wypisanie na kartce A4 ciągu następujących znaków mierząc czas.
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
A, B, C, D, E, F, G, H, I, J
I, II, III, IV, V, VI, VII, VIII, IX, X - Kluczowy jest sposób. W tej rundzie należy je wypisać wierszami. Czyli najpierw wszystkie cyfry arabskie, następnie litery, a na końcu cyfry rzymskie. Zanotuj czas potrzebny na ukończenie zadania.
Runda 2
- Druga runda to wykonanie tego samego zadania ponownie, na drugiej stronie kartki, ale w inny sposób. Tym razem znaki należy wpisywać kolumnami czyli 1, A, I, następnie 2, B, II i tak dalej…
- Zanotuj wynik z tej rundy i porównaj oba czasy. Gwarantuję, że już przy tak banalnym multitaskingu zauważysz znaczącą różnicę w czasach wykonania zadania. A co dopiero przy bardziej złożonych i skomplikowanych czynnościach?
Transport nie przynoszący wartości może dotyczyć nie tylko dokumentów czy plików, ale także osób. Określany jest wówczas zbędnym ruchem. Nie bez przyczyny rekomenduje się, aby agile’owe zespoły w całości były ulokowane w jednym miejscu. Dużo prościej obrócić się po prostu przy biurku, aby dopytać swojego Product Ownera o daną historyjkę użytkownika niż jechać do niego windą na inne piętro wieżowca. Krążenie po biurze w poszukiwaniu wolnej salki konferencyjnej, bo 15 minut temu powinniśmy byli zacząć Sprint Planning to również muda.
W jednym ze swoich Zespołów Scrumowych, dla ograniczenia zbędnego ruchu, zrobiliśmy prostą rzecz. Dogadaliśmy się z administracją, że chcemy mieć na stałe zarezerwowaną salkę konferencyjną tuż obok biurek zespołu i wyłączyć ją tym samym z rezerwacji dla osób spoza tego grona. Odbywały się w niej wszystkie wydarzenia Scumowe, sesję 1:1, refinementy, burze mózgów, swarmingi itp. Dzięki temu prostemu zabiegowi zaoszczędziliśmy średnio około 1,5 godziny czas miesięcznie, który normalnie był marnowany na szukanie i rezerwacje sal, chodzenie po biurowcu, wyrzucanie osób które zajęły salkę pomimo braku rezerwacji itp…
W analogiczny sposób zbudowane są przestrzenie biurowe zespołów w Spotify, patrz obrazek poniżej. Wszystko w jednym miejscu, osobna strefa do pracy, osobna do spotkań, burz mózgów i odpoczynku. Wszystkie niezbędne narzędzia i tablice pod ręką.
Pomijając bez wątpienia pozytywny wpływ większej liczby kroków na nasze zdrowie, z punktu widzenia lean management jest to muda ;).
Szukanie i wyjaśnianie
Jeżeli zespół musi poświęcać czas na wyjaśnianie lub poszukiwanie niezbędnych do pracy informacji, dokumentów czy decyzji to mamy do czynienia z kolejnym rodzajem mudy. Może być ona efektem na przykład nieuporządkowanego czy nietransparentnego procesu.
Często z tym rodzajem marnotrawstwa spotykają się nowe osoby dołączające do organizacji. Okazuje się, że lista zadań onboardingowych, które otrzymały jest niekompletna i częściowo się zdezaktualizowała. Chociażby dlatego, że osoba kontaktowa do wydawania przepustek do biurowca się zmieniła, proces wnioskowania o urlop wygląda inaczej, bo HR-y zaktualizowały swój system, a karty benefit zostały wstrzymane z powodu pandemii. Dojście do właściwej procedury zajmuje czas, który oczywiście zostaje bezpowrotnie zmarnowany. Brzmi znajomo?
Błędy i braki
Wszystkie niepoprawnie zrealizowane zadania lub te wymagające ponownego wykonania to kolejny, dosyć oczywisty rodzaj mudy. Przykładowo błędnie zaimplementowane funkcjonalności, niepoprawnie wpisane dane, błędy w umowach czy brakujące decyzje blokujące proces.
Z punktu widzenia Lean Software Developmentu nie trzeba chyba dodawać, że im więcej defektów i bugów w kodzie tym gorzej. Nie należy jednak zapominać, że kluczowy jest też czas wykrycia danego błędu, a nie samo popełnienie go. Bugi będą się pojawiać zawsze i jest to całkowicie normalne zjawisko. Jeżeli natomiast zidentyfikujemy je szybko i również szybko poprawimy to nie będą stanowiły aż tak dużej mudy. Dużo gorszy będzie błąd odkryty po dłuższym czasie, który już spowodował nieodwracalne zmiany. Przykładowo niedziałająca integracja z systemem płatności, która spowodowała porzucenie koszyka przez wielu klientów.
Dlatego właśnie tak kluczowe w zespołach zwinnych jest wczesne testowanie i szybkie integrowanie kodu. Dzięki temu ograniczamy znacząco ryzyko późnego wykrycia błędów i związanych z nimi bolesnych konsekwencji.
Dobrą praktyką jest również głębsza analiza podstawowych przyczyn powstawania błędów. W jednym z moich Zespołów Scrumowych zaimplementowaliśmy następujący mechanizm. Przed zamknięciem danego defektu w Jirze należało wybrać z przygotowanej wcześniej przez zespół listy co potencjalnie stanowiło jego przyczynę. Do wyboru było między innymi: czynnik ludzki, czeski błąd, niezrozumienie wymagań historyjki, niespełnienie kryteriów akceptacji, niedokładne testowanie.
Przez jakiś czas zbieraliśmy dane o wszystkich błędach zanim podjęliśmy kolejne kroki. Ku zdziwieniu zespołu większość (około 75%) błędów, na przestrzeni kilku Sprintów, była spowodowana niezrozumieniem Historyjek Użytkownika. Dzięki zebranym danym mogliśmy podjąć kolejne kroki u źródła problemu i zapobiec wielu kolejnym bugom. Skoro Developerzy mieli problemy z interpretacją wymagań niezbędne było poprawienie jakości naszych sesji refinementowych, a nie przykładowo zastosowanie częstszego programowania w parach. Dzięki temu, w przeciągu dwóch Sprintów zredukowaliśmy liczbę bugów względem historycznych iteracji o prawie połowę.
Zmarnowany potencjał pracowników
Z tego typu marnotrawstwem często można zetknąć się w organizacjach o mocnej strukturze hierarchicznej. Menedżerowie średniego szczebla, z obawy o swoje stanowiska i pozycje, chcą kontrolować wszystko i wszystkich. Zabijają tym samym motywację i zaangażowanie swoich podopiecznych. Brak umocowania pracowników do podejmowania decyzji czy nie wykorzystywanie ich wiedzy to również strata.
Na myśl przychodzi mi tu popularna w jednej z organizacji, w której pełniłem rolę Scrum Mastera, praktyka mianowania “Proxy Product Ownerów”. Na czym polegała? Otóż teoretycznie osoby na tych stanowiskach był namaszczone do bycia Product Ownerami i działania w sposób zwinny. Było jednak jedno “ale”. Wszystkie decyzje odnośnie produktów, które rozwijały miały być potwierdzane z przełożonymi, którymi najczęściej byli dyrektorzy o bardzo niskim stopniu dostępności.
Powodowało to różne patologiczne sytuacje. Pamiętam, że jeden z zespołów nie był w stanie zaplanować kolejnego Sprintu, bo pewien dyrektor nie podjął jeszcze decyzji, a Proxy Product Owner nie był oczywiście umocowany, żeby wziąć ją na siebie. Proxy PO mieli kompetencje i wiedzę jak rozwijać swoje produkty. Niestety nikt jej nie wykorzystał, bo wszystko musiało być sterowane z góry.
Obwinianie
Szukanie kozłów ofiarnych i przyczyny problemów w ludziach zamiast w organizacji pracy czy procesu to ostatni rodzaj mudy według Lean Management. Energia pracowników powinna być skupiona na rozwiązywaniu problemów i zapobieganiu ich w przyszłości, a nie obwinianiu siebie nawzajem. Błędy popełnia każdy, a wytykanie ich palcem nie przynosi żadnej wartości.
Znacie takie określenie jak zbieranie “dupochronów” albo “dupokryjek”? Jest to patologiczna praktyka polegająca na kolekcjonowaniu i wysyłaniu maili, które zawierają pewne istotne dane, decyzje, fakty czy daty. Mają one za zadanie udowodnić niewinność ich posiadacza w kryzysowej sytuacji.
Przykładowo, że dotrzymał terminu, że prosił o przesłanie czegoś, ale tego nie dostał albo działał w oparciu o czyjąś decyzję. Nie odpowiada zatem za konsekwencje kryzysowego zdarzenia i umywa ręce. Tego typu wiadomości zawierają też zazwyczaj na wszelki wypadek całe mnóstwo osób w CC… Chyba nie muszę dodawać, że samo rozwiązanie problemu i kryzysowej sytuacji nierzadko zajmuje mniej czasu niż mailowe dochodzenie do tego kto zawinił.
Zauważyłem też, że niestety bardzo często obwiniane są osoby, które już nie pracują w organizacji. Nie ma na kogo zwalić, nikt się nie przyznaje więc dla świętego spokoju ponarzekajmy na tego kto już nie pracuje, bo przecież jemu/jej już wszystko jedno :P.
Podsumowując, jak widać marnotrawstwo, czy jak kto woli muda, nie jedno ma imię i czasami nie jest oczywiste i widoczne gołym okiem. Jego identyfikacja i ograniczanie to z pewnością dobry krok w kierunku efektywniejszych i bardziej zwinnych zespołów.
Jaki rodzaj mudy występuje najczęściej w twoim zespole? Podziel się komentarzem 🙂
Źródła:
Mary i Tom Poppendieck – Agile Software Development: An Agile Toolkit (link referencyjny)
Dodaj komentarz