Gdy rozmawiam z osobami szykującymi transformację zwinną albo jej jakiś kolejny etap, często natrafiam na pytanie „jak wybraliście Product Ownerów”, „jak wybraliście Scrum Masterów” i „jak podzieliliście zespoły”. Chętnie wskakuję w przytaczanie różnych przypadków z doświadczenia i często mam doszczegółowienie pytania – „ale jak dobrze to zrobiliście?”. W domyśle widzę tu pytanie (i po zgłębieniu jest to faktycznie właśnie to) o to, jak uniknąć niepowodzenia, jak się zabezpieczyć przed złymi decyzjami i mieć gwarancję dobrego wyboru czy podziału. Szokuję swoich rozmówców hasłami w styl „nie da się, nie można tego zrobić bezbłędnie”. Uważam na bazie doświadczenia, że takie rzeczy jak wybór początkujących osób na jakieś zupełnie nowe stanowisko w firmie, czy podział wszystkich zespołów według nowego schematu w dużej organizacji ma gwarancję błędów. Będą zmiany w roli PO, SMa i będą korekty sposobu podziału. Niepokojące dla mnie byłoby to, gdyby się okazało, że po kilku kwartałach pracy żadne z tych zjawisk nie nastąpiło – albo mamy do czynienia z nieprawdopodobnym fartem, albo nie następuje usprawnianie pracy na bazie cyklicznych retrospektyw i przeglądów sprintów.
Organizacja na bazie takich błędów uczy się. W przyszłości będzie umiała lepiej ewoluować strukturę, podnosić poziom odpowiedzialności Product Ownerów i lepiej rozumieć czego oczekuje od Scrum Masterów. Osoby, które zostały w takich procesach zmian „błędnie” wytypowane, z moich obserwacji często nie żałują przygody – zwłaszcza wiele osób, które spróbowały roli SMa, ale nie zostały w niej na stałe, zyskały w tym procesie nowych narzędzi i przemyśleń.
W mojej ocenie „błędy” w organizacji w pierwszych etapach transformacji to często tak naprawdę najlepszy (najbardziej ryzykowny) eksperyment, na jaki była gotowa firma w danym momencie. Pokazanie, że nie do końca się udało to, co było planowane, że potrzebne są korekty albo dalsze zmiany, to nowa wiedza, walidacja poprzednich założeń i odkrywanie przez organizację potrzeby dalszych eksperymentów. Najgłupsze, co można by wtedy zrobić, to wyjść z założenia „nie udało nam się w 100% = agile nie działa”. Czasem rozśmiesza mnie też fałszywa logika typu „nie udało nam się w 100% = musimy agile usprawnić (elementami waterfalla)”. Za rzadko w case studies wykorzystania agile czy materiałach szkoleniowych widzę takie zastrzeżenia, jakie chciałem przekazać w tym wpisie – agile to będą błędne decyzje, ciągłe eksperymenty i wyciąganie wniosków z kolejnych kroków, nie zawsze idealnych. I nie, żaden konsultant ani żadne kopiowanie najlepszych wzorców wypracowanych w innych firmach nas przed tym nie uchroni.