Czym jest retrospektywa Fishbone (Ishikawa)?
Retrospektywa Fishbone (Ishikawa) pomaga zespołowi znaleźć przyczyny źródłowe problemu, zamiast leczyć jego objawy. Opiera się na diagramie przyczynowo-skutkowym, który Kaoru Ishikawa spopularyzował w latach 60. XX wieku. Diagram przedstawia możliwe przyczyny w układzie przypominającym szkielet ryby. W tym szablonie zespół analizuje sześć kategorii przyczyn: System, Proces, Formularze, Ludzie, Zasady i Miejsce. Omawianie kategorii po kolei sprawia, że uczestnicy wychodzą poza pierwsze wyjaśnienie, jakie przychodzi im do głowy, dzięki czemu pojawiają się też przyczyny spoza obszaru, za który ktoś odpowiada. Najlepiej sprawdza się przy problemach, na które składa się kilka czynników i których nie rozwiązała jedna oczywista poprawka. Pogrupowanie przyczyn w kategorie pokazuje, jak są ze sobą powiązane, a to wskazuje zmianę, która przyniesie największy efekt. Diagram rybiej ości (nazywany też diagramem Ishikawy lub diagramem przyczynowo-skutkowym; wszystkie trzy nazwy oznaczają to samo narzędzie) umieszcza problem w „głowie” ryby, a główne kategorie przyczyn przedstawia jako ości odchodzące od kręgosłupa. W pierwotnej wersji, stosowanej w produkcji i zarządzaniu jakością, kategorie te to „6M”: Manpower (ludzie), Method (proces), Machine (sprzęt), Material (materiały wejściowe), Measurement (dane i wskaźniki) oraz Mother Nature (otoczenie). Zespół zgłasza możliwe przyczyny przy każdej ości, a potem wciąż pyta „dlaczego?”, by prześledzić każdą gałąź aż do przyczyny źródłowej. Kategorie w tym szablonie dostosowują 6M do zespołów programistycznych i innych zespołów wykonujących pracę opartą na wiedzy. Technika pozostaje ta sama, zmieniają się tylko etykiety, by pasowały do Waszej pracy. Jeśli w głowie ryby znajduje się problem „wydania ciągle się opóźniają”, przyczyną z kategorii Ludzie może być „kluczowy recenzent jest wąskim gardłem”, z kategorii Proces „brak definicji ukończenia (Definition of Done)”, a z kategorii System „niestabilny pipeline CI”. Takie mapowanie przyczyn sprawia, że zespół przestaje naprawiać objaw i dostrzega to, co naprawdę go wywołuje.
Format retrospektywy Fishbone
System
Jakie technologie, oprogramowanie lub narzędzia mogą wpływać na wydajność lub wyniki naszego zespołu?
Przyjrzyjcie się infrastrukturze technicznej, narzędziom programistycznym i miejscom, w których systemy się ze sobą łączą. Pytajcie zarówno o oczywiste usterki techniczne, jak i o mniej widoczne interakcje między systemami, które spowalniają pracę.
Proces
Jakie przepływy pracy lub sekwencje działań powodują opóźnienia albo nieefektywność?
Szukajcie wąskich gardeł, zdublowanych kroków i luk w przepływach pracy. Pytanie o konkretne etapy wykonywania pracy pomaga zespołowi oddzielić problemy procesowe od innych przyczyn.
Formularze
Jakie problemy z szablonami lub dokumentacją mogą wpływać na przejrzystość lub dokładność?
Przyjrzyjcie się szablonom i dokumentacji. Czy ludzie znajdują to, czego potrzebują, czy dokumenty są kompletne i czy spełniają swoje zadanie? Uwzględnijcie zarówno dokumenty formalne, jak i nieformalne.
Ludzie
Jakie czynniki związane z umiejętnościami, komunikacją lub rolami wpływają na nasz sukces?
Rozmawiajcie o umiejętnościach, komunikacji i rolach, ale bez szukania winnych. Skupcie się na warunkach, w jakich pracują ludzie, takich jak niejasne role czy silosy wiedzy, a nie na krytykowaniu konkretnych osób.
Zasady
Jakie wytyczne lub reguły rozmijają się z praktyką albo stwarzają trudności?
Przyjrzyjcie się spisanym i niepisanym zasadom, które wpływają na pracę. Zapytajcie, czy każda z nich nadal wspiera obecny sposób pracy zespołu, czy raczej przeszkadza.
Miejsce
Co w naszej fizycznej lub wirtualnej przestrzeni pracy wpływa na współpracę lub produktywność?
Weźcie pod uwagę fizyczną i wirtualną przestrzeń pracy, w tym narzędzia, układ biura i to, jak dobrze działa współpraca zdalna.
Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego
- Gdy problem prawdopodobnie ma więcej niż jedną przyczynę
- Po poważnym problemie, który wymaga uporządkowanej analizy, zanim ktokolwiek zaproponuje rozwiązanie
- Gdy zespół ciągle usuwa objawy, a problem wciąż powraca
- Podczas post-mortemów projektów lub przeglądów incydentów, aby ta sama awaria się nie powtórzyła
Proponowane pytania lodołamacze
- Gdyby nasz zespół był maszyną, która jego część wymagałaby teraz najwięcej konserwacji?
- Jakie najbardziej zaskakujące rozwiązanie powracającego problemu udało Ci się kiedyś znaleźć?
Czy chciałby Pan/Pani, aby Państwa zespół wykonał ćwiczenie rozgrzewkowe, a nie tylko odpowiadał na pytania na głos? Przejrzyj bezpłatne lodołamacze →
Pomysły i wskazówki dotyczące spotkania retrospektywnego
- Zanim ktokolwiek doda przyczynę, zapisz jasno sformułowany problem w głowie ryby
- Zadbaj, by każdy dodawał przyczyny do wszystkich kategorii, także tych spoza swojej roli
- Odłóż szukanie rozwiązań, dopóki wszystkie przyczyny nie zostaną rozpisane
- W każdej kategorii stosuj metodę 5 Why (Pięciu Dlaczego), by dotrzeć głębiej niż do pierwszej odpowiedzi
- Zapisuj każdą przyczynę, nawet jeśli na początku wydaje się błaha
- Zarezerwuj 90–120 minut, by porządnie omówić wszystkie sześć kategorii
Najczęściej zadawane pytania
Czym jest 6M w diagramie rybiej ości?
Czym różni się diagram rybiej ości od diagramu Ishikawy?
Jak przeprowadzić analizę przyczyn źródłowych za pomocą diagramu rybiej ości?
Kto wymyślił diagram Ishikawy?
Powiązane szablony
Nazwijcie sukcesy, rodzące się szanse i bolączki zespołu podczas jednej sesji.
Retrospektywa wartości Scrum
Sprawdź, na ile Twój zespół żyje pięcioma wartościami Scrum.
Retrospektywa Wspinaczka Górska
Zaplanujcie drogę z obozu bazowego na szczyt zespołu.
Retrospektywa agile
Cztery pytania, by ocenić ostatni sprint i zaplanować zmiany.