Skąd się wzięło to całe Inspect & Adapt w agile’u? Przecież eksperymentowanie to w sumie żmudna i czasochłonna praca. Najpierw robimy jakieś założenia, działamy według nich i potem sprawdzamy czy miały sens. Jeśli miały – super, lecimy dalej z tematem, jeśli nie, wyciągamy wnioski, zmieniamy założenia i próbujemy znowu. Aż do skutku.

Zresztą, gdy pada hasło “eksperyment” od razu w głowie pojawia się Wam obraz osoby w białym kitlu spędzającej całe dnie w jakimś laboratorium oświetlonym świetlówkami, z których jedna niepokojąco buczy i miga.

To kompletnie nie przystaje do świata IT, czy jakiegokolwiek świata, w którym liczy się czas, czas i pieniądz. Dlatego, ja w pracy, przynajmniej na początku, unikam słów takich, jak: eksperyment, inspekcja i adaptacja. Właśnie z tej prostej przyczyny – ciąg skojarzeń, który wywołują kojarzy się z czymś czasochłonnym. W jaki sposób wyjaśnić wobec tego jeden z najważniejszych konceptów zwinności, inspekcję i adaptację?

Ja odwołuje się do pętli OODA.

OODA loop to koncepcja opracowana przez amerykańskiego oficera wojskowego Johna Boyda. Nazwa OODA to akronim od angielskich słów Observe, Orient, Decide, Act, czyli po polsku Obserwuj, Orientuj się, Decyduj, Działaj. Koncepcja ta pierwotnie została opracowana z myślą o działań militarnych. Korzystali z niej piloci myśliwców Stanów Zjednoczonych w walce z Koreą. W powietrzu nie ma czasu na wahanie, akcja-reakcja. Nie można się też trzymać sztywno planu, albo inaczej – plan poddawany jest nieustannej analizie, ocenie i na bieżąco dopasowywany do tego co się dzieje. Tak, samo jest w scrumie, czy każdym innym agileowym frameworku.

OODA loop zakłada, że podczas podejmowania decyzji należy przejść przez cztery etapy. Pierwszym z nich jest (1) obserwacja, czyli zebranie informacji o sytuacji. Następnie trzeba się zorientować, czyli (2) zrozumieć, co te informacje oznaczają i jak wpływają na sytuację. Kolejnym krokiem jest podjęcie (3)decyzji na podstawie zdobytych informacji i zrozumienia sytuacji. Ostatnim etapem jest (4) działanie, czyli wprowadzenie w życie podjętej decyzji.

Brzmi znajomo? 

Te cztery kroki można zastosować na prawie wszystkich płaszczyznach pracy z produktem/projektem czy organizacją/zespołem. 

Przyłóżmy pętle OODA do SCRUMa.

Obserwacja.

Zbieramy potrzeby użytkowników, klientów, stakeholderów. Przeprowadzamy retro, żeby zobaczyć, jak wygląda sytuacja. Wrzucamy je do naszego backloga.

Pytania pomocnicze:

• Jaka jest obecna sytuacja?
• Dlaczego chcesz ją zmienić?
• Jak bardzo potrzebujesz tej zmiany?

Zrozumienie.

Robimy refinement. Sprawdzamy, jaką wartość i komu przynoszą zebrane potrzeby. Analizujemy je, dzielimy na mniejsze części, szacujemy.

Pytania pomocnicze:

• Co jest potrzebne żeby z obecnej sytuacji zrobić stan pożądany?
• Jakie są kryteria sukcesu?
• Jakie są ryzyka i ograniczenia związane z tą zmianą?

Decyzja.

Z wynikiem refinementu idziemy do zespołu i ustalamy, co jest możliwe do zrobienia. Ustalamy cel. Przeprowadzamy planning i tworzymy backlog sprintu.

Pytania pomocnicze:

• Jakie są sposoby na osiągnięcie zmiany?
• Jak poradzimy sobie z blokerami/przeszkodami?

Działanie.

Przystępujemy do pracy, zaczyna się sprint.

Pytania pomocnicze:

• Jaki ją implementujemy?

Kiedy cykl zaczyna się od nowa? 

I tu jest najtrudniejsza część – cykl nie ma wyraźnego początku i końca. Dopóki żyje produkt i projekt, jesteśmy w cyklu a wszystkie te etapy zachodzą równolegle. Gdy trwa I na każdym z jego etapów musimy obserwować, analizować, podejmować decyzje i przekłuwać je na działanie. Zobaczmy to na przykładzie.

Zaczęliście już sprint. W czasie jego trwania dochodzi do refinementu, pojawiają się nowe potrzeby, musicie podejmować decyzje w oparciu o obserwacje i analizę codziennej sytuacji. W SCRUMie jest to odzwierciedlone w wydarzeniu Daily Scrum – małym Scrumie, małym inspect & adapt, małej pętli OODA.

Codziennie zespół patrzy, co ma i myśli czy to przybliża go, czy oddala od celu sprintu. Codziennie PO patrzy na backlog i zastanawia się, czy elementy w nim wspierają wizję produktu czy nie. Codziennie dostajemy informacje od użytkowników czy nasz produkt im się podoba czy jednak nie. Jesteśmy w procesie inspekcji i adaptacji, w procesie Obserwuj-Zrozum-Zdecyduj-Działaj.

Tu nie ma miejsca na przestoje, na komitety, długie łańcuchy decyzji. Jesteśmy cały czas czujni, cały czas sprawdzamy nasze położenie. To trochę jak z nawigacją Google, wybieracie że chciecie dojechać gdzieś, a ona na bieżąco analizuje ruch i sprawdza, która trasa jest najlepsza i proponuje Wam alternatywy. Pozostaje decyzja i akcja, obranie szybszej, ładniejszej czy bardziej ekonomicznej trasy. Up to you. To jest właśnie pętla OODA. Jeśli przyłożycie się do daily scruma, do refinementu, do review i planningu – nic Was nie zaskoczy na tyle, żebyście nie widzieli alternatyw. Pozostanie tylko decyzja.

Tak samo będzie podczas pracy z zespołami i organizacją. Możecie być formalni i działać w SCRUMie, prowadząc backlog ulepszeń/akcji, które chcecie wypróbować. I bardzo polecam Wam tą metodę, bo dzięki strukturze i wizualizacji tego, co robicie łatwiej jest wytrenować w sobie odruch inspekcji i adaptacji. Gdy wejdzie Wam w krew, nawet podczas rozmowy będziecie tworzyli w głowie potencjalne ścieżki rozwoju sytuacji, niczym Sherlock Holmes albo Doctor Strange. Zresztą szybko zauważycie, jak bardzo naturalne jest dla nas takie myślenie. Człowiek, nigdy nie osiągnął by takie poziomu rozwoju gdyby nie nasza niesamowita zdolność do adaptowania się do sytuacji (plus umiejętność współdziałania w tej adaptacji).

Podsumowując, OODA loop to koncepcja, która pomaga w podejmowaniu trafnych decyzji w sytuacjach zmieniających się szybko. Dzięki tej koncepcji można szybciej reagować na zmiany i osiągać sukces w biznesie, nauce, sporcie i wielu innych dziedzinach. Jest to też doskonały sposób na zaznajomienie zespołu, organizacji z koncepcją inspekcji i adaptacji unikając przy tym stereotypowych skojarzeń z eksperymentami. Jeśli działa to dla pilotów myśliwców, którzy mają sekundy na podjęcie decyzji, tym bardziej zadziała dla IT, gdzie ten czas jest odrobinę dłuższy 😉

Niech agile będzie z Wami!

A.