Od czego zacząć wprowadzenie Scruma w organizacji

Zacząć od Backlogu Produktu? Od stworzenia Zespołu? Czy od wyboru Product Ownera? Jaki powinien być pierwszy krok?

Sporo zależy od tego, jakie metody już są używane, bo czasami wystarczy jedynie nałożyć zasady frameworku Scrum na istniejące procesy. Najczęściej jednak okazuje się, że aby dobrze (czyli z dużymi korzyściami dla interesariuszy) użyć Scruma, sporo musi się zmienić.

Krok zerowy: czy Scrum to dobry wybór?

Zanim zabierzemy się do wprowadzana Scruma do jakiegokolwiek Zespołu lub organizacji, musimy zastanowić się, czy Scrum ma tam sens i da się go w ogóle zastosować w tym konkretnym miejscu. Jeśli nie wiemy, czy tak jest, pozostaje nam spróbować. Choćby dlatego, że jeśli brak oczywistych powodów do uznania Scruma za nieadekwatną metodę, prawdopodobnie oznacza to, że sięgnięcie po nią przyniesie korzyści, a nawet jeśli będą ograniczone, to wciąż może się opłacać.

Kiedy sięganie po Scruma nie ma sensu, a kiedy da się go użyć? Napisałem kiedyś artykuł na ten temat, zachęcam do zapoznania się z nim.

Gdy uznamy, że warto po Scruma sięgnąć, możemy kontynuować.

Krok pierwszy: definicja produktu

Scrum jest metodą produktową, czyli sposobem na wytworzenie i długotrwałe rozwijanie jakiegoś wartościowego rozwiązania, którego istnienie i użycie przynosi interesariuszom wymierne korzyści, np. rozwiązując jakiś problem, dając nieistniejące bez tego produktu możliwości, ułatwiając działanie itd.

Przy czym należy produkt rozważać tutaj maksymalnie szeroko, niekoniecznie musi to być fizyczny wytwór jakiegoś procesu. Równie dobrze mogą to być rozwiązania wirtualne, takie jak np. oprogramowanie, ale też całe procesy biznesowe, receptury nowych leków, kampanie marketingowe – w zasadzie cokolwiek, co powstaje w wyniku kreatywnej pracy grupy ludzi (w Scrumie: Zespołu lub Zespołów) na potrzeby innych ludzi (w Scrumie: interesariuszy, w tym użytkowników produktu).

Dlatego podstawą jest określenie tego, co właściwie jest produktem, jaki za pomocą Scruma będzie wytwarzany lub rozwijany (jeśli już istnieje). Bez tego w praktyce nie da się zacząć, bo ani nie będzie wiadomo, kto powinien być Product Ownerem (Product Ownerem czego?), ani wyznaczyć sensownego celu do osiągnięcia. A to znów uniemożliwi stworzenie Backlogu Produktu.

Oczywiście nie trzeba od razu zrobić wszystkiego dobrze, bo produkt może okazać się źle zdefiniowany, podobnie jak wybór Product Ownera nietrafiony. Czasami wypracowanie naprawdę dobrej wizji produktu nie jest łatwe, bo sam fakt, że coś komuś jest potrzebne, niekoniecznie oznacza, że ujęcie tej potrzeby w słowa tak, by przekazać wizję innym osobom, jest trywialne.

Krok drugi: Product Owner

Scrum wymaga ustalenia, kto będzie Product Ownerem. Nie jest to jedynie formalizm, ale konieczność wynikająca wyłącznie z pragmatyzmu metody. Ktoś musi potrafić wytłumaczyć, czym jest produkt, określić jego wizję i zidentyfikować interesariuszy.

Czasami wybór Product Ownera jest trywialny, bo osoba ta ujawnia się wraz z powstaniem potrzeby, na jaką odpowiada sam produkt. Można wtedy powiedzieć, że Product Owner jest tym człowiekiem, który pierwszy określił, że jakieś rozwiązanie jest oczekiwane i znalazł sensowną odpowiedź na to, jak go wytworzyć. Bywa, że taki Product Owner jest na początek głównym lub wręcz jedynym interesariuszem, ale nie ma tu reguły.

W wielu organizacjach ustalenie, kto będzie Product Ownerem, stwarza jednak problem. Niewątpliwie jest to odpowiedzialność, która wymaga zarówno władzy (na pewno nad produktem, niekoniecznie nad ludźmi), umiejętności dyplomatycznych (bo godzenie potrzeb różnych interesariuszy produktu wymaga mówienia „nie” częściej, niż „tak, zrobimy to”), jak i gotowości do podejmowania decyzji (a więc i do bycia za nie rozliczonym). Stąd i korporacyjne przepychanki pomiędzy tymi, co pchają się, by czymś rządzić, a tymi, którzy starają się jak ognia unikać odpowiedzialności.

W skrajnych przypadkach nie pozostanie nic innego niż pogodzić się na początek z istnieniem jakiegoś komitetu osób zarządzających produktem, który wydelegował na front pacynkę w postaci formalnego, ale kompletnie pozbawionego decyzyjności Product Ownera. Choć czasami nawet i tego braknie, a Product Ownerów będzie kilku.

Nie blokuje to możliwości posłużenia się Scrumem, ale zdecydowanie brak jednego Product Ownera z prawdziwego zdarzenia jest jedną z rzeczy, które trzeba będzie szybko zmienić. Jeśli komitet produktowy lub inne patologie, z jakimi zetknąć można się w dużych firmach, pozostanie na długo lub na stałe, przejrzystość Backlogu Produktu na pewno będzie nieustannie spadać, a procesy decyzyjne będą w najlepszym razie powolne, o ile nie chaotyczne.

Krok trzeci: wizja produktu

Wizja produktu to kolejna kwestia, a jaką należy zadbać. I nie chodzi o sformułowanie jakiegoś marketingowego lub biznesowego hasła, które pustosłowiem ma zasypać dziurę ziejącą w miejscu odpowiedzi na pytanie „po co i dla kogo powstaje produkt?”. Bo w istocie wizja produktu musi być taką odpowiedzią.

Jeśli Product Owner nie potrafi choćby w ułomny, ale sensowny sposób wyjaśnić, dlaczego sam produkt, jak i jego budowanie ma sens, to niewykluczone, że tego sensu brak.

Jakaś wizja musi więc istnieć, przede wszystkim dlatego, że bez niej trudno zidentyfikować interesariuszy. A trzeba pamiętać, że Zespół pozbawiony styczności z interesariuszami nie jest w stanie działać empirycznie, bo nie może potwierdzić, czy hipotezy produktowe, jakie stawia, są trafne. Tym bardziej nie da się działać empirycznie, jeśli nie wiadomo, kim są interesariusze produktu i czy istnieją.

Poza tym, jak obronić tezę, że produkt ma wartość, skoro nikomu nie zależy na nim na tyle, by dało się tego kogoś zidentyfikować jako interesariusza?

Krok czwarty: pierwszy Cel Produktu

Mając wizję produktu i dostęp do interesariuszy, Product Owner może na podstawie wiedzy o potrzebach tychże interesariuszy wytyczyć Cel Produktu. Będzie to odpowiedź o to, do jakiego przyszłego stanu produktu Zespół Scrum podąży na początek (ewentualnie Zespoły, jeśli nad produktem będzie pracować dużo osób).

Tu uwaga: pisząc o przyszłym stanie produktu jako definicji Celu Produktu, nie mam na myśli próby opisania konkretnego rozwiązania, które ma w przyszłości powstać. Stan należy rozumieć bardziej jako zbiór określonych cech, dających produktowi jakość funkcjonalną (wartość użytkową). Inaczej mówiąc, Cel Produktu wyjaśnia nie tyle, co ma powstać, ile co taki produkt umożliwi.

Bez ustalenia Celu Produktu nie da się stworzyć Backlogu Produktu. Tak, da się spisać listę wymagań czy potrzeb interesariuszy w dowolnej formie, ale taki artefakt nie będzie miał z prawdziwym Backlogiem Produktu wiele wspólnego. Backlog ma być przecież dynamicznie dostosowywanym, minimalnym i zarazem wystarczającym (na teraz) planem rozwoju produktu, który pozwoli osiągnąć konkretny cel – Cel Produktu właśnie. Bez Celu lista stanie się po prostu planem prac i niczym więcej.

Dlatego Cel Produktu jest potrzebny, aby Zespół Scrum nie miotał się od lewa do prawa, zależnie od tego, czego akurat będą domagać się interesariusze. I aby lista rzeczy do zrobienia nie zamieniła się z minimalistycznego łatwego do ogarnięcia planu w ogromny zsyp na rzeczy, których w większości nigdy nie uda się zrealizować.

Krok piąty: Backlog Produktu

Sam Backlog Produktu, a przynajmniej jego zaczyn, nie musi być na początku duży. I, prawdę mówiąc, nigdy nie powinien taki się stać. Idea kompletnego Backlogu Produktu jest nieporozumieniem, o czym pisałem przed laty w artykule, który pozostał wciąż aktualny.

Plan rozwoju produktu i osiągnięcia aktualnego Celu Produktu będzie ciągle zmienny, bo musi być, skoro rzeczywistość nie jest statyczna. Im elementów na liście więcej, tym ciężej zadbać o utrzymanie ich przejrzystości i zapewnić, że będą na czas aktualizowane. Nie warto też wybiegać zbyt daleko w przód, bo w zmiennym i nieprzewidywalnym środowisku nadmierna pielęgnacja elementów, które realizowane mogą być (choć nie muszą) dopiero za jakiś czas jedynie skonsumuje czas, a i tak będzie trzeba ją potem powtarzać.

Backlog Produktu jest potrzebny do tego, by z grubsza zrozumieć, jaki charakter będą mieć działania w pierwszych Sprintach i w związku z tym jakiego Zespołu lub Zespołów potrzeba. Przy czym konieczne jest też ustalenie choćby wstępnie jakiejś Definicji Ukończenia, bo ta będzie wskazówką, jakich kompetencji należy oczekiwać od Developerów i ilu ich powinno być.

Krok szósty: prototypowa Definicja Ukończenia

Definicja Ukończenia to deklaracja intencji Zespołu Scrum odnośnie do tego, jaki minimalny poziom jakości strukturalnej produktu Zespół ten chce zapewnić interesariuszom. Jakość strukturalna związana jest z tym, w jaki sposób produkt będzie wytwarzany – o tym, jaki produkt powstanie, rozstrzyga Backlog Produktu, a dokładniej Produkt Owner zarządzając tym artefaktem.

Zanim jednak powstanie Zespół, jakaś forma Definicji Ukończenia musi zostać określona. Będzie to jedynie prototyp tej Definicji, którą stworzy Zespół Scrum (lub Zespoły wspólnie, jeśli będzie ich kilka). Ta prototypowa Definicja pozwoli zrozumieć (jak już pisałem powyżej), jakich kompetencji oczekiwać należy od Developerów i ilu ich powinno być, żeby w akceptowalnym tempie zacząć budować produkt.

Krok siódmy: formowanie Zespołu Scrum

Dopiero na tym etapie jest sens powołać do życia Zespół, najlepiej na początek jeden, a potem dołożyć kolejne, stopniowo, aby skala organizacyjna przedsięwzięcia nie przekroczyła możliwości kognitywnych ludzi, którzy w nim uczestniczą. Rzucenie się ogromną rzeszą ludzi do rozwoju jednego produktu daje promesę szybkich postępów prac, w praktyce jest najczęściej źródłem chaosu i powoduje, że od zarania produkt obciążony jest trudnymi do usunięcia deficytami, a tempo jego budowania wcale nie jest tak duże.

Stopniowe rozbudowanie możliwości developerskich można przeprowadzić na wiele sposobów, choćby poprzez powolne powiększanie jednego Zespołu do czasu, aż stanie się on za duży i samodzielnie dokona podziału na dwa mniejsze. Dodawanie po jednym nowym Zespole też w wielu miejscach się sprawdzi, byleby każdemu dać taką samą szansę na zgranie się i wdrożenie jak pierwszemu.

Natomiast zdecydowanie odradzam wprowadzanie w życie scenariusza, w którym zaczynamy z jednym Zespołem, a potem dzielimy go na siłę na kawałki, dodając nowych Developerów. W ten sposób będzie kilka Zespołów zamiast jednego, ale żaden z nich (jako całość) nie będzie miał realnego doświadczenia z produktem, wszystkie natomiast będą musiały się na nowo formować i uczyć pracy w takim składzie osobowym. Lepiej już pozostawić ten pierwszy Zespół, a tworzyć kolejne, korzystające punktowo ze wsparcia tego mającego już doświadczenie.

Krok ósmy: ustalenie Definicji Ukończenia

Gdy Zespół lub Zespoły Scrum w końcu powstały, to moment, by określić Definicję Ukończenia, jaką będą się posługiwać. Podstawą będzie tu niewątpliwie prototyp Definicji, o jakim była mowa wcześniej – stworzony przez organizację, jaka powołała Zespół (Zespoły) do życia.

O tym, jak stworzyć sensowną Definicję Ukończenia i rozwijać ją z czasem, pisałem w serii artykułów, z których pierwszy można znaleźć tutaj. Tu wspomnę tylko, że sensowna Definicja bierze pod uwagę realne możliwości Developerów i to, jaki produkt nadaje się do użycia, oraz obowiązujące standardy (techniczne, prawne, organizacyjne), w jakie musi się ten produkt wpisać.

Jeśli prototypowa Definicja Ukończenia była bodaj odrobinę przemyślana, nie ma dużego ryzyka, że zbudowane w jej kontekście Zespoły Scrum będą z początku niezdolne do budowania wartościowego produktu. Gdyby tak się stało, trzeba szybko podnieść kompetencje Developerów (albo zmienić strukturę Zespołów tak, by te kompetencje zapewnić). Długotrwałe budowanie produktu wedle zaniżonych standardów jakości nie ma większego sensu, bo albo nie będzie się on w ogóle nadawał do użycia, albo kumulować będzie się w nim dług techniczny.

Krok dziewiąty: ustalenie czasu trwania Sprintów

Nieoczywistym, aczkolwiek niezbędnym krokiem przed rozpoczęciem prac nad produktem jest określenie, jak długie będą Sprinty. Nie da się bowiem zaplanować iteracji bez całkowitego fantazjowania, jeśli nie wiadomo trzech rzeczy: jakie mamy możliwości, co chcemy osiągnąć i ile na to mamy czasu.

Zwracam uwagę, że Planowanie Sprintu to zdarzenie, w którego trakcie Zespół Scrum tworzy prognozę tego, jaki Cel Sprintu osiągnie, co w związku z tym zamierza zrobić i w jaki sposób. Wymaga to więc oceny, jak dużo czasu mogą zająć poszczególne działania, jeśli trzeba je wykonać w sposób umożliwiający spełnienie wymogów jakościowych zawartych w Definicji Ukończenia.

Jak dobrać czas trwania Sprintu na początek, jeśli jeszcze nie wiadomo, jak w praktyce przebiegał będzie development? Cóż, trzeba się tu posłużyć zgadywaniem, ale podpartym w takim stopniu, w jakim to możliwe, doświadczeniem Developerów. Być może pierwsze Sprinty okażą się za długie lub za krótkie, wtedy oczywiście trzeba będzie je skrócić albo wydłużyć. Niemniej, z czymś trzeba zacząć.

O ustalaniu długości iteracji pisałem już kiedyś, więc zainteresowanych odsyłam do stosownego artykułu. Tu dodam, że jeśli mamy wątpliwości, lepiej na początek zdecydować się na krótsze Sprinty, bo takie zdecydowanie łatwiej jest zaplanować, a poza tym – gdyby okazało się, że Zespół potrzebuje czasu, by nauczyć się dobrze planować – krótszy interwał iteracji pozwoli częściej dokonywać regularnych usprawnień w procesie.

Krok dziesiąty: pierwszy Sprint

W końcu można zorganizować Planowanie Sprintu i rozpocząć pierwszy Sprint. Pierwszy, bo nie ma „Sprintu zero”. Taki zerowy Sprint jest obecny tylko we wprowadzających w błąd artykułach i innych niegodnych posłuchu źródłach, a także w organizacjach, które kompletnie nie zrozumiały, że Scrum to metoda korzystająca z empiryzmu.

Sprint zerowy, czyli cała iteracja poświęcona na przygotowania do rozwoju produktu, nie jest żadnym Sprintem, bo nie powstaje w nim nic, co można by poddać sprawdzeniu i wyciągnięciu wniosków odnośnie do dalszych działań. Takie przygotowania kończą się jedynie postawieniem tezy, że jesteśmy gotowi do Sprintu pierwszego. A zatem nie nazywajmy tych przygotowań Sprintem, tylko po prostu przygotujmy się do rozpoczęcia prac nad produktem najlepiej, jak to możliwe, a wtedy zaplanować będzie można pierwszą iterację.

Co dalej?

Używać Scruma i obserwować.

A bardziej na poważnie: identyfikować utrudnienia, aby je usuwać, rozwiązywać problemy, szukać nowych możliwości (eksperymentując z narzędziami, praktykami itd.). Często wymaga to wpłynięcia na otoczenie Zespołu i wyedukowania go, bo bez wiedzy, jak działa Scrum, niemal zawsze pojawiają się działania skutkujące negatywnym wpływem na jego funkcjonowanie.

Warto też przygotować się na opór ludzi, którym Scrum się nie spodoba. Dążenie do zapewnienia przejrzystości skutkuje ujawnieniem istniejących problemów, a nie wszyscy będą z tego zadowoleni lub po prostu poczują się zagrożeni. Warto zrozumieć motywację ludzi, którzy oponują przeciwko Scrumowi, bo często da się zapewnić im coś, czego potrzebują, by stracić motywację do walki z nową metodą.

Koniecznie też trzeba stawiać sobie realistyczne cele, nie tylko te produktowe (Cel Produktu, Cel Sprintu). Chodzi mi teraz o cele związane z rozwojem Scruma jako takiego w Zespole, a także w organizacji. Nie da się użyć Scruma od razu dobrze niemal nigdzie, jest to raczej ciągły proces szukania sposobu, na użycie go lepiej niż do tej pory.

Ten realizm jest potrzebny też po to, by gdzieś po drodze nie ulec demotywacji. Nic bowiem nie podcina skrzydeł bardziej, niż poczucie, że dążymy do czegoś, co jest całkowicie poza naszym zasięgiem. A tak będzie, jeśli oczekiwać będziemy od siebie i Zespołów, że dokonamy cudu, przeskakując od braku wiedzy i doświadczenia w Scrumie do perfekcyjnego użycia tej metody.

Jeśli istnieją obiektywne powody, dla których działania Zespołu odbiegają (w tym momencie) od tego, jak wyglądałyby w idealnie działającym Scrumie, potrzeba czasu, by zmienić ten niekorzystny stan spraw. Dopóki ludzie nie zaczynają uznawać, że właściwie to już jest dobrze i po co w ogóle coś zmieniać, krok po kroku Scrum działał będzie lepiej, a za tym przyjdzie wzrost korzyści wynikających z jego stosowania.

Gdy produkt i Zespoły już istnieją

Proces wprowadzania Scruma w istniejących Zespołach i dla istniejących produktów zasadniczo się nie zmieni. Wciąż potrzeba dobrej definicji produktu, jego wizji, Product Ownera, Zespołów itd. Zamiast tworzyć wszystko od zera, trzeba będzie zweryfikować, że faktycznie mamy to, co niezbędne, ewentualnie wprowadzając korekty (niekoniecznie na modłę rewolucyjną, być może małymi kroczkami, odchodząc od czegoś, co istniało dotychczas, na rzecz nowego podejścia – by minimalizować opór).

Uwaga: może okazać się, że odkryjemy, iż ludzie ciężkim wysiłkiem chłopa i robotnika tracą czas na budowanie czegoś, co nie ma sensu. Próba zdefiniowania produktu okaże się nieudana, nie odnajdziemy żadnych interesariuszy, zrozumiemy, że sprawy toczą się siłą rozpędu i bardziej chodzi o to, by ktoś był zajęty, aby ktoś inny mógł tym zarządzać, niż o kreowanie korzyści. Scrum w tym nie pomoże, ale pozostawiam decyzję o tym, co wtedy zrobić odpowiedzialności każdego, kto znajdzie się w takiej sytuacji.

I jeszcze jedna uwaga: czasami okaże się, że niewielka grupa ludzi jest zmuszona utrzymywać coś, co nazywają produktem, ale jest to w istocie zlepek wielu różnych produktów, z których żaden nie uzasadniałby utrzymania całego dedykowanego Zespołu. Co wtedy? Cóż, nadal powinno się rozdzielić Backlogi Produktu, a Zespół nie powinien pracować na wieloma z nich w jednej iteracji, tylko przełączać się między nimi na przełomach Sprintów (zapewne krótkich).

Trochę trudniej będzie, jeśli próbujemy coś zdziałać na gruzach po Scrumie (a może raczej pseudo-Scrumie), którego ktoś próbował użyć, ale kompletnie nieskutecznie. Ewentualnie w sytuacji, gdy organizacja i Zespoły w niej posługują się czymś, co uważają za Scrum, a co z metodą nie ma za wiele wspólnego (lub wręcz jest rozległą kolekcją patologii i dysfunkcji, o jakich piszę w tej serii artykułów).

Wciąż przepis pozostaje z grubsza ten sam, choć niewątpliwie pojawi się dodatkowa praca związana z oduczaniem złych praktyk. Zalecam bardzo dużą ostrożność w krytykowaniu stanu początkowego, jakkolwiek by on nie był koszmarny. Jest, jaki jest, krytyka nic nie zmieni. Trzeba pokazać korzyści, jakie przynieść może zmiana tego stanu spraw, a także podpowiedzieć, jak zmiany tej można dokonać.

Zapomniałem o Scrum Masterach?!

O, właśnie. Piszę o Scrumie, a nie było ani słowa o Scrum Masterach. Nie, nie zapomniałem o nich. Zupełnie świadomie pominąłem informację, w którym kroku pojawia się Scrum Master, a przede wszystkim nie uznałem za stosowne wydzielić na to osobnego kroku. Dlaczego?

Odpowiedź lakoniczna: bo Scrum Master pojawi się wtedy, kiedy będzie potrzebny.

Nieco bardziej rozbudowana odpowiedź: być może Scrum Master będzie pierwszą osobą, która pomoże organizacji zabrać się za wprowadzenie Scruma w organizacji. Bardziej prawdopodobne, że zostanie wskazany (albo – co byłoby o wiele lepsze – sam podejmie się tej odpowiedzialności) w momencie, gdy formowane będą Zespoły. A może ciut wcześniej, np. zacznie pomagać Product Ownerowi, gdy tylko ten zostanie powołany.

Czy możliwe, że nie będzie Scrum Mastera, a rozpocznie się pierwszy Sprint? Nie jest to zupełnie wykluczone, bo w wielu organizacjach nie ma dużej wiary w sens zatrudniania Scrum Masterów, ani też nie ma tłumu chętnych do wzięcia na siebie tej odpowiedzialności. Niemniej wcześniej czy później Scrum Master się pojawi – bo ktoś w Zespole Scrum będzie dbał o skuteczność procesu i o sam proces.

Rzecz jasna nie namawiam do tego, by czekać na to, co przyniesie czas i kierować się zrządzeniami losu. Jeśli to możliwe, organizacja, która zamierza rozwijać produkty z użyciem metody Scrum, powinna jak najszybciej zadbać o wsparcie osób, które pomogą jej w zabraniu się za to z sensem. Będą one zarazem doskonałymi Scrum Masterami – na stałe albo na początek, zanim pomogą wykształcić swych następców.

O tym, jak przekonać organizację, że warto zatrudniać Scrum Masterów, napiszę jednak w osobnym artykule. W czasie oczekiwania zachęcam do zapoznania się z nieco innym tekstem traktującym o tym, ile wart jest Scrum Master.