Jak wiadomo, wielu chodzi po ziemi ludzi z obsesjami. Jeden nie zazna spokoju, jeśli podczas daily nie zada trzech drętwych pytań o stan realizacji celu sprintu, drugi kompulsywnie zbiera znaczki pocztowe z epoki PRLu, a jeszcze inny ględzi przy każdej okazji o zasługach Billa Gatesa dla rozpętania pandemii. Ja na przykład od jakiegoś czasu muszę sobie napomknąć dla zachowania zdrowia psychicznego o modelu Cynefin. By nie przynudzać, odsyłam do dwóch tekstów, w których tę tematykę już poruszałem: na przykład tutaj oraz tutaj.
W największym skrócie: dla rozwiązywania problemów złożonych – a więc takich, którym czoła powinien stawiać również scrum – model proponuje sekwencję: probe-sense-response. Czyli zbadaj (ewentualnie wysonduj)-odczuj-zareaguj. Oczywiście istoty takiego podejścia nie wymyślił ani Dave Snowden, twórca koncepcji Cynefin, ani Ken Schwaber z Jeffem Sutherlandem. Na dobrą sprawę wymyślił to Sokrates, kiedy zadumał się, podrapał po brodzie i wymamrotał: wiem, że nic nie wiem.
Może to zabrzmi trochę nazbyt wzniośle, ale od jakiegoś czasu coraz bliższy jestem zdania, że przytomnie zastosowany scrum jest niczym innym jak uznaniem ułomności naszego poznania. Nie jesteśmy omnipotentni, nie jesteśmy w stanie rozwiązywać złożonych problemów pstryknięciem palców, dlatego mierzymy się z nimi po kawałku, choćby i w sprintach.
Piszę o oczywistościach, ale refleksję na ten temat raz jeszcze odpaliła u mnie lektura zaktualizowanego ubiegłej jesieni Scrum Guide’a. Precyzując: lektura ustępów o celu sprintu. Dokument stwierdza, co następuje: (…) cały Scrum Team współpracuje nad sformułowaniem Celu Sprintu, który opisuje to, dlaczego dany Sprint jest wartościowy dla interesariuszy. Cel Sprintu musi zostać określony przed zakończeniem Sprint Planningu.
Różne interpretacje celu sprintu można na mieście usłyszeć. Że to taka latarnia morska, której światło prowadzi zespół scrumowy przez wzburzone wody rozwoju produktu, że to – o zgrozo! – artefakt tożsamy z najistotniejszym zadaniem z zakresu sprintu, że to zszywka, która trzyma w całości backlog sprintu, a tym samym nie pozwala uwadze członków zespołu rozpierzchnąć się w przypadkowych kierunkach.
Muszę jednak przyznać, że mierzyłem się z pewnym paradoksem, który wzmocnił się wraz z wprowadzeniem koncepcji celu produktu, czyli – jak piszą autorzy Scrum Guide’a – jest długoterminowym zamierzeniem Scrum Teamu. Zamierzeniem, które zespół musi zrealizować (…), zanim przystąpi do realizacji kolejnego. Jak to musi? Jak to długoterminowym? A więc jednak jesteśmy omnipotentni i wiemy lepiej? Jednak informacja zwrotna z otoczenia – rynku, nawyków użytkowników oraz ich preferencji, od konkurencji – jest mniej istotna od długoterminowego zamierzenia, które zespół MUSI zrealizować? Przecież takie postawienie sprawy zbliża dynamikę scruma do poszatkowanej na iteracje realizacji projektu, a nie rosnącego na glebie empiryzmu rozwoju produktu, co nie?
Mogłoby być i tak, gdybym w poprzednim przytoczonym cytacie nie pominął z premedytacją podkreślonego fragmentu: Zespół musi zrealizować jeden cel (lub z niego zrezygnować). Cztery słowa, ale – według mnie – o kolosalnym znaczeniu. Bo te cztery słowa są, jak mi się zdaje, stymulantem dla zastosowania empiryzmu. Gdyby założyć, że cel sprintu zasilany jest celem produktu, to jakie konsekwencje może to mieć dla zespołu scrumowego?
Ano takie, że cel sprintu jawi się już nie tylko jako latarnia morska albo zszywka, ale papierek lakmusowy wytwarzanej wartości. Tudzież jako hipoteza co do przewidywanej wartości stawiana najpóźniej w chwili zakończenia planowania sprintu, a weryfikowana najpóźniej wraz z chwilą zamknięcia przeglądu sprintu. Wiadomo – hipotezy mają to do siebie, że bywają nietrafione. Negatywna weryfikacja hipotezy znanej jako cel sprintu może pociągnąć za sobą negatywną weryfikację hipotezy znanej jako cel produktu. I co? I bardzo dobrze! Poprzednia wersja Scrum Guide’a wspominała o przerwaniu sprintu jako wydarzeniu traumatycznym dla zespołu. Nie dość, że brzmiało to potwornie melodramatycznie, to na dodatek podkopywało jeden z atutów zwinności – zwrotność wytwórczą w rozdygotanym, bo zmiennym jak zeznania Daniela Obajtka, środowisku.
Radykalne konsekwencje, które mogą wypływać z pogodzenia się zespołu scrumowego z ograniczonością umiejętności przewidywania przyszłości prowadzą według mnie do wniosku, że przegląd sprintu nie może być jedynym i ostatnim miejscem weryfikacji hipotezy. Stąd oczywiście praktyki takie jak continous integration oraz continous delivery, które dają pretekst i możliwość, by hipotezę weryfikować w sprincie wielokrotnie. Stąd pozyskiwanie zdania użytkownika wielokrotnie przed przeglądem sprintu. Stąd plan sprintu przygotowany w detalach na zaledwie kilka pierwszych dni jego trwania. Stąd rozkwit zwinności tam, gdzie jesteśmy gotowi przyznać: wiem, że nic nie wiem. A przynajmniej: wiem, że nie wiem wszystkiego, i biorę to z godnością na klatę.