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, które zadają uczestnicy szkoleń, jakie 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ść z użyciem 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 to właśnie jest Scrum: iteracyjne i inkrementalne rozwijanie produktów i Zespołów (a 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 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ć to lepiej. A wręcz będą szukać możliwości uwolnienia się od Scruma, omijania jego reguł, zarzucania praktyk itd.

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 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ść.

W naszym kontekście to nie ma sensu…

Kolejny typowy przypadek to ustalenie, że organizacja naprawdę nie potrzebuje podejścia zwinnego, bo nie boryka się z niestabilną złożonością. Nie myjemy okien łopatą (choć pewnie na upartego dałoby się), nie używajmy więc metod zwinnych (w tym Scruma) tam, gdzie nie ma to sensu. 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 mamy silne przekonanie, że właśnie w takiej domenie funkcjonujemy.

Co wtedy? Ciężko być Product Ownerem i pełnić „scrumowe role” tam, gdzie Scrum nie ma sensu. Zapewne sięgniemy po inne metody, więc musimy dokonać transpozycji tego, za co chcemy odpowiadać, na role i/lub odpowiedzialności w tych innych metodach. Przecież nie chodzi o „etykietę”, pod jaką będziemy wykonywać pracę, ale o realny sens i wartość tej naszej pracy, nieprawdaż? No, chyba że jednak chodzi o „etykietę” – ale wtedy pewnie będziemy wyznawcami kultu cargo wspomnianego wcześniej, lub to my (niestety) tłoczyć będziemy na siłę Scruma do organizacji, w której jest on zbędny.

Poziom niewiedzy jest ogromny…

Przyjmijmy, że odkryliśmy, iż „kulawizna” naszego Scruma 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 ze Scrumem (a przynajmniej tak, jak go rozumiemy w danym momencie).
  • Poszerzać swoją wiedzę o Scrumie, innych metodach zwinnych, praktykach i narzędziach (tego nigdy dość) a jak 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 oceniania innych, że „źle robią Scruma”, a zamiast tego pomaganie im w robieniu go choć troszkę lepiej, lub chociaż 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 pierwszego: 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 „meta-poziomie”) 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 my 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ę.

Zdjęcie: Jonathan Borba