SCRUM - spis by WN PWN

Spis treści

Wprowadzenie do nowego wydania

Rozdział 1

Sposób działania świata jest wadliwy

Rozdział 2

Początki Scruma

Rozdział 3

Zespoły

Rozdział 4

Czas

Rozdział 5

Marnotrawstwo to zbrodnia

Rozdział 6

Planować rzeczywistość, a nie fantazję

Rozdział 7

Szczęście

Rozdział 8

Priorytety

Rozdział 9

Przedsiębiorstwo

Rozdział 10

Zmieniać świat

Załącznik 1. Implementacja Scruma: jak zacząć

Załącznik 2. Przedsiębiorstwo Scrum: jak rozpocząć

Podziękowania

Wprowadzenie do nowego wydania

Sposób, w jaki działa świat, się zmienił.

– Uratował mi pan życie. – Kobieta miała rude włosy, czerwoną sukienkę i czerwone od płaczu oczy. Trzymała egzemplarz czerwonej księgi*. Tej księgi.

Przysięgam, że tego nie zmyślam. Staliśmy w sali wystawowej na konwencji Agile kilka lat po publikacji pierwszego wydania Scrum, czyli jak robić dwa razy więcej dwa razy szybciej**. W koło kręcili się ludzie, tak jak zwykle przy tego typu okazjach. Były tam stoiska firm dostarczających różne narzędzia, firm konsultingowych Agile, autorów podpisujących książki oraz firm programistycznych i technologicznych.

Potem zauważyłem inne stoiska: BP, Lockheed Martin, 3M, IBM, Target. Na plakietkach uczestników widniały też nowe nazwy: John Deere, Coca-Cola, Toyota, Ford, Exxon, Armia Stanów Zjednoczonych, Bloomberg, JPMorgan, Chase, Bain Accenture, Medtronic, Departament Bezpieczeństwa Wewnętrznego USA, Bank of America, The Broad Institute, Wells Fargo, Philips, Siemens… i tak dalej.

* Czerwona księga (ang. red book ) – żargonowe określenie na książki o tematyce ekonomicznej i politycznej (przyp. tłum.).

** J. Sutherland, Scrum, czyli jak robić dwa razy więcej dwa razy szybciej, tłum. M. Dąbrowska-Kowalik i W. Sikorski, PWN SA, Warszawa 2015.

Dziesięć lat temu musiałem przekonać ludzi, że Scrum będzie działał w ich kontekstach biznesowych. Czasami było to frustrujące. Wszyscy byli przekonani, że ich organizacja to wyjątkowy płatek śniegu. Cały ten Scrum byłby u nich nieefektywny, bo ich firmy były inne niż wszystkie. Że to, co zrobili, nie było oprogramowaniem, i Scrum nie mógł się odnosić właśnie do nich.

W ciągu tych dziesięciu lat przestałem się o to kłócić. Już nawet nie próbuję przekonywać ludzi. Teraz pozwalam, aby przekonywali ich konkurenci. Albo po prostu sam świat.

Kiedy wraz z J.J. dziesięć lat temu napisaliśmy pierwsze wydanie tej książki, mieliśmy kilka celów. Pierwszym było wyjaśnienie Scruma: dlaczego i po co istnieje każdy element ram postępowania. Co go powołało do życia. Jakie były założenia i stojące za nimi historie. Jak to wszystko działa. Nauka i idee, a nie po prostu praktyki. Drugim było dawanie ludziom narracji, opowieści zamiast rutyny. Na pewnym poziomie my, ludzie, jesteśmy tak naprawdę tylko historiami, które opowiadamy o nas samych. Chcieliśmy przedstawić nowe historie o nowym sposobie myślenia o pracy – tak naprawdę o ludzkim wysiłku. Po trzecie, chcieliśmy pokazać, że Scrum to nie tylko sposób tworzenia oprogramowania; to sposób myślenia o świecie. W ten sposób proste filary przejrzystości, inspekcji i adaptacji (ang. transparency, inspection, adaptation) można zastosować wszędzie. Scrum to uniwersalny akcelerator ludzkiego wysiłku. Nie ma znaczenia, czy tworzycie oprogramowanie, budujecie statki, produkujecie samochody, opracowujecie szczepionkę, prowadzicie sklep lub bank, wysyłacie roboty na Marsa, obsadzacie dział pomocy technicznej, walczycie na froncie, czy przygotowujecie kolację wigilijną. Scrum działa wszędzie.

Kiedy ja i siedemnaście innych osób stworzyliśmy i podpisaliśmy Manifest Agile (ang. Agile Manifesto) w 2001 roku, nikt z nas nie miał pojęcia, że właśnie powołaliśmy do życia nowy ruch. Sposób, w jaki podbił świat, zaskoczył nas wszystkich. W ciągu dziesięciu lat od pierwszego wydania książki stało się to jeszcze bardziej oczywiste. Jedną z rzeczy, które słyszałem przez lata, jest to, że podtytuł książki – robić dwa razy więcej w dwukrotnie krótszym czasie – jest nierealistyczny. Spowodowało to wiele dyskusji w społeczności Agile, a wielu ludzi twierdziło, że wyolbrzymiłem wpływ Scruma.

Kilka lat temu, o czym wówczas nie wiedziałem, zapytano Rona Jeffriesa, kolejnego sygnatariusza Manifestu Agile, czy to, co twierdzę, jest możliwe. Ron jest jednym z twórców Extreme Programming (XP) , podstawy wielu dzisiejszych standardowych praktyk tworzenia oprogramowania. Może znacie

terminy: DevOps, ciągłe dostarczanie (ang. Continuous Deployment, CD), ciągła integracja (ang. Continuous Integration, CI), programowanie w parach (ang. pair programming) lub programowanie sterowane testami (ang. Test-Driven Development, TDD)? Wszystkie stworzono w XP. Kiedy sceptycy napisali do niego z pytaniem, co wyniósł z książki, jego odpowiedź brzmiała:

Najważniejsze było to, że jeśli faktycznie utworzycie wielofunkcyjny zespół, poproście, aby pracował nad dostarczaniem działającego oprogramowania w każdym sprincie, aby pokazał to wszystkim interesariuszom, w tym kierownictwu. Dzięki codziennym spotkaniom, by ludzie zarządzali samymi sobą jako zespołem i analizie każdego sprintu, aby naprawdę poprawiali wyniki, oraz dzięki uprawnieniu Product Ownera do podejmowania decyzji... i do dostarczania produktu, powinniście otrzymać czterokrotność wartości tego, co robiliście wcześniej, bez żadnego wysiłku.

Żałuję tylko, że określili go jako „dwukrotną wartość w dwukrotnie krótszym czasie”.

Oczywiście możemy dyskutować o frazeologii, ale przesłanie jest takie samo: Scrum działa. Dwukrotnie więcej wykonanej pracy w dwa razy krótszym czasie jest łatwe do osiągnięcia. Ale naprawdę trzeba to przeprowadzić w uczciwy i dogłębny sposób. Potrzeba trochę rygoru. W bardzo realnym sensie nie jest to aż tak skomplikowane. Musicie tylko myśleć o tym na poważnie. W tym nowym wydaniu zaktualizowaliśmy i rozszerzyliśmy każdy rozdział. Omawiamy sztuczną inteligencję (AI) , zdalne zespoły w dobie pandemii, nowe badania nad ludzką wydajnością, znaczenie różnorodności i przyjęcie zasad Scruma we wszystkim, od urządzeń medycznych po rolnictwo, wojsko, energię, bankowość, modę i wiele innych.

Największą zmianą w książce jest rozdział o Enterprise Agility, czyli o zwinności przedsiębiorstwa, dotyczący zastosowania Scruma do przyspieszenia działań całej organizacji. To najbardziej rozwojowy element Scruma w ciągu ostatnich dziesięciu lat. Scrum nie jest już używany tylko przez pojedyncze zespoły, a nawet pojedyncze działy; jest wykorzystywany do napędzania innowacji i realizacji w całej firmie. Krok po kroku pokażemy wam dokładnie, jak to przeprowadzić na własnym podwórku.

Bo da się to zrobić. I często musi zostać zrobione.

W innym kraju, w innym miejscu, w innym czasie siedziałem z mężczyzną, który właśnie podjął zupełnie inną decyzję. Pogoda była szara, jak to często

bywa, woda też. Okna od podłogi do sufitu z najwyższego piętra ukazywały szarość panoramy na zatokę, ujętej w złotobrązowe refleksy drewnianych ram okiennych. Ta organizacja jest legendarna i istnieje od dziesiątków lat. Jej nieustające znaczenie na świecie rozkwitało w czasach wojny i pokoju, rewolucji i stabilności; kraje i reżimy przychodziły i odchodziły podczas jej warty. Dzień wcześniej lider tej grupy, liczącej dziesiątki tysięcy ludzi, ogłosił: Całe przedsiębiorstwo się zmieni. Zostanie wprowadzony Scrum na rzadko spotykaną skalę.

Opowiadałem mu już te historie. Rozmawialiśmy. Użyłem całej retoryki „zmiana albo śmierć” i wielu przykładów. Ale szczerze mówiąc, nie spodziewałem się, że zrobi to, co zrobił. To nie był mały krok. Ani prosty. Skierował organizację na ścieżkę, której pełne wdrożenie zajęłoby lata. Więc zapytałem go dlaczego.

– Posłuchaj – powiedział – nie wiem, czy to zadziała. Nie wiem, czy Scrum jest odpowiedzią, której szukamy. Wiem, że sposób, w jaki teraz pracujemy, zawiedzie, a to najlepsza opcja, jaką mam, abyśmy zmienili się w organizację, którą musimy być w 2035 roku.

Spojrzał na mnie. Od ponad czterdziestu lat przewodzi ludziom w najbardziej wymagających sytuacjach, w jakich można się znaleźć. Niebieskie oczy. Jasnobrązowe włosy. Postawa przywódcy. – Nie mam wyboru. Świat gna zbyt szybko. Nasi konkurenci rozwijają się zbyt szybko. Jeśli teraz się nie zmienimy, przegramy. Musimy się zmienić. Przerwał.

– Albo zginąć. Oto dlaczego.

Delikatny uśmiech przebiegł przez jego twarz, gdy cytował moje własne słowa. Potem spoważniał. Spojrzał w przyszłość i nie spodobało mu się to, co zobaczył. Radykalnej zmiany nie było na horyzoncie; była tutaj. I musiał radykalnie zmienić swoją organizację, aby to przeżyć. Ale nie chodziło tylko o przeżycie. Pragnął też zwycięstwa.

Patrzył na rewers monety. Scrum to nie tylko przetrwanie. Tu chodzi też o zwycięstwo.

– Wiele firm nie praktykuje limitów godzin pracy – mówi Scott – ale istnieje bezpośrednia korelacja. Kończycie więcej zadań. Jesteście szczęśliwsi. Podwyższacie jakość.

Podwójne wyniki dzięki skracaniu godzin pracy

Krzywa Maxwella

Ukończone zadania

metoda kaskadowa

Godziny przepracowane w tygodniu

Nie ma się nad czym zastanawiać. Mniej pracy pomaga szybciej osiągnąć więcej dzięki wyższej jakości.

Scott mówi, że dla każdego krzywa jest inna, nawet dla tej samej osoby w różnych momentach jej życia: – Zauważyłem, że w miarę starzenia się i w różnych rolach szczytowa wydajność jest dla mnie niższa niż dwadzieścia lat

Scrum

Zakres relatywnej wielkości

koncept roboczy cel cyklu życia produktu architektura cyklu życia wstępna gotowość operacyjna

WykonalnośćPlany/ wymagania

ProjektRozwój i testowanie

Fazy i kamienie milowe

Wróćmy na chwilę do Medco. Miesiącami planowali wysiłek: jak będzie wyglądał produkt, jak długo potrwa jego wprowadzenie. Nawet po tym czasie, jak jasno pokazują badania, szacunki najprawdopodobniej różniły się od rzeczywistości nawet czterokrotnie. To dlatego moim zdaniem planowanie metodą kaskadową jest naprawdę głupie.

– Okej, Sutherland – niemal słyszę wasze słowa – kiepsko szacujemy, ale musimy przecież coś zrobić, prawda? Musimy mieć jakiś plan. Macie rację: musi być jakiś plan. Kluczem jest dopracowanie go w trakcie trwania całego projektu, a nie wcześniejsze planowanie. Zaplanujcie szczegóły wystarczające do tego, aby zapewnić kolejny przyrost wartości, i oszacujcie pozostałą część projektu w większych częściach. W Scrumie pod koniec każdej iteracji otrzymujecie coś wartościowego, co można zobaczyć, dotknąć i pokazać klientom. Można wtedy

ich zapytać: Czy tego państwo chcą? Czy to rozwiązuje przynajmniej część państwa problemu? Czy zmierzamy we właściwym kierunku?

Jeśli odpowiedź brzmi „nie”, zmieńcie plan.

Ale jak to zrobić?

Porozmawiajmy o tym ślubie. Pierwszą rzeczą, którą należy zrobić, jest stworzenie listy wszystkich elementów składających się na udaną ceremonię. Może wyglądać mniej więcej tak:

Goście

Kwiaty

Zaproszenia

Miejsce ślubu

Miejsce wesela

Jedzenie

Urzędnik stanu cywilnego/duchowny

Stroje

Obrączki

Muzyka (DJ lub zespół)

Następną rzeczą jest posortowanie ich według priorytetów. Dla różnych ludzi kolejność będzie inna. Każda para młoda widzi świat inaczej. Pewnego dnia zapytałem przyjaciela, jak ułożył priorytety na swojej liście, i oto kolejność, którą wymyślił:

Goście

Urzędnik stanu cywilnego/duchowny

Obrączki ślubne