Scrum w praktyce - ebook

ROZDZIAŁ PIERWSZY.
PRZED NAMI WYBÓR

Jedną z najbardziej ekscytujących rzeczy w życiu jest dla mnie ciągłe odkrywanie, że to, jak sobie wyobrażałem działanie świata, nie jest w istocie sposobem, w jaki on funkcjonuje. Odkrycie tego, jak bardzo się mylę, jest dla mnie fascynujące. Wynika z tego, że istnieje świeższy, lepszy, bardziej dokładny i lepiej obejmujący sposób widzenia świata. Otrzymałem dar, dzięki któremu zdałem sobie sprawę, że moje dotychczasowe aksjomaty, moje zafiksowane sposoby rozumienia działania rzeczy były błędne. Zwykle okazuje się, że sposób, w jaki wszystko działa w biologii, nauce, biznesie i w życiu, jest bardziej zawiły i poplątany, bardziej subtelny i bardziej otwarty na zmiany, niż kiedykolwiek sobie wyobrażałem. To niezwykle wyzwalające.

Przypomina mi to opowieść leżącą u podstaw publikacji przełomowej książki Antoine’a Lavoisiera, _Traité élémentaire de chimie_, opublikowanej w 1798 roku. Lavoisier zaproponował, aby za pomocą rygorystycznie prowadzonych eksperymentów można było wyprowadzać podstawowe zasady:

Jest to maksyma powszechnie przyjęta w geometrii, a faktycznie w każdej dziedzinie wiedzy, że powinniśmy przechodzić od znanych faktów do tego, co jest nieznane… W ten sposób z szeregu doznań, obserwacji i analiz wyłania się ciąg idei tak ze sobą powiązanych, że uważny obserwator może prześledzić wstecz do pewnego punktu porządek i połączenie całej sumy ludzkiej wiedzy¹.

Lavoisier wysunął teorię, że istnieją podstawowe pierwiastki chemiczne, które są niepodzielne. Twierdził, że stanowią one elementy składowe materii. I zaczął rygorystycznie ich szukać. To on nazwał tlen, wodór i węgiel, odkrył rolę tlenu w spalaniu i oddychaniu, pokazał, że woda składa się z wodoru i tlenu. Zrewolucjonizował chemię. Stworzył nowy język, aby opisać, jak części składowe reagują ze sobą. Innymi słowy, opisał na nowo działanie świata. Potrafił zastosować podstawowe zasady, które wyznaczył, aby przewidzieć istnienie innych pierwiastków, które nie zostały odkryte za jego życia.

Przed Lavoisierem chemicy potrafili badać tylko te związki chemiczne, które podsunęła im natura. Jego idea polegała na tym, że zamiast ograniczać się do tych elementów, dlaczego nie eksperymentować, aż do znalezienia całego wszechświata wszystkich możliwych związków chemicznych, a nie tylko tych, na które wygodnie się natkniemy?

Jego pomysł był oszałamiający. Publikacja książki stała się jednym z kamieni milowych w historii nauki. Przed Lavoisierem uczeni i intelektualiści zakładali, że świat działa w jeden sposób. Potem zrozumiano, że funkcjonuje on inaczej. Narodziła się nowoczesna chemia. Świat uległ fundamentalnej zmianie. Dziś wszystko – od guzików do koszuli po chłodziwa w lodówce, tusz liter tej książki czy też chip sterujący trzymanym przez was urządzeniem podczas jej czytania – istnieje tylko dzięki temu odkryciu.

Uwielbiam, gdy coś takiego się dzieje. Gdy nowe odkrycie zasadniczo zmienia sposób rozumienia przez nas świata, w którym żyjemy. Gdy wszystko, co uważaliśmy za znane, zostaje zakwestionowane dzięki nowym informacjom lub danym. Gdy świat jednego dnia wydawał się określony w jeden sposób, a następnego pokazują się możliwości, z których dzień wcześniej nie zdawaliśmy sobie sprawy.

NOWY SPOSÓB MYŚLENIA

W okresie, jaki upłynął od publikacji mojej pierwszej książki, _Scrum: The Art of Doing Twice the Work in Half the Time_*, której współautorem był mój ojciec, Jeff Sutherland, coraz więcej ludzi ma świadomość faktu, że stoimy w obliczu podobnej zmiany w świecie biznesu. Rewolucja pobudza zmiany w świecie biznesu. I podobnie jak praca Lavoisiera, pokazuje nowy świat, w którym stare ograniczenia nie mają zastosowania. W moich rozmowach z firmami, prezesami i dyrektorami używam teraz nowego sformułowania: Scrum to sztuka zmieniania tego, co _możliwe_.

Potrzeba stosowania Scruma wynika z szybkich zmian społecznych, ekonomicznych i politycznych, szczególnie z postępem technicznym. Każdy z pewnością słyszał o prawie Moore’a, które sformułował Gordon Moore, współzałożyciel Intela. W 1965 roku napisał artykuł _Cramming More Components onto Integrated Circuits_. To, co dziś nazywamy prawem Moore’a, było wnioskiem z tego artykułu: liczba tranzystorów w chipie będzie się podwajać co dwa lata. Jest to wzrost wykładniczy. No i koszt zwiększonej mocy komputerowej spadnie w tym samym czasie o połowę.

Trudno nam pojąć, jak szybkie są te zmiany. Tego, co nastąpi, nie jesteśmy w stanie ocenić. Przytoczę starą francuską zagadkę dziecięcą, aby zilustrować, jak szybko się to wszystko dzieje. Dotarliśmy nad piękny staw z liliami – może ten w Giverny, który stał się sławny dzięki obrazom Moneta. Wyobraźcie go sobie. Spokojna woda, lilie pływające na powierzchni, mostek, niebo i drzewa otaczające staw odbijające się w wodzie.

Załóżmy, że liczba lilii w stawie każdego dnia się podwaja. Po trzydziestu dniach całkowicie pokryją one powierzchnię wody, zasłaniając staw płatkami. Lilie, nie ze swojej winy, zabiją życie w stawie – ryby, żaby, a także same siebie. Ale mamy jeszcze czas, aby ocalić staw. W końcu lilie są piękne. Jeśli zdecydujemy się poczekać, aż lilie pokryją połowę stawu, to ile dni będziemy mieć na uratowanie stawu?

Jeden. Tylko jeden. W dniu dwudziestym dziewiątym lilie pokryją połowę stawu. Następnego dnia pokryją cały staw.

Pozwólcie, że podam jeszcze jeden przykład tempa, jakie niesie za sobą podwajanie się tranzystorów i mocy. Użyjmy słynnego przykładu z ziarnkami ryżu** na szachownicy, który pochodzi z roku 1256 (już w XIII wieku ludzie myśleli o tego typu sprawach). Jeśli umieścimy ziarnko ryżu na jednym kwadracie szachownicy, a następnie podwoimy liczbę ziaren na każdym kolejnym kwadracie, to po dojściu do ostatniego pola na szachownicy liczba ta zostanie podwojona 63 razy. Ostatni kwadrat zawierałby około 9 kwintylionów (a dokładnie 9 223 372 036 854 775 808) ziaren. Jest to niewyobrażalnie duża liczba. Nie do ogarnięcia. Niezgłębiona. Odzwierciedla ona szybkość zmian, które zachodzą w naszym życiu. Stare sposoby pracy załamują się w obliczu gwałtownie zmieniających się problemów, które są poza ich możliwościami radzenia sobie. Złożoność nie jest już rzadkością – jest tym, z czym codziennie musimy się zmagać.

CO SIĘ STANIE PO TYM, CO NADEJDZIE

Scrum jest sposobem, w jaki osoba, zespół lub organizacja mogą reagować na tę złożoność, na zmiany, których nie sposób przewidzieć, na zręczne przejście z entuzjazmem przez wciąż zmieniającą się przestrzeń. Szybkość zmian, które nam towarzyszą, wymaga innego sposobu pracy. Scrum stanowi odpowiedź na ten problem.

Ale żeby poznać prawdziwą moc Scruma, ten rodzaj ogromnej produktywności i dostarczanej wartości, musi nastąpić fundamentalna zmiana w zarządzaniu i działaniach. Wprawdzie część zespołów scrumowych potrafi dostarczyć produkt z niezwykłą szybkością, ale tym, czego naprawdę oczekujemy, jest Scrum na poziomie przedsiębiorstwa. Tradycyjne struktury muszą ulec zmianie, systemy premiowania i zarządzanie wydajnością muszą się zmienić, a ludzie w całej organizacji, nawet jeśli sami nie należą do zespołów scrumowych, muszą się nauczyć, jak współpracować, dostarczać, pomagać i zarządzać tymi _zespołami_ w nowy sposób.

Gdy ludzie w tradycyjnych organizacjach pojmą skalę koniecznych zmian, czasami rozkładają ręce. To niemożliwe. To zbyt wielki skok. W istniejących firmach jest za dużo biurokracji, za dużo historii, za dużo korporacyjnego _załatwiania spraw_. „Nie możemy zmienić wszystkiego” – mówią menedżerowie. – „Tak się tutaj nie pracuje”. A gdy coś się nie powiedzie, zaczynają szukać, na kogo zrzucić winę.

Nie ma znaczenia, kto jest odpowiedzialny za sukces lub porażkę firmy ani za to, jak wydano pieniądze lub co poszło źle. Liczy się tylko jedno: co się stanie po tym, co nadejdzie? Przeszłość to przeszłość. To prawda w biznesie, polityce i związkach. Jak naszym zdaniem ma wyglądać przyszłość? Jak się ustawić, aby skorzystać ze zmian, które uznajemy za potrzebne? Jak wbudować w zespół, oddział lub firmę nie tylko coś dla przetrwania, ale system, który pomoże zespołowi wzmocnić się przy każdym napotkanym problemie? Jak zbudować system dostatecznie solidny, aby przy każdej katastrofie nie tylko doszedł do siebie, lecz także rósł, uczył się i zyskał nowe możliwości?

Najlepsze organizacje uczą się na błędach i sukcesach, a potem systematycznie wykorzystują te lekcje, aby się ulepszyć. Gdy moje zespoły pokazują mi coś, co się nie powiodło, często mówię im: „Świetnie. Teraz wiemy, co nie działa. Następnym razem pokażcie mi ciekawszy błąd”.

Tym, czego najbardziej chcemy, jest to, co nazywam renesansowym przedsiębiorstwem – takim, które uwolniło się z pęt przeszłości, od starych sposobów patrzenia na świat, i potrafi tworzyć rzeczy, które kilka lat temu były niewyobrażalne. Potrzebujemy prawa Moore’a dla ludzi. Jak sami mamy się stać szybsi, bardziej efektywni i produktywni? Jak to zrobić w odpowiedniej skali?

ŚWIAT Z KLOCKÓW LEGO

Pojedźcie ze mną do północnej Europy – domu Ikei, _Dziewczyny z tatuażem_, zespołu Abba, zapewne najlepszych klopsików na świecie i słońca świecącego o północy. Szwecja jest także domem Saaba. Saab produkował kiedyś samochody – ta działalność była dla tej firmy marginalna. Tym, czym Saab się zajmuje, jest produkcja myśliwców wojskowych. Kto by pomyślał?

Saab buduje myśliwce od roku 1937. Było wtedy wiadomo, że wojna ogarnie pożogą cały świat, a Szwecja, która nie była sprzymierzona z żadną stroną ani krajem, zdecydowała się na budowę własnych sił powietrznych. Kraj ten, podobnie jak Szwajcaria, prowadził oficjalną politykę neutralności od czasów napoleońskich. I potrafił oficjalnie utrzymać tę politykę podczas drugiej wojny światowej i zimnej wojny. Z jednej strony miał NATO, z drugiej – ZSRR, co było stresującą sytuacją dla naszych przyjaciół z tego rozległego terytorialnie państwa.

Szwedzi zatem sami zbudowali siły powietrzne. W roku 1950 zaprezentowali myśliwiec Saab 29 Tunnan, który w tym czasie dorównywał najlepszym myśliwcom odrzutowym. Zbudowali 55 operacyjnych eskadr, a wiele z nich było w gotowości do startu w ciągu sześćdziesięciu sekund. Wtedy zaczęli sprzedawać swoje samoloty Austrii, Południowej Afryce, Tajlandii i innym krajom.

Po Tunnanie były Lansen, Draken, a potem w latach osiemdziesiątych XX wieku Gripen A/B, po którym pojawiła się wersja C/D. I wtedy wystąpił problem. Gripen był dobrym samolotem i sprzedawał się dobrze. Ale Saab i szwedzcy wojskowi chcieli go zmodernizować, aby był mocniejszy, miał większy zasięg i lepsze uzbrojenie. I tak pojawił się pomysł Gripena E. Na początku inżynierowie chcieli po prostu zmodernizować około sześćdziesięciu istniejących samolotów Gripen 39C, gdyż samoloty są drogie i trudno się je buduje. Tymczasem, podczas aktualizacji samolotów, przyjęli Scruma – najpierw tylko w grupie oprogramowania. Ale wkrótce zaczęła ona obejmować projektowanie, prace inżynierskie, jakość i inne obszary. Scrum@Scale to modułowa platforma organizacyjna z zespołami wielofunkcyjnymi, które szybko dostarczają wartość. Ale gdy rozpowszechnił się w Saabie, władze firmy wyszły z nowym pomysłem – a może samolot powinien odzwierciedlać strukturę organizacyjną firmy?

„Chcemy mieć samolot, który potencjalnie będzie latał przez 50 lat” – wskazał Saab. – „Wiemy, że technika się radykalnie zmieni w ciągu dziesięcioleci. Obecne projekty samolotów są bardzo trudne do aktualizacji. Są ściśle powiązane. Każdy element jest związany z innym. A może zbudować samolot złożony z modułów, które można łatwo rozłożyć i złożyć z powrotem, podobnie jak zespoły scrumowe w firmie? Moglibyśmy aktualizować cały system przez cały czas. Nie musielibyśmy czekać na cały nowy program modernizacji. Zamiast tego zróbmy go tak, aby gdy pojawią się nowy radar, nowe komputery lub lepsze silniki, po prostu wyjmiemy stary element i podepniemy nowy, bez ruszania reszty samolotu. Co by było, gdybyśmy zbudowali myśliwiec bojowy tak, jakby był zbudowany z klocków Lego?”.

„Chcemy, aby był to system typu plug-and-play” – powiedział Jorgen Furuhjelm z Saaba. – „Nazywamy to inteligentnym myśliwcem. Nie wiemy, czego będą chcieli nasi klienci za kilka lat”.

Trzeba będzie opracować lepszy silnik? Nie ma problemu – możemy go wymienić. Poprawiony radar? Zrobione. Bardziej poręczne uzbrojenie? Rozwiązane. Filozofia Saaba pozwala, aby Gripen robił rzeczy, które wydają się niemożliwe. Może wylądować na drodze w ekstremalnych warunkach pogodowych. Można go zatankować i ponownie uzbroić w ciągu dziesięciu minut – trzeba do tego sześciu ludzi i żadnych narzędzi. Większość myśliwców wymaga na to dwa do trzech razy więcej czasu. W Saabie można wymienić silnik w ciągu godziny. Oto zalety modułowości.

A przy tym firma to _przyjemne_ miejsce pracy. Szwedzcy studenci kierunków inżynierskich tylko Google’a stawiają wyżej w kategorii „najlepsze miejsce pracy”. I w przeciwieństwie do większości firm na świecie, w których ludzie najchętniej wcale nie chodziliby do biura, pracownicy Saaba _chcą_ codziennie iść do pracy.

„Chodzi o zaangażowanie. Ludzie uważają, że projekt jest w porządku. Naprawdę świetny. Fascynują się samolotami. A tego poczucia zaangażowania w zespołach można niemal dotknąć” – podkreśla J. Furuhjelm.

To jest siłą Scruma. Wyzwala u ludzi szybszą i bardziej wydajną pracę, a jednocześnie pozwala wykonać więcej pracy w krótszym czasie. Zespoły pracują z pasją i bez przeszkód. Gdy Saab przyjął Scruma, okazało się, że skupiając się na usuwaniu przeszkód, mogą wyzwolić olbrzymie pokłady potencjału ludzi.

Choć Gripen E jest po prostu lepszy, z lepszymi częściami i wyposażeniem – lepszy w zasadzie we wszystkim – od swojego poprzednika, samolot jest tańszy do opracowania, tańszy w budowie i tańszy w działaniu. Utrzymanie stu pięćdziesięciu Gripenów w powietrzu przez czterdzieści lat będzie nas kosztować około 22 miliardów dolarów. To połowa tego, ile wynosiłoby utrzymanie sześćdziesięciu pięciu amerykańskich F-35.

A dokonali tego dzięki Scrumowi. Zbudowali od podstaw wysoko zaawansowany myśliwiec. Często zdarza się, gdy pracuję dla firm, że menedżerowie mówią: „Och, platforma Scrum jest przeznaczona do tworzenia oprogramowania. To, co robimy, jest zbyt skomplikowane, aby mogło być zwinne (Agile)”.

„Jestem pewien” – mówię wtedy – „że cokolwiek robicie lub budujecie, nie jest to bardziej skomplikowane niż myśliwiec bojowy”.

NIE JESTEM PEWIEN, CZY ŚWIAT JEST TAKI, JAK SĄDZIMY

W ostatnich latach Scrum, często pod flagą zwinności (Agile), stał się wszechobecny. Nie jest już tylko sposobem pracy w firmach zajmujących się oprogramowaniem i technologią, lecz także coraz częściej w dużych firmach niemal w każdej dziedzinie. Podmioty specjalizujące się w bankowości, motoryzacji, produkcji urządzeń medycznych, biotechnologii, ubezpieczeniach, opiece zdrowotnej i w innych dziedzinach postawiły na Agile jako sposób na utrzymanie się na aktualnym poziomie. Czołowe firmy, takie jak Bosch, Coca-Cola, USAA, Schlumberger, Fidelity i Lockheed Martin, przeszły na Scrum, aby dostarczać produkty wartościowe i dobrej jakości w tempie, które jest obecnie wymagane przez ich klientów.

Wiele z tego jest napędzane tym, co często nazywamy dziś transformacją cyfrową. Chodzi o to, że czasy oddzielania biznesu i technologii informacyjnej (IT) minęły bezpowrotnie. Teraz każda firma jest firmą technologiczną. Oprogramowanie zapanowało nad światem. W naszym samochodzie jest więcej wierszy kodu niż w systemie Windows. Nawet moja nowa pralka żąda hasła do Wi-Fi.

Teraz firmy – często zachęcane przez prezesów, którzy zobaczyli prezentację na konferencji TED lub słyszeli o korzyściach, jakie niesie Agile, od swoich kolegów lub od firmy konsultingowej – decydują, że choćby się waliło i paliło, postawią na zwinność.

Czas więc zdefiniować pojęcie zwinności, Agile, i jego związek ze Scrumem. Jeff Sutherland i Ken Schwaber wymyślili Scruma w 1993 roku, a dwa lata później sformalizowali go. W połowie lat dziewięćdziesiątych XX wieku w grupach Usenet i na konferencjach pojawiały się osoby, które walczyły, aby znaleźć sposoby tworzenia oprogramowania, które nie stałoby się koszmarną porażką, co stawało się coraz częstsze.

W 2001 roku siedemnastu z tych ludzi spotkało się na kilka dni w ośrodku narciarskim Snowbird w Utah. Był tam mój ojciec Jeff Sutherland, był Ken Schwaber i jeszcze jeden zwolennik Scruma, Mike Beedle. Pozostałych czternastu uczestników miało różne doświadczenia zawodowe i metodologiczne, ale doszli do wniosku, że wszyscy próbują podchodzić do tych samych problemów w podobny sposób, a może nawet tak samo.

Pierwszego dnia, jak opowiadało mi kilka obecnych tam osób, spierali się przede wszystkim o to, jak nazwać ten parasol, który istniał, ale nie był nazwany. Pod koniec dnia Mike Beedle zasugerował nazwę Agile. Wszyscy zgodzili się, że ta nazwa jest bardziej chwytliwa niż na przykład proponowana również Lightweight. Zdecydowali się więc na nazwę Agile. Potem zaczęli debatować nad tym, co to oznacza.

Następnego dnia nadal się spierali. OK, niech będzie Agile, ale co to właściwie znaczy? Jak można to opisać? Dziewięciu uczestników postanowiło zrobić przerwę na papierosa, a pozostałych ośmiu zostało w pomieszczeniu. Jeden z nich, Martin Fowler, podszedł do tablicy i powiedział coś w rodzaju: _Byłby wstyd, gdybyśmy niczego nie uzgodnili w ciągu tych dwóch dni._ Po piętnastu minutach ośmiu uczestników doszło do następującego wniosku:

ODKRYWAMY LEPSZE SPOSOBY TWORZENIA OPROGRAMOWANIA, ROBIĄC TO I POMAGAJĄC ROBIĆ TO INNYM. W RAMACH TEJ PRACY ZACZĘLIŚMY CENIĆ:

1. - _ludzi i interakcje bardziej niż procesy i narzędzia,_
2. - _działające oprogramowanie bardziej niż kompleksową dokumentację,_
3. - _współpracę z klientem bardziej niż negocjowanie kontraktu,_
4. - _reagowanie na zmiany bardziej niż trzymanie się planu._

INNYMI SŁOWY, CHOCIAŻ CENIMY ELEMENTY PO PRAWEJ STRONIE, BARDZIEJ CENIMY TE PO STRONIE LEWEJ.

Po piętnastu minutach, gdy pozostałych dziewięciu uczestników wróciło do pokoju, Ward Cunningham – twórca między innymi Wiki – powiedział: „To jest doskonałe!”. Nie zostało zmienione ani jedno słowo.

Zatem to jest Agile. To oświadczenie o wartościach. Resztę dnia uczestnicy spędzili na opracowaniu dwunastu zasad, jak „Prostota – sztuka maksymalizowania ilości pracy niewykonanej – jest kluczowa” oraz „Twórzcie projekty wokół zmotywowanych ludzi. Dajcie im potrzebne środowisko oraz potrzebne wsparcie i zaufajcie, że wykonają powierzone zadanie”, a także „Ciągła uwaga na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność”. Wszystko to ważne sprawy, ale brakuje opisu, jak je zrealizować. Nie było platformy, nie było metodologii, tylko cztery wartości i kilka zdroworozsądkowych zasad.

I to zmieniło świat. Umieścili _Manifest Agile_ (_Agile Manifesto_) na witrynie internetowej agilemanifesto.org i wrócili do domów, aby poświęcić się ciężkiej pracy nad praktyką. Nie zdawali sobie sprawy, że będzie to miało wielki wpływ znacznie wykraczający poza świat oprogramowania.

Ale chcę was ostrzec, że gdy ktoś mówi, że działa według Agile, to trzeba go koniecznie zapytać, co przez to rozumie. Scrum jest najpopularniejszym sposobem robienia tego – około 70 procent zespołów Agile używa Scruma. Nie jest to w żadnym wypadku jedyny sposób, ale stwierdzenie, że firma jest zwinna (Agile), nie mówi nam zbyt dużo.

PRAWO MOORE’A DLA LUDZI

Jeśli ktoś nie słyszał wcześniej o Scrumie albo poznał jego podstawy, ale nadal nie wie, jak to może pomóc w biznesie, daję krótką lekcję historii o tym, skąd Scrum pochodzi i co ma robić.

Osoby pracujące w Dolinie Krzemowej były zaniepokojone wpływem prawa Moore’a na szybki postęp techniczny od końca lat osiemdziesiątych XX wieku. W miarę jak kolejne maszyny były zdolne zdziałać coraz więcej, projekty programistyczne zaczęły być bardziej skomplikowane i niestety porażka tych projektów stała się powszechna, marnując czas, energię, produktywność i marzenia.

Weźmy na przykład projekt TAURUS z giełdy londyńskiej z tego okresu. TAURUS to akronim _Transfer and Automated Registration of Uncertified Stock_ (Transfer i automatyczna rejestracja niecertyfikowanych akcji). Problemem był tu system rozrachunku ceny na giełdzie o nazwie Talisman. _Rozrachunek_ to termin oznaczający, że „otrzymujemy to, za co zapłaciliśmy”. Po zakupie akcji na giełdzie przeniesienie tych akcji do naszego portfela mogło więc zająć dwa do trzech tygodni i wymagało dostarczenia tego papierowego certyfikatu z jednego miejsca w drugie. System zakupu i sprzedaży nosił nazwę Seaq. Był systemem elektronicznym, ale nie mógł porozumiewać się z systemem Talisman, który poprzedzał go o wiele lat.

TAURUS powstał, by to naprawić. Był to elektroniczny system rozrachunków, który miał zastąpić stary system papierowy i być powiązany z handlem międzynarodowymi papierami wartościowymi. Byłby świetny. Ale pojedynczy handlowcy potrzebowali jednego, a hurtownicy czegoś innego. Większość chciała, aby TAURUS był kompatybilny z ich niestandardowym systemem, a nie zastępował go. Do programu zaczęto więc wprowadzać coraz więcej wymagań.

Nadal miał być świetny. Miał zintegrować około siedemnastu różnych systemów. Niesamowite. Problem, według Hamisha McRae, który opisał w „Independent” 12 marca 1993 roku, był trojakiego rodzaju. Po pierwsze, próba budowy wielkich systemów oprogramowania od zera i jednocześnie uruchomienie go jest ryzykowna. Nie ma miejsca na drobne awarie i błędy. Najmniejsza pomyłka może być katastrofą. Mimo to podejście takie było powszechne i czasami spotyka się je także dziś. Firmy zakładają, że jakiś wielki system naprawi wszystko od razu. Zgodnie z danymi Standish Group około 40 procent projektów działających w ten sposób to porażki². Połowa z nich ma opóźnienia, przekracza budżet i nie daje tego, co powinny. W przypadku TAURUS-a były nikłe szanse na powstanie systemu, który miałby zastąpić system rozliczeń w jednym z głównych centrów finansów.

Po drugie, co wskazał McRae, choć ważne, aby system działał, preferowany jest dość dobry system działający nieskończenie długo zamiast idealnego systemu, który nie działa. Nigdy nie pozwól, aby doskonały był wrogiem dobrego. W przypadku projektu TAURUS, jak w niemal każdym projekcie, „pełzanie zakresu” stało się dzwonem pogrzebowym. _Czyż nie byłoby wspaniale, gdyby system robił nie tylko to, o czym myśleliśmy i co zaplanowaliśmy, lecz jeszcze jedną rzecz dodatkowo? A gdyby przygotowywał świetne espresso podczas oczekiwania klienta na finalizację transakcji, to byłoby jeszcze wspanialsze,_ i tak dalej. W końcu projekt, który na początku był prosty i dobrze zdefiniowany, staje się urządzeniem Rube’a Goldberga, które powinno robić wszystko dla wszystkich. I oczywiście kończy się to tak, że nie potrafi wykonać nawet najprostszych rzeczy, które projektanci chcieli przede wszystkim osiągnąć.

Wciąż widzę to w firmach przez pryzmat jednego ogólnego systemu: SAP. SAP jest na rynku liderem tego, co nazywamy systemem planowania zasobów przedsiębiorstwa (_enterprise resource planning_ – ERP). Systemy ERP mają robić wszystko. To olbrzymie bazy danych, które śledzą zasoby takie jak pieniądze, surowce czy zdolności produkcyjne i kojarzą je z listami płac, fakturami, zamówieniami i tak dalej. System ERP dotyka każdego elementu firmy – zaopatrzenia, sprzedaży, zasobów ludzkich, księgowości, produkcji, naprawdę wszystkiego – i integruje je cyfrowo. W zasadzie działa dość dobrze, jeśli używamy gotowej wersji.

Problem pojawia się, gdy jak w przypadku TAURUS-a, wszyscy są podekscytowani magicznym rozwiązaniem _wszystkiego_: integracji każdego systemu, porozumienia ze starymi komputerami typu _mainframe_ z piwnicy, obsługi przetwarzania w chmurze, połączenia ze sobą różnych fragmentów przygotowanych i używanych przez różne wydziały. Lub zastąpienia tego wszystkiego czymś lepszym! I zaczyna się pełzanie zakresu. _Niech gada z istniejącym systemem, którego używaliśmy przez 30 lat._ Albo: _Powinien obejmować każdą funkcję tego produktu z pudełka, który kupiliśmy 20 lat temu, a który nie jest już wspierany_. Ta lista nie ma końca.

Tylko w okresie ostatniego pół roku współpracowałem z trzema globalnymi korporacjami, które przez ponad dekadę próbowały zaimplementować SAP. W międzynarodowej firmie zajmującej się napojami – zapewne każdy z was pił dziś jakiś jej produkt – po rozmowie o prostocie rozwiązań inżynier nachylił się do mnie i powiedział półgłosem: „Wydaliśmy na to ponad miliard, a to dalej nie działa”. W innej firmie zatrudniającej setki tysięcy osób pracujących w najbardziej odległych zakątkach naszej planety powiedziano mi, że miliard dolarów to taniocha. Oni wydali półtora miliarda na SAP, a on nadal nie działa. Nie będę przygnębiał trzecim przykładem. Uwierzcie mi, jest źle. Wszystkie trzy firmy łączy jedno: pomimo miliardów dolarów i tysięcy ludzi system nie działa. A oni nadal topią w nim kolejne miliony dolarów rocznie, postępując tak jak wcześniej, ale oczekując innych wyników.

Ale wracając do TAURUS-a, wspaniałego klejnotu do rozliczeń, i tych biednych dusz zajmujących się syzyfową pracą polegającą na integracji siedemnastu różnych propozycji sposobów działania systemu. Oni próbowali. Naprawdę.

W kwestii ostatniego problemu z TAURUS-em zacytuję tu akapit z pracy McRae:

Giełda nie słuchała swoich klientów. Ma klientów różnego typu: firmy członkowskie, firmy, których akcjami handluje, inwestorów instytucjonalnych, inwestorów indywidualnych. Członkowie martwili się kosztami TAURUS-a, firmy były niezadowolone (a niektóre odmawiały pomocy), instytucje w najlepszym przypadku nie zajmowały się tym, a w najgorszym były wrogo nastawione, a każdy mały inwestor, który się w tym orientował, był zaniepokojony dodatkowymi opłatami, które musiał ponosić. Forsowanie czegoś przy tak dużym oporze wymaga wyjątkowej arogancji.

„Wyjątkowa arogancja” – arogancja eksperta. Arogancja specjalisty. Arogancja biurokraty. Arogancja procesu ponad ludźmi, gdzie większą wartość przykłada się do zawiłego opisu rzeczy, które działają, niż do samych rzeczy. Egoistyczny nacisk na to, żeby ludzie wkładali więcej serca i umysłu w wypracowany plan, zamiast rozważnej idei, że wszystko się zmienia, więc może lepiej ująć w planie.

TAURUS, który powstał jako piękna idea, został odwołany w 1993 roku po latach wysiłków, z tysiącami ludzi pracującymi dniami i nocami i około 75 milionami funtów wyrzuconych w błoto. Ogólny koszt poniesiony przez udziałowców szacuje się na 400 milionów funtów.

To bardzo dużo. Ale także dużo zmarnowanego czasu i życia. Wielu mądrych ludzi, którzy poświęcili lata na utworzenie czegoś, co stało się synonimem katastrofy technologicznej.

Bardzo bym chciał powiedzieć, że TAURUS jest jednym z najgorszych przykładów, jakie mogę podać, ale tak nie jest. Jest ich znacznie więcej. Projekt o nazwie Connecting for Health narodowego systemu zdrowia, który miał stworzyć elektroniczną dokumentację medyczną w Wielkiej Brytanii: dziewięć zmarnowanych lat przy koszcie 12 miliardów funtów. System amerykańskiej armii, Expeditionary Combat Support System: siedem zmarnowanych lat przy kosztach 1,1 miliarda dolarów. Kalifornijski departament motoryzacji wydał dziesiątki milionów dolarów, rozpoczynając w 1987 roku budowę systemu, który w roku 1990 był gorszy niż ten, który miał zastąpić – a mimo to nie potrafiono z niego zrezygnować do roku 1994. Dziennik „San Francisco Chronicle” opisał to jako „system niemożliwy do działania, którego nie da się naprawić bez wydawania kolejnych milionów”.

Nasze maszyny stały się szybsze, a ich możliwości wzrosły, lecz ludzie nie brali tego pod uwagę – to był kontekst, w jakim mój ojciec pracował na początku lat dziewięćdziesiątych XX wieku. Jeśli chcecie poznać całą jego historię, przeczytajcie książkę _Scrum, czyli jak robić dwa razy więcej dwa razy szybciej_. Ale w skrócie opracował on nowy sposób pracy. Jego krytyczne spojrzenie pozwoliło stwierdzić, że są takie porażki, które nie są winą zaangażowanych w pracę ludzi. Menedżerowie, inżynierowie i projektanci w tych projektach, które się nie powiodły, nie byli złymi ludźmi. Nie byli głupi. Nie spowodowali porażki. Mieli wielkie cele i marzenia, aby dokonać zmiany sposobu, w jaki działa świat.

To nie ludzie zawiedli, lecz system. Chodziło o sposób pracy, o myślenie o tym, co miało się zdarzyć, gdy udawali się na spotkania, aby omawiać i planować swój wysiłek. Dla nich był to po prostu sposób wykonywania pracy. Praca w inny sposób oznaczałaby kwestionowanie oczywistości – jakby ryba kwestionowała, że jej gatunek mieszka w wodzie.

PRZEWODNIK PRZETRWANIA

Ludzie, których stanowiska pracy są zagrożone przez automatyzację, nie różnią się od korporacji, których sens istnienia jest stale zagrożony. Niezależnie od tego, czy dokonujemy w pracy osobistych wyborów, planujemy strategiczne cele dla dużej firmy wielonarodowej, czy decydujemy o tym, jak kultura dostosuje się do nowych okoliczności z całkiem innym zbiorem aksjomatów, to zdolność do szybkiej adaptacji decyduje o naszym sukcesie. Jak mój ojciec napisał w naszej ostatniej książce: _Zmień się lub umrzyj_.

W tej książce chcę jednak dać kilka nowych narzędzi. Oprowadzę czytelników po świecie i przejdę z przestrzeni kosmicznej do centrów obsługi, od radykalnych nowych technologii do restauracji. Trendy mogą wydawać się przerażające, ale wierzę, że możemy nauczyć się akceptować zmiany tak, abyśmy byli bardziej odporni i mniej się bali, mieli większe możliwości, aby odrzucić to, czego nie możemy już robić, aby działać w globalnym celu, nie dając się uwięzić przez siły wokół nas.

Chodzi o to, że Scrum tak naprawdę nic nie robi. On tylko uwalnia wielkość, która jest w nas. Ta wielkość jest na wyciągnięcie ręki. Może być ukryta lub stłamszona, ale nigdy jej naprawdę nie tracimy. Tacy jesteśmy jako ludzie. Jednego dnia uważamy, że świat działa w jakiś sposób, a następnego okazuje się, że w rzeczywistości tak nie jest. Po chwili okazuje się, że patrzyliśmy na świat przez wąską soczewkę, a mamy cały wszechświat możliwości, o których nigdy nie pomyśleliśmy, a nagle możemy zmienić sposób działania świata… a tak naprawdę zawsze mogliśmy to zrobić.

DO ZAPAMIĘTANIA

- _SCRUM TO SZTUKA ZMIENIANIA TEGO, CO MOŻLIWIE__._ Możecie dostosować się do świata przyspieszających zmian i zobaczyć co wy, wasza organizacja, wasi współpracownicy i wasi ludzie tak naprawdę potraficie. Niezależnie od tego, czy dokonujecie osobistych wyborów dotyczących pracy, czy też planujecie cele strategiczne dla dużej firmy międzynarodowej, zdolność do szybkiej reakcji zadecyduje o waszym losie.
- _PORAŻKA JEST NIEUNIKNIONA I BEZCENNA__._ Nie ma znaczenia, kto jest odpowiedzialny za sukces lub niepowodzenie firmy, ile wydano pieniędzy i co się nie udało. Najlepsze organizacje uczą się na własnych błędach i sukcesach, systematycznie wykorzystując te lekcje, aby być lepszymi.
- _PERFEKCJA JEST PRZECENIANA__._ Dość dobry system, który działa, jest o wiele lepszy niż dążenie do systemu idealnego, który nie funkcjonuje.

REJESTR

- Przejrzyjmy każdą z czterech wartości Agile i oceńmy, jak zwinni jesteśmy my i nasza organizacja. Pamiętajmy, że „są wartości w elementach po prawej, ale bardziej cenimy elementy po lewej”.
1. - Poszczególnych ludzi i interakcje bardziej niż procesy i narzędzia.
2. - Działające bardziej niż kompleksową dokumentację.
3. - Współpracę z klientem bardziej niż negocjowanie kontraktu.
4. - Reagowanie na zmiany bardziej niż trzymanie się planu.
- Przeanalizujmy reakcję naszej organizacji na niepowodzenie. Czy jest to dobra okazja do nauki, czy czas na wskazywanie palcem?
- Oceńmy zdolność waszą i waszej organizacji do adaptacji i innowacyjności. Jak łatwo możesz dotrzymać kroku zmieniającym się potrzebom, chęciom i wymaganiom? Czy potrafimy zaburzyć dotychczasowe działania, czy będziemy czekać, aż staną się przestarzałe? Co pomaga, a co przeszkadza naszej zdolności do reagowania na zmiany?