- Czy nadgodziny dowiozą na czas? — 01/10/2020
- Przewodnik po EBM po polsku — 21/07/2020
- Kolejny raport o Agile. I co z tego? — 02/06/2020
Idealny Świat Scrum to jeden z tematów, na które często mówię i dorastają do własnych nazw, artykułów a nawet prezentacji. Określenie idealny nasuwa zaraz skojarzenie z utopijny, czyli nieistniejący. Zapewniam, że jest to jak najbardziej realna rzeczywistość. Idealny świat, to świat w którym Scrum będzie działał idealnie.
Pomimo ponad dwudziestu lat obecności na rynku, Scrum jest nadal widziany lek na całe zło, który może być stosowany w każdej sytuacji. Gdyby efektem tych poglądów były jedynie niepowodzenia w podejmowanych próbach kolejnych organizacji, to jest to ofiara, którą można ponieść. Gdyby przy okazji te organizacje nauczyły się na porażce, że co u nich nie działa i trzeba coś zmienić, to było by bardzo dobrze. Niestety skutki stosowania Scrum do uzdrawiania chorych sytuacji, jakie najczęściej widzimy, to robienie Scrum czarnego PRu. Zaraz słyszymy albo widzimy na blogach postulaty “Gdyby Scrum działał, to …”, “To niemożliwe, żeby Scrum gdzieś zadziałał!” i tym podobne. Przecież łatwiej jest narzekać na młotek zamiast zatrzymać się na chwilę i zauważyć, że młotkiem cieżko się maluje ściany. Czasem na szkoleniach też pojawia się narzekanie “U nas tego nie ma”, “U nas to tak nie działa”, “Dobra, ale rzeczywistość jest inna”. Co to wszystko może oznaczać? Czy chodzi o złe nastawienie czy może o coś innego? Okazuje się, że kiedy dobrze popytamy, dowiemy się, że bardzo często ludzie, którzy próbują zaimplementować Scrum nigdy nie widzieli i nie wyobrażają sobie innej rzeczywistości, niż ta, w której pracują teraz.
Management zawsze był taki sam, terminy były zawsze narzucane, każdy projekt był podobny do siebie.
Scrum powstał w innej, dosyć specyficznej rzeczywistości. I to właśnie buduje kontekst, w którym ten framework będzie bardzo dobrze działać. Różnice pomiędzy tymi okolicznościami a Twoją rzeczywistością mogą być przyczyną niepowodzeń. Przyjrzyjmy się temu co powinno być, czego nie powinno być, żeby Scrum działał w pełni swoich możliwości. Jest to także odpowiedź na pytanie, które często słyszę w swojej pracy “No dobra, to tak koszernie to jak to powinno działać?”.
Pracujemy w firmie, która wytwarza konkretne produkty oferowane jej klientom. Firma działa na rynku, na którym znajduje się także jej konkurencja. Jedynym dobrym sposobem na prowadzenie biznesu jest zaspokajanie potrzeb użytkowników produktu i tworzenie innowacyjnych produktów. Jeśli będziemy z tym zwlekać, nie będziemy wdrażać nowych funkcjonalności szybko, to konkurencja nas wyprzedzi. Musimy mieć krótki czas od pomysłu do wdrożenia, czyli tak zwany time to market. Chcemy szybko dowiadywać się co sądzą o naszych pomysłach i nowych produktach klienci. Jeżeli coś nie przynosi zakładanych zysków, zwanych Return On Investment, to nie będziemy tego dalej rozwijali.
Za rozwój każdego produktu jest odpowiedzialna jedna, konkretna osoba, która zna klientów i sytuację na rynku. Jedna osoba trzyma budżet, zbiera informacje od klientów i podejmuje decyzje. Konkurencja nie śpi, więc potrzebujemy szybko podejmowanych decyzji i jasnej Wizji Produktu. Po co komplikować to zajęcie komitetami i przeciągającymi się spotkaniami? W Scrum taka osoba nazywa się Właściciel Produktu. Właściciel Produktu posiada wiedzę na temat produktu, rynku, biznesu, użytkowników, klientów itd. oraz ma władzę potrzebną do podejmowania autonomicznych decyzji. Oczywiście będą różni interesariusze, którzy chcą zaspokoić swoje interesy i mogą go rozliczać za konsekwencje decyzji. Zwykle Product Owner jest dostępny na zawołanie, bo siedzi z Zespołem Developerskim w tym samym pokoju.
Ktoś musi budować ten produkt, zatem mamy wewnętrzny zespół budujący rozwiązanie. Taki Zespół Developerski pracuje dla swojej organizacji i dba, żeby dostarczane rozwiązanie byly jeak najlepsze i kombinuje jak najlepiej zaspokoić potrzeby biznesu. Product Owner i Zespół Developerski starają się jak najlepiej wykonywać swoją pracę. Współpracują ściśle i są bardzo zaangażowani w Produkt. Można powiedzieć, że traktują Produkt jak własne dziecko. Mamy zespół prawdziwych profesjonalistów, którzy przeszli do fazy performowania w swoim rozwoju i ciagle uczą się nowych umiejętności. Developerzy chętnie dzielą się wiedzą w zespole i poza zespołem rozwijając wzajemnie swoje kompetencje. Nie martwimy się o wskroś-funkcjonalne zespoły, bo mamy coraz więcej wskorś-funkcjonalnych Developerów. Zespół wie jak radzić sobie z konfliktami. Każdy członek zespołu jest naprawdę dumny z bycia jego częścią. Zespół ma swoją przestrzeń, w której tworzą środowisko dla produktywności i zaznaczają swoją tożsamość. Ciągły hałas z open-space nie dochodzi tam, w związku z czym mogą pracować bez słuchawek i wymieniać się informacjami. Czasem komunikacja zachodzi w sposób osmotyczny, bo gdy w ucho wpada interesujący temat, to ktoś przyłącza się do rozmowy. Pokój zespołu jest obklejony wizualizacjami pomysłów, postępu Sprintu i planów na przyszłość. Zespół wspólnie świętuje sukcesy i przeprowadza trudne rozmowy o porażkach.
Produkt będzie tak długo rozwijany, jak długo Product Owner bedzie znajdował na Backlogu wartościowe rzeczy do zrobienia. Kiedy takich rzeczy zabraknie, Zespół będzie przesunięty do innej pracy. Nie ma mowy o “dowożeniu projektów na czas”. Czas to po prostu stały rytm Sprintów. Właściciel Produktu decyduje kiedy kolejny Przyrost Produktu wydać na produkcję biorąc pod uwagę sens biznesowy. Może to być co Sprint i wtedy wszystkie ukończony elementy Rejestru Produktu trafiają na produkcję, ale równie dobrze można czekać, aż pojawi się odpowiednia wartość biznesowa. Właściciel Produktu ufa Zespołowi Developerskiemu i negocjuje z nim jak z równym partnerem. W wyniku tych rozmów nauczył się rozmawiać o technologii. Zespół rozumie, Właścicielowi Produktu zależy na jak największej wartości ich pracy i stara się zrozumieć biznes. Ważne daty i duże oczekiwania klientów zawsze są osiągane poprzez wspólną pracą obu stron.
Scrum Master to funkcja poważana w organizacji, ponieważ każdy wie, że pomaga osiągać cele i budować wartość. Zespoły dzięki jego pracy rozwijają się i są zmotywowane. To samo dotyczy z resztą poszczególnych developerów. Nikt nie myśli o odejściu z firmy nawet za dodatkowy tysiąc, bo stworzone środowisko jest czymś wyjątkowym.
Ile z tego opisu zgadza się z Twoją rzeczywistością?