Jak przekonać szefa/zarząd do wdrożenia Scruma? Można śmiało założyć, że osoby związane z IT z reguły wiedzą, czym jest Scrum i jakie korzyści płyną z wytwarzania oprogramowania w sposób zwinny. Ta wiedza niestety nie jest powszechna u osób z pozostałych branż, a często zdarza się, że prezesi lub zarządy firm nie mają świadomości jego istnienia i korzyści, jakie daje.
Wdrażanie Scruma w organizacjach, w których zarząd nie miał z nim wcześniej styczności, zwykle rozpoczyna się od inicjatywy oddolnej, tzn. pracownicy sami decydują, że chcieliby zmienić sposób pracy na bardziej zwinny, i przekonują szefostwo do zaakceptowania tej zmiany. W rzeczywistości Scrum jest możliwy do skutecznego wdrożenia w firmie, tylko jeśli tę zmianę wesprze zarząd. Bez jego aprobaty niestety przedsięwzięcie najprawdopodobniej spełznie na niczym i skutecznie zniechęci pracowników do ponownych prób wdrożenia Scruma w przyszłości.
W tym artykule chciałabym przedstawić szereg informacji i wskazówek, które można wykorzystać w rozmowie z szefem, aby wyjaśnić mu, czym jest Scrum i jakie korzyści może dać wdrożenie go w Waszej organizacji.
Po pierwsze: musisz wiedzieć, co to Scrum
Nie przekonasz nikogo do Scruma, jeśli sam go dobrze nie będziesz znał. Dlatego w pierwszej kolejności przeczytaj Przewodnik po Scrumie (ang. Scrum Guide) autorstwa Jeffa Sutherlanda (współtwórca Scruma) oraz Kena Schwabera (współautor procesów scrumowych). Ma on zaledwie 14 stron (licząc stronę tytułową i spis treści) i jest łatwo dostępny w Internecie w wielu językach. Autorzy przewodnika często go aktualizują o dodatkowe wskazówki, które jeszcze bardziej mają usprawnić pracę w Scrumie, dlatego upewnij się, że czytasz najnowszą wersję.
Ogromną zaletą przewodnika jest to, że nie tylko opisuje on zasady Scruma, ale też wyjaśnia, dlaczego istnieją i są tak istotne. Dodatkowo, jeśli język angielski nie jest dla Ciebie problemem, to polecam zapoznanie się z książką Kena Schwabera: Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust (pl. Oprogramowanie w 30 dni: Jak zwinni managerowie pokonują przeciwności, zachwycają swoich klientów i zostawiają konkurencję w tyle).
Odradzam uczenie się formułek z poradnika i przedstawiania ich szefowi, bo raczej trudno mu będzie zrozumieć, o co nam chodzi, kiedy powiemy, że Scrum to wzorzec pracy, w którym ludzie mogą zaadresować skomplikowane problemy, a przy tym równocześnie w sposób produktywny i kreatywny dostarczać produkty o najwyższej możliwie jakości. Lepiej jest wytłumaczyć to własnymi słowami, jak najprościej, np. mówiąc, że Scrum to sposób rozwiązywania złożonych problemów poprzez dostosowywanie się do obecnej rzeczywistości i równoległe dostarczanie najwyżej jakości produktu.
Nawet sam Ken Schwebber, zapytany o to, czym się zajmuje, powiedział, że uczy ludzi, jak dostarczać działające oprogramowanie w 30 dni lub krócej.
Scrum jako model pracy
Przy wytwarzaniu oprogramowania najczęściej spotykamy się z dwoma modelami pracy – klasycznym kaskadowym (ang. Waterfall) oraz zwinnym (ang. Agile). Model kaskadowy opiera się na realizowaniu projektów z wykorzystaniem pewnych stałych elementów i zachowaniu ich kolejności. Są to:
- Zebranie wymagań -> analiza biznesowa -> projektowanie - > wytwarzanie - > testowanie -> oddanie klientowi gotowego produktu
Scrum, który jest jednym z najpopularniejszych modeli zwinnego wytwarzania oprogramowania, nie przeczy konieczności przechodzenia przez wszystkie te etapy, ale umieszcza je w mniejszych przedziałach czasowych (ang. time box) zwanych sprintami, które z reguły trwają od 1 do 4 tygodni. Na sprint składa się planowanie, które trwa przez cały czas jego trwania oraz po zakończeniu, a także analiza, wytwarzanie, testowanie, integrowanie nowego elementu oprogramowania z wcześniej wytworzonym oraz weryfikacja, czy produkt jako całość działa tak, jak założono.
To, co szczególnie wyróżnia Scrum w porównaniu do innych metod, to fakt, że nie czekamy na zakończenie jednego etapu, aby móc przejść do kolejnego. Wszystkie mogą dziać się równolegle, co w zauważalny sposób przekłada się na efektywność pracy. Co więcej, po każdym zakończonym sprincie zespół wyciąga wnioski odnośnie produktu, sposobu pracy oraz planuje, w jaki sposób może poprawić proces (np. jak zwiększyć efektywność czy wyeliminować ryzyko powstawania błędów). Moim zdaniem jest to najbardziej wartościowy element pracy zespołu deweloperskiego, gdyż promuje kulturę ciągłego doskonalenia i bieżącego adresowania napotkanych problemów.
Mówiąc o Scrumie, należy pamiętać o tym, że nie jest to sztywny zbiór wytycznych i zasad. Na poparcie tych słów wystarczy spojrzeć na jego genezę. Od momentu powstania w 1985 roku był wiele razy zmieniany i usprawniany, aby zwiększyć jego efektywność. Dopiero w 2008 roku oficjalnie do zespołu scrumowego został dołączony Product Owner, a w 2016 pojawiły się wartości Scruma, którymi są: zaangażowanie, skupienie, otwartość, szacunek i odwaga. Wartości te powinny być wdrożone nie tylko w zespołach stosujących metody zwinne, ale w całej organizacji. Tylko wtedy będą spełniały swoją rolę. Myślę, że możemy śmiało założyć, że w kolejnych latach w Scrumie będą pojawiały się kolejne zmiany.
Elastyczność Scruma i zmiany mające na celu jego doskonalenie są jego głównymi atutami. Nieraz błędnie przyjmuje się, że Scrum jest to metodologia, którą należy wdrożyć w 100%, aby przyniosła korzyści dla firmy. Należy tutaj podkreślić, że jest to model, który można dopasowywać do specyfiki organizacji. Potrzebujesz, aby w sprincie zawrzeć dodatkowe kroki, np. ze względu na specyficzne wymogi klienta? Nic nie stoi na przeszkodzie!
Dlaczego organizacje wdrażają Scrum?
Faktem jest, że coraz więcej organizacji wdraża lub chce wdrożyć Scrum. Z perspektywy organizacji najczęściej wynika to z potrzeby wprowadzenia operacyjnej zwinności. Uniwersalność tego modelu zarządzania sprawia, że sprawdza się on nie tylko w IT, ale też w różnych innych obszarach, szczególnie tych, w których występują projekty.
W 2018 roku Standish Group, wskutek badań prowadzonych na różnego typu projektach, opublikowało raport CHAOS, z którego wynikało, że projekty zwinne mają aż o 60% większe szanse powodzenia niż projekty niezwinne. Co więcej, projekty kaskadowe niosą trzy razy większe ryzyko niepowodzenia niż zwinne.
Ta sama grupa w latach 2013-2017 prowadziła podobne badania nad projektami, w wyniku których okazało się, że 42% projektów zwinnych kończy się sukcesem — w porównaniu do zaledwie 26% projektów kaskadowych. Jeszcze większa różnica pojawiła się w przypadku projektów zakończonych porażką: takich projektów zwinnych było w badanej grupie tylko 8%, zaś kaskadowych — aż 21%.
Powyższe dane jasno obrazują, dlaczego coraz częściej spotykamy projekty zwinne. Minimalizacja ryzyka oraz zwiększenie szansy powodzenia projektu, a przy tym nieskomplikowany sposób wdrożenia Scruma, sprawiają, że wypada on dużo lepiej na tle projektów tradycyjnych.
Co ważniejsze: projekt czy produkt?
W organizacjach możemy spotkać się z dwoma podejściami wytwarzania produktu. Jedno z nich polega na skupieniu się na projekcie, czyli działaniu, a drugie — na produkcie, czyli efekcie końcowym.
Projekt definiujemy jako określone w czasie przedsięwzięcie mające na celu uzyskać unikalny produkt, usługę lub efekt. Każdy projekt jest unikalny i nie ma w nim rutynowych operacji. Ponadto ma zdefiniowany zakres i zasoby. Jest określony w czasie czyli ma zdefiniowany początek i koniec. Przy zarządzaniu projektem należy wykonać pewne zdefiniowane etapy, do których należą: inicjacja, planowanie, realizacja, monitorowanie, kontrola i zamknięcie.
Jedną z ważniejszych wad podejścia projektowego jest to, że czasem zdarza nam się definiować sukces jako realizację założonego planu. Wprowadzanie zmian jest sformalizowane i często odrzucane właśnie ze względu na to, jak wpływają one na plan. Dodatkowo trudno jest określić precyzyjnie etap realizacji, np. jak mogę stwierdzić, jak wiele pracy mam jeszcze do zrobienia, jeśli nie znam zastanego kodu (ang. legacy code), nad którym mam jutro zacząć pracować?
Podsumowując, projekty są napędzane przez plan, a sukces definiuje się jako realizacja tego planu, a nie produkt końcowy, który zostanie wytworzony.
Jeśli chodzi zaś o produkty, to oczywiście mogą one być wynikiem jakichś projektów. Mają swoją żywotność (ang. lifespan) i mogą pojawiać się inkrementacyjnie, tzn. w czasie można rozwijać produkt, np. o dodatkowe funkcjonalności, modyfikować istniejące itp., mając na celu zwiększenie jego wartości.
Skupiając się na produkcie, warto pamiętać o tym, że niedoskonały produkt w rękach klienta przyniesie nam więcej pieniędzy niż doskonały produkt, którego jeszcze klientowi nie dostarczyliśmy. Oznacza to, że dostarczanie klientom produktów będących idealną całością nie jest opłacalne. Każdy dzień zwłoki to strata pieniędzy. Znacznie rozsądniej jest dostarczać już produkt, który przynajmniej w pewien sposób spełnia oczekiwania klienta, a następnie pracować nad jego udoskonaleniem.
Należy jednak zawsze pamiętać o jakości. Jeśli produkt nie spełnia norm jakości, to nic na nim nie zyskamy, gdyż klient nie będzie pamiętał o tym, że np. dostarczono mu produkt z lekkim opóźnieniem, ale za to na pewno zapamięta na długo, że dostarczono mu produkt słabej jakości i najprawdopodobniej już do nas nie wróci, a może nawet podzieli się swoimi negatywnymi doświadczeniami z innymi.
Produkt i projekt w Scrumie
Scrum skupia się na produkcie, czyli dostarcza elementy działającego oprogramowania, które posiada funkcje czyniące program wartościowym dla klienta. Oznacza to, że każdy sprint dostarcza nową wersję oprogramowania.
To, co odróżnia podejście scrumowe od projektowego, to m.in. to, że produkty zwykle nie mają z góry założonego okresu żywotności, ale mają jasno zdefiniowaną datę zakończenia. Ponadto produkt w Scrumie ciągle się zmienia i ewoluuje i w przeciwieństwie do projektów może być oddawany klientowi wielokrotnie, na różnych etapach realizacji, a nie tylko po zakończeniu projektu. Jednak najważniejsza różnica dotyczy zmiany i jakości. W projektach często próbuje się kontrolować zmianę poprzez kontrolę ryzyka, natomiast Scrum akceptuje zmianę, aby zmniejszyć ryzyko. Jeśli chodzi o jakość, to w projektach nieraz ryzykuję się utratę jakości, naciskając na realizację projektu w wyznaczonym terminie. Scrum kontroluje jakość poprzez postawienie jasnych wymagań co do produktu (Definition of Done).
Muszę tutaj jednak zaznaczyć, że projekty i Scrum wcale się nie wykluczają. Coraz częściej można napotkać projekty zarządzane przez Scrum. Wynika to z tego, że w niektórych sytuacjach elementy obu podejść są potrzebne, a przecież mogą one ze sobą współgrać. Takie podejście sprawdza się szczególnie w przypadkach, gdy dany produkt ma być wytworzony w określonym czasie, jednak niesie ze sobą duże ryzyko. W takich projektach dobrze jest utworzyć backlog (listę zadań do zrealizowania) i poukładać go pod względem priorytetów – najważniejsze i najbardziej ryzykowne funkcjonalności powinny znaleźć się na górze. Pozwoli to zaadresować w pierwszej kolejności elementy objęte największym ryzykiem.
Jedną z głównych cech projektów scrumowych jest umieszczanie najmniej wartościowych funkcjonalności na dole backloga. Dzięki temu maksymalizujemy wartość produktu, który wytwarzamy i ryzykujemy pominięcie tylko tych elementów, bez których produkt nie traci dużo na swojej wartości. Ponadto, w tego typu projektach można dokonywać zmian w elementach backlogu, które nie trafiły jeszcze do realizacji. Oznacza to, że jeśli w trakcie trwania projektu pojawi się potrzeba modyfikacji jakichś funkcjonalności, to będzie ją można w prosty sposób wprowadzić. Oczywiście projekty scrumowe mają też cechy tradycyjnych projektów, m.in. jasno określoną datą zakończenia projektu oraz wycena całego backlogu następują przed rozpoczęciem pracy.
Co więcej, każdy sprint możemy traktować jako mikroprojekt, który mierzy sukces w oparciu o efekty pracy, a nie podążanie za z góry określonym planem. To jest właśnie największa wartość tego podejścia.
Niepewność i ryzyko w Scrumie
Pojęcie niepewności to nieodzowny element zarządzania projektami. Musimy ją zaakceptować, gdyż może wystąpić na każdym etapie realizacji, a im bardziej projekt jest złożony, tym większa niepewność.
Ralph Stacey opublikował model, w którym wskazał zależność między stylem pracy a niepewnością. Wyróżnił cztery style: prosty, skomplikowany, chaotyczny i złożony. W stylu prostym niepewność jest adresowana na każdym kroku, gdyż planuje się tutaj działania i monitoruje zachowanie poprzez porównanie ich z planami. Następnie powtarza się te działania, które przynoszą korzyści. W stylu skomplikowanym ogromną rolę odgrywa polityka firmy, budowane są koalicje, przeprowadza się negocjacje, a decyzje to najczęściej kompromisy oparte o agendę lub ideologię firmy.
Styl chaotyczny zwany jest również rozłamem lub anarchią. Tutaj żadna tradycyjna metoda planowania czy zarządzania niepewnością nie działa. Prace stają w miejscu i nikt nie ma pojęcia, co zrobić, żeby ruszyć dalej. Ostatni z wymienionych styli to styl złożony, który jest najbliższy Scrumowi, gdyż wymaga zaakceptowania kreatywności, nowych pomysłów, częstych zmian mających na celu ciągłe doskonalenie, a ponadto opiera się na danych, a nie na opiniach czy przeczuciach.
W Scrumie zarządzanie ryzykiem i niepewnością odbywa się na poziomie pojedynczego sprintu. W związku z tym firma w wypadku zaistnienia ryzyka ponosił bardzo mały koszt, bo tylko ten obejmujący sprint, w którym ryzyko wystąpiło. Dodatkowo częsty feedback nt. produktu zmniejsza ryzyko i niepewność. W tradycyjnych projektach zdarzają się dłuższe okresy, kiedy nie ma feedbacku, gdzie po prostu wykonywana jest zaplanowana praca, a ryzyko i niepewność narastają. W Scrumie tego nie znajdziemy.
Regularny feedback to cecha charakterystyczna Scruma i przydaje się nie tylko w IT, ale i na poziomie całej organizacji. Bardzo wiele firm, które z sukcesem wdrożyły zwinność przy zarządzaniu projektami IT, decyduje się też na zaaplikowanie wybranych elementów Scruma w innych działach organizacji, np. poprzez organizowanie retrospektyw po zakończeniu przedsięwzięć (np. akcji promocyjnych) i ustalanie, co się udało zrobić dobrze, a jakie działania wymagają skorygowania w przyszłości.
W Scrumie każdy zakończony sprint to lekcja dla zespołu, z której powinny być wyciągane wnioski, aby w przyszłości pracować jeszcze lepiej i jeszcze bardziej zwiększać wartość produktu. W niesamowity sposób redukuje to ryzyko i niepewność oraz pozwala na unikanie popełniania w przyszłości tych samych błędów. Taka retrospektywa — przeprowadzana systematycznie i poprawnie — niesamowicie zwiększa szanse na zakończenie sukcesem całego projektu.
Scrum jest jak badania naukowe
Praca w Scrumie może przypominać doświadczenia naukowe, gdyż między nimi istnieje cały szereg podobieństw. Najpierw stawia się jakieś pytanie lub potrzebę (np. "chcę nową funkcjonalność X"). Następnie przechodzi się do fazy obserwacji i zbierania danych (zderzamy to, co klient mówi, że chce mieć, z tym, czego realnie potrzebuje). Formułujemy hipotezę (np. dodanie funkcjonalności X w tym miejscu sprawi, że więcej osób zwróci uwagę na produkt i go kupi), którą następnie testujemy poprzez przeprowadzenie eksperymentów i zebranie danych (po każdym oddaniu produktu). W dalszej kolejności analizujemy zebrane dane (czy naprawdę sprzedaż produktu wzrosła?), interpretujemy je i formułujemy nową hipotezę (np. jeśli eksperyment się nie powiódł albo jest coś, co można by zrobić lepiej, żeby jeszcze bardziej zwiększyć sprzedaż). Na koniec publikujemy wyniki (do zespołu, klienta itp.) i zaczynamy cały proces od nowa.
Całe to podobieństwo między Scrumem a badaniami naukowymi wynika z tego, ze Scrum opiera się na empiryzmie. Oznacza to, że wymaga dowodów odnośnie tego, jak idą postępy prac. Codzienne spotkania (tzw. Daily Scrum), planowanie czy retrospektywa właśnie są po to, aby wspierać empiryzm. Każde działania oraz wnioski wyciągane po zrealizowanej pracy opierają się właśnie na takich eksperymentach, jakie opisano w poprzednim akapicie. Każdy sprint to eksperyment (czy uda nam się zbudować właściwy produkt dla klienta?), a podsumowanie sprintu (ang. Sprint Review) weryfikuje to, czy eksperyment zakończył się powodzeniem. Wartość dodana do projektu jest efektem przeprowadzonego eksperyment, a sprint może potwierdzać stawianą hipotezę lub jej zaprzeczyć, zaś zebrane dane mają na celu usprawnić przyszłe sprinty.
Wysokowydajnościowe zespoły
Jak można stwierdzić, czy zespół jest wysokowydajnościowy? Tak naprawdę nie ma tu żadnej filozofii, bo widać to na pierwszy rzut oka. Takie zespoły pracują lepiej od innych zespołów, a ich praca wykracza poza oczekiwania, jakie przed nimi postawiono. Cechy zespołów wysokowydajnościowych to m.in.:
- mają wspólne cele, które wyznaczają sobie sami, ale także wyznacza im je lider bądź Product Owner,
- rozumieją potrzeby klienta,
- korzystają z procesów, które wspierają ich pracę, np. wzajemna weryfikacja kodu,
- posiadają wiedzę i umiejętności, które się wzajemnie uzupełniają, powalając zespołowi jako całości wytwarzać kompletne elementy oprogramowania,
- stale ze sobą współpracują,
- otwarcie udzielają sobie wzajemnego feedbacku, a ponadto proszą o pomoc i poradę w razie napotkania problemu,
- zasięgają wzajemnej opinii.
To, że wiemy, jak wygląda wysokowydajnościowy zespół i jakie posiada cechy, to jedno, ale pojawia się tutaj pytanie: jak utworzyć taki zespół? Jak znaleźć i zebrać ludzi, którzy posiadają wachlarz umiejętności (np. znają różne technologie), posiadają dodatkowe umiejętności miękkie, potrafią skupiać się na kliencie i jego potrzebach, a przy tym przyświeca im cel, jakim jest osiągnięcie technicznej i użytkowej doskonałości, a co za tym idzie — wytwarzają produkt mający największą możliwość jakość?
Tak naprawdę to na początku nie chodzi tutaj nawet o sam zespół, ale o przywództwo. Liderzy zespołu powinni przede wszystkim inspirować, rozwiązywać konflikty, promować współpracę i wyznaczać ambitne cele. Ponadto powinni stale komunikować, jaki jest cel, i wizję tego, co robi zespół, a przede wszystkim powinni cieszyć się zaufaniem całego zespołu. Mając takiego lidera, zespół niemal samoczynnie przeobrazi się w wysokowydajnościowy.
Jednak samo posiadanie takiego zespołu to nie wszystko. Trzeba go przecież jeszcze utrzymać. Jak to zrobić? Przede wszystkim należy doceniać zespół jako całość, np. chcąc zwiększyć zasoby ludzkie w zespole, powierz rekrutację nowej osobie w zespole – kto lepiej, niż oni sami, znajdzie odpowiednią osobę do zasilenia ich szeregów? Ponadto, inwestuj w rozwój i naukę – wysyłaj na szkolenia (ale na takie, na które zespół chce iść) lub ustal, że jeden dzień w miesiącu zespół będzie mógł przeznaczyć na rozwój i naukę. Pamiętaj też, aby zapewnić zespołowi odpowiedni sprzęt (komputer, biurko, monitory itp.), dbaj o to, by zespół miał wszystko czego potrzebuje do pracy i inwestuj w dobrej jakości infrastrukturę.
Jeśli wysokowydajnościowy zespół ma pracować w oparciu o Scrum, to ważne jest, aby upewnić się, że posiada odpowiednią wiedzę i umiejętności na jego temat. Firma nie powinna tutaj oszczędzać na szkoleniu, bo przecież członkowie zespołu muszą dobrze wiedzieć, jak mają pracować. Jednakże nie można tutaj popaść w skrajność i kontrolować zespół, by robił tylko to, co napisane jest w Przewodniku Scruma. Najkorzystniej będzie pozwolić zespołowi uzupełniać proces o te elementy, które uważa, że pozytywnie wpłyną na jego pracę.
Przywództwo służebne w Scrumie
Przywództwo służebne (ang. servant leadership) wprowadził Robert Greenleaf i zdefiniował je jako filozofię i zespół praktyk, które mają za zadanie poprawiać życie ludzi poprzez budowanie lepszych organizacji i tworzenie czegoś więcej niż tylko przyjaznego świata.
Brzmi dość górnolotnie i nie do końca wiadomo, o co chodzi, prawda? James C. Sorros definiuje lidera stosującego przywództwo służebne jako osobę, która dzieli się władzą z podwładnymi, na pierwszym miejscu stawia potrzeby pracowników, a także pomaga ludziom się rozwijać i osiągać najwyższą możliwie wydajność. No dobrze, ale co to znaczy, że dzieli się władzą? Głównie polega to na tym, że zachęca podlegające mu zespoły do samoorganizacji i kiedy tylko to możliwie, to pozwala im samodzielnie podejmować decyzje. Dzięki temu zespoły mogą się rozwijać, gdyż zdobywają poczucie niezależności, współpracy i wspólnego podejmowania decyzji.
Może teraz zastawiasz się, jaki jest empiryczny dowód na to, że przywództwo służebne sprawdzi się w zespołach Scrumowych? Najlepiej będzie posłużyć się życiowym przykładem. Amerykańska sieć restauracji Popeyes w obliczu problemów finansowych postanowiła wprowadzić radykalne zmiany w sposobie zarządzania firmą. Założyli, że w ciągu 7 lat zostaną jednymi z liderów sprzedaży w branży fast food oraz będą oferować najlepszy sposób szybkiego dostarczania żywności. Aby to osiągnąć, wdrożyli przywództwo służebne. Po zakończeniu eksperymentów zebrali dane, które wskazały, że sprzedaż wzrosła o 30%, zyski o 40%, a cena akcji Popeyes wzrosła z 13 dolarów do 58. Zarząd Popeyes w wywiadach publikowanych w sieci bardzo pozytywnie odnosi się do rezultatów wdrożenia tego modelu przywództwa i nie zamierza z niego rezygnować.
Scrum nie zadziała bez wsparcia organizacji, a właśnie przywództwo służebne opiera się głównie na udzielaniu wsparcia pracownikom niższych szczebli. Co więcej, wymaga odwrócenia kierunku spełniania potrzeb. W tradycyjnym schemacie pracownicy na dolnych szczeblach organizacji wspierają tych na wyższych. W Scrumie powinno to wyglądać odwrotnie. Innymi słowy należy osiągnąć stan, w którym liderzy ufają zespołom znajdującym się na niższych szczeblach, że wykonają właściwą pracę.
Podsumowanie
Jak wspomniałam na wstępie, kluczem do wdrożenia Scruma w organizacji jest przekonanie zarządu do słuszności tego przedsięwzięcia. Co więcej, warto jest wdrożenie przeprowadzać małym krokami. Ogłoszenie ogromnej rewolucji w firmie może napotkać opór wśród pracowników, którzy mogą nie posiadać wiedzy na temat tego, co się dzieje i jakie są oczekiwane skutki. Dlatego polecam zacząć najpierw od codziennych spotkań (Daily Scrum) i retrospektywy. Jak zespół zacznie widzieć korzyści z nich płynące, to można przejść do wdrażania kolejnych elementów. Komunikuj postępy i sukcesy w całej firmie – to najlepszy sposób, aby utwierdzić zarząd w przekonaniu, że podjął dobrą decyzję, decydując się na wdrożenie Scruma, a ponadto może zainspirować innych pracowników do wdrożenia zwinnych praktyk.
Mam nadzieję, że niniejszy artykuł pomoże Ci w przygotowaniu się do rozmowy z szefem nt. wdrożenia Scruma. Trzymam kciuki, aby się udało!
