Wspomniany Product Owner jest przekonany, że sposób korzystania ze Scruma w jego organizacji niewiele wspólnego ma z tym, jak zdefiniowana jest ta metoda. Przy czym nie chodzi mu o sposób na „zrobienie Scruma zgodnie z definicją”, ale o podpowiedź, jak uzyskać korzyści, jakie może ta metoda dać, jeśli używa się jej poprawnie. Z punktu widzenia Product Ownera to pytanie dałoby się sformułować więc również w sposób następujący: „jak uzyskać wartość z użyciem Scruma, jeżeli organizacja ma problemy z działaniem zwinnym?”.

Na początek trzeba zastanowić się, czym jest wspomniany „kulawy Scrum”. Jest wybrakowany lub niekompletny? Jeśli tak, czego w nim brak i jakie są tego skutki? A może reguły obowiązujące w organizacji uniemożliwiają poprawne użycie Scruma? Jeśli tak, co jest niemożliwe i jak wpływa to na efektywność działania zespołów scrumowych?

Pierwszy scenariusz jest taki: dziś faktycznie nie da się użyć Scruma poprawnie, bo organizacja przez lata ułożyła się pod zupełnie inny sposób działania, niemożliwy do zmiany z dnia na dzień. A ponieważ nie możemy lub nie chcemy robić rewolucji (której organizacja mogłaby nie przetrwać), potrzebujemy czasu. Inaczej mówiąc: wiemy, co robimy nieefektywnie i szukamy sposobu, by to zmienić – co być może wymaga gruntownej przebudowy kultury całej organizacji.

Jeśli ten proces (dążenia do zmiany i jej wprowadzania) nie jest pozorny, i jeśli faktycznie dążymy świadomie do tego, by działać lepiej (i liczymy na to, że im bliżej „poprawnego Scruma” się znajdziemy, tym większe odniesiemy korzyści), to wcale nie jest „kulawy Scrum”. Jest marny, może bardzo marny, ale to właśnie jest Scrum: iteracyjne i inkrementalne rozwijanie produktów i zespołów (szerzej: organizacji), by lepiej przekuwać możliwości ludzi i zasoby firmy na coś, co daje wymierne korzyści.

To, że uwiera nas robienie czegoś „niezgodnie z definicją”, to dobrze – powinno uwierać, bo wtedy dążyć będziemy do zmiany status quo. Natomiast to nie jest powód, by samobiczować się stwierdzeniami o „kulawym Scrumie”.

Zróbmy listę tych rzeczy, które wymagają zmian i usprawnień najpilniej, a następnie zajmijmy się nimi po kolei – poczynając od tego, co najważniejsze, albo co da najlepsze efekty, eksperymentując, dzieląc duże problemy na małe kawałki tak, by łatwiej było sobie z nimi radzić… Brzmi znajomo? Tak, dokładnie tak buduje się produkty z użyciem Scruma. Nie ma powodu, by tego samego podejścia nie użyć do budowania zwinnej organizacji.

Po co nam ten Scrum…

Możemy niestety odkryć coś mniej budującego: ktoś nakazał użycie Scruma, ale nikt nie ma rzeczywistych intencji z niego korzystać ani wysilać się, by zrobić to dobrze. Zanim przejdę dalej, krótka dygresja: ten scenariusz nie jest tożsamy z sytuacją, w której jakaś firma podjęła decyzję o użyciu Scruma na zasadzie kultu cargo – z nadzieją, że mechanistyczne „wdrożenie” procesu z automatu przyniesie korzyści. Taki scrumowy kult cargo zazwyczaj wygląda z zewnątrz bardzo poprawnie i trzeba zdrapać kilka warstw z fasady, by zobaczyć, że to wszystko pozory (brak empiryzmu, brak przejrzystości itd.). Tym samym scrumowy kult cargo rzadko bywa oskarżany o bycie „kulawym Scrumem”. Za to dużo częściej bywa „dowodem na to, że Scrum nie działa”.

Jeśli nie uda się wykrzesać chęci użycia Scruma, niewiele z tym można zrobić. Sytuacja nie jest beznadziejna, ale prawie zawsze problem trzeba rozwiązywać poza zespołem Scrum. Żadne szamańskie tańce dookoła Developerów, pohukiwanie na nich i szkolenia nie zmienią faktu, że ludzie nie chcą robić czegoś, czego się od nich oczekuje. Nie chcą, bo być może nie ma to sensu (wtedy poszukajmy innej metody), albo też nie rozumieją powodów, dla których Scrum w ich kontekście jednak sens ma (wtedy dajmy im ten powód).

Co zatem robić?

Co zrobić, będąc Product Ownerem w takiej sytuacji? Zadbać o dobrą definicję swojego produktu – tak, żeby wiedzieć, po co jest robiony, jaki sens jest w jego efektywnym budowaniu, jakie korzyści to daje, jakie są koszty i skutki braku tej efektywności. Kto wie, może uda się uzyskać źródło zaangażowania dla ludzi i przesuniemy się do tego pierwszego scenariusza. Wciąż będzie trudno, bo zderzymy się z różnymi ograniczeniami organizacji, ale przynajmniej będziemy realnie dążyć do zniesienia tych ograniczeń.

Ale może też się okazać, że nasz produkt… nie ma w ogóle sensu. Albo że nikt w organizacji nie ma realnych intencji czegokolwiek zmieniać, a samo wprowadzenie metod zwinnych jest tylko grą pozorów – bo „wypada być Agile”. Wtedy sytuacja może być beznadziejna, o ile nie uda nam się przebić „w górę” i uzyskać choćby minimalnego wpływu na sposób działania organizacji. Czasami jedynym sposobem, by zacząć robić coś sensownego, jest przejście do innej firmy. Bo, wbrew tym, którzy oferują „przeprowadzenie transformacji zwinnych w każdej organizacji”, nie wszędzie da się uzyskać choćby podstawową zwinność.