To nowe podejście nosi nazwę „Scrum”. Stworzyłem je dwadzieścia lat temu. Obecnie to j e d y n a sprawdzona metoda, pomocna w tego rodzaju projektach. Są dwa sposoby działania: stara metoda kaskadowa, która marnowała setki milionów dolarów i często nie dawała żadnych wyników, lub nowa, która przy pomocy mniejszej liczby osób i w krótszym czasie może dostarczyć więcej rzeczy o wyższej jakości i mniejszym kosztem. Wiem, że to brzmi zbyt pięknie, aby było prawdziwe, ale dowodem są wyniki. To działa.
Dwie dekady temu byłem zdesperowany. Potrzebowałem nowego sposobu podejścia do pracy. A poprzez masę badań i eksperymentów oraz przeglądanie starych danych zdałem sobie sprawę, że nowego sposobu organizowania ludzkich wysiłków potrzebujemy wszyscy. Bez kosmicznych technologii; była o tym mowa już wcześniej. Istnieją badania sięgające II wojny światowej, które przedstawiają lepsze sposoby pracy, lecz z jakiegoś powodu ludzie nigdy nie łączą ze sobą wszystkich składających się na nie elementów. Próbowałem zrobić właśnie to przez ponad dwadzieścia lat, aż moja metodologia stała się wszechobecna w pierwszej dziedzinie, w jakiej ją zastosowałem – w tworzeniu oprogramowania. W takich gigantach, jak Google, Amazon i Salesforce.com oraz w nowych małych firmach, o których jeszcze nie słyszeliśmy, radykalnie zmieniła sposób realizacji zadań.
Powód, dla którego ta zasada działa, jest prosty. Przyglądałem się, jak ludzie pracują n a p r a w d ę, a nie temu, c o m ó w i ą o swojej pracy. Przeanalizowałem badania robione przez dziesiątki lat oraz najlepsze praktyki w firmach na całym świecie i przyjrzałem się dokładnie najlepszym zespołom w tych firmach. Co uczyniło je najlepszymi? Co sprawiło, że są inne? Dlaczego niektóre osiągają wielkość, a inne pozostają miernymi?
Z powodów, którymi zajmuję się dalej, ten schemat działania, służący poprawie wydajności zespołów, nazwałem „metodą Scrum” (młyn). Termin zaczerpnąłem z gry w rugby; dotyczy sposobu współpracy w drużynie dla przeniesienia piłki przez pole. Staranne ustawienie w linii, jasny cel i zjednoczenie w dążeniu do niego łączą się ze sobą. To idealna metafora tego, co według mnie powinna robić grupa.
Tradycyjnie kierownictwo chce w każdym projekcie dwóch rzeczy: kontroli i przewidywalności. To prowadzi do powstawania ogromnej liczby dokumentów, wykresów i tabel, tak jak w przypadku Lockheeda. Miesiące pracy idą na planowanie każdego szczegółu, aby nie było żadnych błędów, żadne go przekraczania kosztów. A wszystko zostanie dostarczone zgodnie z harmonogramem.
Problem polega na tym, że faktycznie sytuacja nigdy nie rozwija się zgodnie z założonym różowym scenariuszem. Cały wysiłek włożony w planowanie, próby ograniczania zmian, próby poznania niepoznawalnego idą na marne. Każdy projekt obejmuje rozpoznanie problemów i przypływy inspiracji. Usiłowanie zawężenia jakiegoś zakresu ludzkich wysiłków do kolorowych wykresów i diagramów jest niemądre i skazane na niepowodzenie. Nie w ten sposób pracują ludzie i nie tak projekt posuwa się do przodu. To nie jest sposób, w jaki idee wydają owoce lub tworzy się wielkie rzeczy.
Natomiast prowadzi on do frustracji tych, którzy nie dostają tego, czego chcieli. Projekty opóźniają się, przekraczają budżet – i w wielu wypadkach – kończą się beznadziejną klęską. To dotyczy w szczególności zespołów zaangażowanych w tworzenie czegoś nowego. W większości przypadków kierownictwo nie widzi drogi prowadzącej w stronę niepowodzenia, zanim nie wyda nadaremnie milionów dolarów i nie straci tysięcy godzin.
W metodzie Scrum stawiamy pytanie dlaczego wykonanie czegoś zajmuje tak dużo czasu i tyle wysiłku. I dlaczego tak słabo idzie ustalenie, ile wymaga ich rzeczywiście. Wybudowanie katedry w Chartres zajęło 57 lat. Mogę się założyć, że na początku projektu kamieniarze spojrzeli na biskupa i powiedzieli: „Najwyżej 20 lat. Prawdopodobnie będzie gotowa w 15”.
Scrum łączy w sobie niepewność i kreatywność. Tworzy strukturę wokół procesu poznawania, co daje zespołom możliwość oceny zarówno tego, co zrobiły, jak i – co równie ważne – jak to zostało zrobione. Algorytm Scrum wykorzystuje sposób, w jaki faktycznie pracują grupy ludzi, i daje im narzędzia do samoorganizacji i szybkiego poprawiania zarówno szybkości, jak i jakości pracy.
W swoich podstawach Scrum opiera się na prostym założeniu: dlaczego na samym początku projektu nie sprawdzać regularnie, czy działamy we właściwym kierunku i czy robimy to, czego faktycznie chcą ludzie? I pytać, czy nie ma żadnych sposobów poprawienia tego, co robimy, jakichś metod zrobienia tego lepiej i szybciej, oraz co mogłoby nas przed tym powstrzymać.
Właśnie to nazywamy cyklem „sprawdzania i dostosowywania” (Inspect and Adapt). W niewielkich odstępach czasu należy przerywać swoje zajęcia, sprawdzać, co zostało zrobione, i patrzeć, czy to, co robimy, jest nadal właściwe. I jak można by zrobić to lepiej. Pomysł jest prosty, lecz jego realizacja wymaga introspekcji, uczciwości i dyscypliny. W tej książce chcę pokazać, jak to zrobić. I to nie tylko firmom tworzącym oprogramowanie. Widziałem metodę Scrum stoso- waną z powodzeniem do budowy samochodów, zarządzania pralnią, nauczania, tworzenia statków kosmicznych, planowania ślubu, a nawet – do czego użyła jej moja żona – do sprawdzenia w każdy weekend, czy została zrealizowana („Zrób to, kochanie”) lista domowych obowiązków.
Końcowym wynikiem metody Scrum – lub, jeśli wolicie: celem projektu – są zespoły, które radykalnie poprawiają swoją wydajność. Przez dwadzieścia ostatnich lat tworzyłem je nieustannie. Byłem dyrektorem generalnym, szefem działu technologii lub szefem ds. inżynierii w dziesiątkach firm, od małych, wchodzących na rynek z kilkoma osobami w jednym pokoju, po duże przedsiębiorstwa, z biurami rozrzuconymi po całym świecie. Z setkami współpracowałem jako konsultant lub coach.
Rezultaty mogą okazać się spektakularne. Firmy prowadzące badania i analizy, takie jak: Gartner, Forrester Research i Standish Group, mówią obecnie, że dawny styl pracy jest przestarzały. W kurczowo trzymających się sprawdzonych, choć niedziałających idei, opartych na poleceniach i kontroli, próby narzucania sztywnej przewidywalności są po prostu skazane na niepowodzenie. Zwłaszcza gdy konkurencja korzysta z metody Scrum. Różnica jest zbyt wielka. Firmy oferujące kapitał inwestycyjny, takie jak OpenView Venture Partners w Bostonie, w której jestem doradcą, twierdzą, że Scrum oferuje taką przewagę konkurencyjną, że grzechem byłoby z niej nie skorzystać. Nie mówią tego dobroduszne osoby o niesprecyzowanych poglądach; to bystrzy ludzie finansów, którzy twierdzą po prostu: „Wyniki są bezdyskusyjne. Firmy mają dwa wyjścia: zmianę lub śmierć”.
–
Powyższy fragment pochodzi z książki pt. „SCRUM, czyli jak robić dwa razy więcej, dwa razy szybciej”. Autorem książki jest Jeff Sutherland, współtwórca Scrumu.
SCRUM, czyli jak robić dwa razy więcej, dwa razy szybciej
Jeff Sutherland
Wydawnictwo Naukowe PWN, 2015
Liczba stron: 240
