Po dłuższej przerwie wracam z nowym tekstem. Tak, wiem, że obiecałem opisać typowe błędy związane z pielęgnacją Backlogu Produktu i wrócę do tego tematu już wkrótce. W międzyczasie postanowiłem, że zacznę dzielić się odpowiedziami na pytania, jakie zadają uczestnicy szkoleń, które prowadzę.  Ponieważ takich pytań i odpowiedzi mam zachomikowanych naprawdę dużo, powstanie z tego cykl artykułów.

Pytanie na dziś:

Jak pełnić rolę scrumową w firmie, która ma „kulawego Scruma”?

Autorem jest Product Owner 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ło w tym pytaniu 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ż następująco: „jak uzyskać wartość dzięki użyciu Scruma, jeśli 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 Scrum?

Poszukując odpowiedzi na takie pytanie, warto pamiętać, że celem nie powinno być „używanie Scruma” ani „poprawny Scrum”, ale uzyskanie za pomocą Scruma korzyści – spowodowanie, by metoda dała nam więcej, niż kosztuje jej zastosowanie. Trzeba też mieć świadomość, że Scrum nie jest jedyną metodą zwinną (więc niekoniecznie każda firma musi akurat z niej korzystać) i Agile nie jest jedynie słusznym podejściem do osiągania celów organizacji.

Wróćmy do „kulawego Scruma” i przyjmijmy, że ustaliliśmy już, skąd bierze się owa kulawizna i jaki ma charakter (a przynajmniej mamy mocne podejrzenia i potrafimy wskazać konkretne problemy i ich skutki). Działania, jakie możemy podjąć, by efektywniej używać empiryzmu (przypominam, że jest on podstawą wszystkich metod zwinnych), zależy od tego, co odkryliśmy.

Teraz jest źle, ale…

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 będziemy z tego mieć korzyści), to wcale nie jest „kulawy Scrum”. Jest marny, być może bardzo marny, ale tym właśnie jest Scrum: iteracyjnym i inkrementalnym rozwijaniem produktów i Zespołów (a szerzej: organizacji), by coraz 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ą Scruma, jest zrozumiałe – powinno uwierać, bo wtedy dążyć będziemy do zmiany status quo. Natomiast nie ma powodu do samobiczowania się stwierdzeniami o „kulawym Scrumie”.

Zróbmy listę rzeczy, które wymagają zmian i usprawnień najpilniej i 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”.

Wracając do Scruma użytego pod przymusem – nie da się w takim środowisku użyć go skutecznie. Jeśli ludzie uczestniczący w procesie (nie tylko Zespół Scrum, ale też jego otoczenie) nie mają intencji użycia Scruma jako narzędzia do efektywnego działania, to na pewno nie będą poszukiwać sposobu, jak robić cokolwiek lepiej. A wręcz będą szukać możliwości uwolnienia się od Scruma, omijania jego reguł, porzucania niezbędnych praktyk itd.

Jeśli nie uda się wykrzesać w ludziach 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 zrobić, będąc Product Ownerem w takiej sytuacji? Zadbać o dobrą definicję swojego produktu – tak, żeby wszyscy wiedzieli, 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. Jeśli pojawi się w ludziach chęć, by wartościowy produkt zbudować, dużo łatwiej będzie przekonać ich, że Scrum może im w tym pomóc. Gdy zaczną z niego korzystać, pojawi się zapewne problem, o którym pisałem wcześniej – dążenie do zwinnego działania zderzy się z różnymi istniejącymi ograniczeniami, które trzeba po kolei wyeliminować. Nie jest to jednak nic, z czym zaangażowany Zespół nie zdoła sobie poradzić.

Niestety może też się okazać, że produkt nie ma w ogóle sensu. W tej sytuacji prawdziwy Product Owner powinien doprowadzić do zaprzestania przez organizację inwestowania w coś, co jest zbędne. Możliwości Zespołu i środki, którymi dysponuje, powinny być użyte na potrzeby innego produktu lub inicjatywy biznesowej.

Czasami Product Owner zorientuje się, że nikt w organizacji nie ma realnych intencji dążenia do skuteczności i efektywności w działaniu, a wprowadzenie metod zwinnych jest grą pozorów – bo „wypada być Agile”. Wtedy sytuacja może być beznadziejna, o ile nie uda mu się 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 Agile w każdej organizacji, nie wszędzie da się uzyskać choćby podstawową zwinność.

W naszym kontekście to nie ma sensu…

Kolejny typowy przypadek to użycie Scruma w domenie pozbawionej niestabilnej złożoności, w której skutecznie da się planować działania długoterminowe, a prognozy okazują się niemal zawsze trafne. Pozostaje otwartym pytaniem, czy w dzisiejszych czasach są jeszcze domeny dostatecznie stabilne, by nie było potrzeby korzystania z empirycznej kontroli procesu – ale to temat na zupełnie inny artykuł. Przyjmijmy, że Product Owner ma silne przekonanie, że problemy, z jakimi zmaga się jego Zespół, są proste albo co najwyżej skomplikowane. Co wtedy?

Użycie Scruma w tej sytuacji wciąż może przynosić korzyści, bo Zespół będzie regularnie poszukiwał sposobu na wprowadzenie usprawnień w procesie, praktykach, stosowanych narzędziach itd. Niemniej Product Owner nie powinien upierać się przy stosowaniu Scruma tylko dlatego, że chce zachować etykietkę, pod którą będzie wykonywał swoją pracę. Zamiast tego, powinien wraz z Zespołem poszukać takiej metody, która dla wszystkich będzie akceptowalna, a jednocześnie pozwoli na skuteczny rozwój produktu.

Taka elastyczność postawy Product Ownera ma i tę zaletę, że pozostawia otwartą ścieżkę powrotu do Scruma w przyszłości. I to takiego prawdziwego, na którym ludziom autentycznie zależy, a nie pseudo-Scruma, który jest efektem narzucenia Zespołowi metody siłą.

Poziom niewiedzy jest ogromny…

Przyjmijmy, że Produkt Owner odkrył, iż kulawizna Scruma w jego Zespole wynika z niewiedzy lub braku doświadczenia. Najlepsze, co można zrobić, to połączyć w spójną całość trzy działania:

  • Postępować najlepiej, jak potrafimy jako Product Owner (albo Scrum Master lub Developer), zgodnie z zasadami Scruma (a przynajmniej tak, jak je rozumiemy w danym momencie).
  • Poszerzać swoją wiedzę o Scrumie, innych metodach zwinnych, praktykach i narzędziach (tego nigdy dość), a jeśli trzeba, uczyć tych rzeczy innych (Scrum Master wręcz ma obowiązek to robić).
  • Poszukiwać możliwości zmienienia stanu spraw, w szczególności poprzez unikanie mówienia ludziom, że źle używają Scruma, a zamiast tego pomaganie im w użyciu go choć troszkę lepiej. Lub chociaż poprzez danie im przykładu, jak można działać lepiej (w swoim Zespole) i dlaczego się to opłaca.

W swej istocie ten scenariusz jest bardzo podobny do opisywanego na początku: na razie nie potrafimy lepiej działać w Scrumie, ale dążymy, by to zmienić. Różnica polega na tym, czy musimy aktywnie usuwać coś, co blokuje możliwości, czy raczej jest to pasywne ograniczenie wynikające z braku umiejętności, które dopiero nabywamy. O ile w pierwszym scenariuszu być może trzeba walczyć ze status quo, które będzie się mocno bronić, o tyle w tym przypadku borykać się będziemy głównie z własnymi ograniczeniami.

Czy istnieją inne scenariusze?

Niewątpliwie tak. Opisałem kilka typowych i podpowiadam (na tak zwanym metapoziomie), jak sobie z nimi radzić. W praktyce nigdzie nie ma „instrukcji wdrożenia” do Scruma, nie ma też czegoś takiego jak „idealny Scrum”. Powód: to metoda ramowa (ang. framework), więc zawiera tylko minimalny zbiór zasad i praktyk, które zawsze musimy czymś uzupełnić, i w które jakoś musimy się wpisać. Im lepiej to zrobimy, tym więcej potencjalnych korzyści z tego będziemy mieli. Ot, cała magia Scruma.

Pamiętajmy też, że nie da się za dużo zmienić na raz, ani nie da się za wiele zmienić w krótkim czasie. Jest to jednocześnie o wiele trudniejsze, jeśli brak silnej woli zmian u tych, których zmiany te dotyczą. Inaczej mówiąc, należy być cierpliwym (ale nie masochistą) i stawiać sobie realne cele do osiągnięcia, czyli oczekiwać niewielkich, ale trwałych zmian. Póki cokolwiek się zmienia i tempo nie powoduje, że stracimy motywację do dalszego działania, jest światełko w tunelu.

Ważne też, by unikać zgniłych kompromisów (choć czasami są one nieuniknione) i trzymać się zasad, które chcielibyśmy, aby obowiązywały w organizacji. Dzięki temu w końcu stanie się widoczne, że warto dążyć do poprawy sposobu pracy (bo pojawią się korzyści), albo… cóż, będziemy wiedzieć, że to nie miejsce dla nas.

Masz pytania?

Będę publikował kolejne artykuły oparte o dyskusje, jakie odbywają się na szkoleniach, które prowadzę. Jeśli chcesz zadać własne pytania – po prostu zapisz się na jedno z tych szkoleń. Będzie okazja porozmawiać albo w czasie zajęć, albo w ramach specjalnej sesji Q&A, którą robię na koniec każdego dnia. W końcu szkolenia są też i po to, by uzyskiwać odpowiedzi na pytania, a nie jedynie samą wiedzę.