Scrum 97 rzeczy, które powinieneś wiedzieć - ebook

WSTĘP

Mam przyjemność przedstawić 97 esejów o Scrumie. Nie jest to książka do nauki Scruma. Oferuje raczej wgląd w zasady i role struktury Scruma oraz ich cele, a także pokazuje taktyki, strategie i wzorce do zastosowania, historie z frontu i niektóre aspekty Scruma, które… wykraczają poza Scrum.

Wprawdzie Scrum (który zadebiutował w 1995 roku) stopniowo stał się najczęściej przyjmowaną definicją Agile (które pojawiło się w 2001 roku), pozostaje wiele wyzwań ważnych dla praktyków Scruma. Nie tylko stoimy przed ciągłym zadaniem poprawiania wielu istniejących nieporozumień dotyczących Scruma – wciąż także szukamy najlepszych możliwych sposobów i kanałów dostarczenia informacji dla nowicjuszy oraz dla tych, którzy chcą lepiej rozumieć ramy postępowania w Scrumie.

Dzięki szerokiemu przyjęciu Scruma przez miliony praktyków na całym świecie, dostępne jest niezwykłe bogactwo wiedzy i prawdziwej eksperckiej praktyki. W tym samym czasie niezliczone osoby i organizacje szukają spostrzeżeń, porad i historii, a z drugiej strony praktycy mają nadzieję uzyskać głębsze zrozumienie. Ta książka aspiruje do tego, aby połączyć świat dojrzałych praktyków ze światem poszukującym rozwiązań.

Scrum jest znany z tego, że jest prosty, ale nie łatwy. Scrum to proste ramy postępowania, opracowane w celu sprostania trudnym wyzwaniom, których ważnym podzbiorem jest tworzenie złożonych produktów. Scrum pozostawia wiele miejsca na stosowanie różnych praktyk i taktyki i może obejmować wiele takich elementów. Czyż jest lepszy sposób niż zebranie i udostępnienie historii pochodzących od wiodących praktyków Scruma, aby przedstawić wiele kształtów, jakie może przybrać Scrum?

Dowiecie się tutaj, jak doświadczeni praktycy poradzili sobie z problemami i wyzwaniami oraz co ich zdaniem jest ważną rzeczą, o której musicie wiedzieć. Skorzystajcie z ich doświadczeń. Poprawcie swoje zrozumienie Scruma na podstawie ich spostrzeżeń. Zainspirujcie się, aby znaleźć swoją drogę w Scrumie, stosując, dostrajając i dopracowując sposoby korzystania z niego przez tych praktyków.

Wspólna wiedza wyrażona w tych 97 esejach reprezentuje niezwykłą różnorodność idei. Może się wam nie podobać każda z nich lub możecie zgadzać się ze wszystkimi. Możecie znaleźć sprzeczności, odmienne perspektywy i formy dwuznaczności. Witajcie w świecie złożoności, w którym Scrum pomaga nam nawigować: świat rzadko jest czarno-biały. Obyście znaleźli w nim wiele wartości, które pozwolą lepiej poruszać się w złożonej sytuacji.

Jak zbudowana jest ta książka

Poza ściganiem ludzi, zbieraniem i czytaniem esejów oraz dostarczaniem autorom sugestii edytorskich, cieszyłem się, szukając podobieństw i wspólnych tematów w miarę powstawania kolejnych esejów. Ta część mojej pracy, uporządkowanie esejów, zaowocowała pogrupowaniem ich w 10 tematów, Był to sposób na utworzenie pewnego przepływu w książce, choć na szczęście żaden esej nie ograniczał się do jednego tematu i każdy z nich można czytać oddzielnie.

Część I: Rozpocznij, przyjmij, powtórz

W części I znajdziecie 11 mniejszych i większych rzeczy wartych rozważenia i ponownego rozpatrzenia w waszej podróży do przyjęcia Scruma. Ponieważ przyjęcie Scruma to więcej niż jednorazowy wysiłek wprowadzenia go. Jest to ciągłe ćwiczenie myślenia, ponownego przemyślenia i odkrywania.

Część II: Produkty dostarczają wartość

W części II znajdziecie 11 rzeczy, które uwypuklają skupienie Scruma na produktach i usługach, oraz dlaczego wartość góruje nad wielkością. Ponieważ w złożonym świecie niestabilnych wymagać i wciąż zmieniających się technologii, „produkt” zapewnia minimalną formę stabilności, aby zorganizować waszą pracę ze Scrumem.

Część III: Kluczem jest współpraca

W części III znajdziecie 10 rzeczy, które tłumaczą, dlaczego Scrum polega na pracy zespołowej, gdzie komunikowanie się i interakcje są kluczowe. Ponieważ tworzenie, podtrzymywanie i ewolucja złożonych produktów i usług w złożonych i zmieniających się środowiskach wymaga zespołowej inteligencji, umiejętności i kompetencji.

Część IV: Rozwój to praca o wielu twarzach

W części IV znajdziecie 12 rzeczy, które stanowią przykłady, jak „rozwój” obejmuje wszelkie prace mające na celu tworzenie namacalnych, możliwych do pokazania, działających wyników nie później niż na końcu sprintu. Ponieważ rozwój złożonych produktów (często w skomplikowanych okolicznościach) wymaga więcej niż tylko mechanicznego tworzenia pracy (jak samo kodowanie lub programowanie).

Część V: Zdarzenia, a nie spotkania

W części V znajdziecie 10 rzeczy, które pomagają zrozumieć intencje współpracy i charakter zdarzeń w Scrumie i zobaczyć, że są one skupione na przyszłości, a nie na przeszłości, raportowaniu czy aktualizacji stanu. Ponieważ to, co zwykle nazywamy spotkaniami scrumowymi, to naprawdę są zdarzenia, które zapewniają określone możliwości inspekcji i adaptacji.

Część VI: Mistrzostwo ma znaczenie

W części VI znajdziecie 12 rzeczy dla osób, które chcą osiągnąć mistrzostwo w Scrumie, czego należy szukać i na co należy zwracać uwagę. Ponieważ mistrzostwo ma znaczenie nie tylko dla Scrum Masterów, chociaż są oni dość ważni jako mistrzowie ceremonii.

Część VII: Ludzie, zbyt ludzcy

W części VI znajdziecie 8 rzeczy, które podkreślają ludzką stronę pracy w Scrumie, poruszając nawet temat antropologii i neuronauki. Ludzie nie są zasobami (robotami, trybikami czy wymiennymi częściami maszyn). Ponieważ rozwój jest dokonywany przez ludzi, często jego wynikiem jest praca dla ludzi. A ludzie są… ludźmi.

Część VIII: Wartości są motorem zachowania

W części VIII znajdziecie 6 rzeczy, które są oparte na lepszym zrozumieniu, że Scrum to dużo więcej niż reguły. Scrum jest zaprojektowany jako niepełne ramy postępowania, zachęcające ludzi do angażowania się, komunikowania się i współpracy. Ponieważ Scrum jest strukturą reguł, zasad i… wartości. A wartości kierują zachowaniem.

Część IX: Projekt organizacyjny

W części IX znajdziecie 9 rzeczy zawierających punkty widzenia, praktyczne przypadki i lekcje dotyczące wpływu Scruma na struktury organizacyjne. Wprawdzie nie zawsze wiąże się to ze skalą, ale wpływ na organizację jest lepiej widoczny w dużych organizacjach. Ponieważ wprowadzenie Scruma nie jest możliwe bez wpływu na organizację i istniejące struktury organizacyjne.

Część X: Scrum poza protokołem

W części znajdziecie 8 rzeczy dotyczących Scruma, jego wykorzystania i potencjalnego użycia w taki sposób i w takich dziedzinach, które nie są z nim zwykle kojarzone, w tym trochę historii odwołujących się do korzeni, do czasów zanim zostało to nazwane Scrumem. Ponieważ praktycy Scruma pomagają kształtować jego przyszłość, potrzebujemy wyobraźni połączonej ze świadomością historyczną.

Na końcu książki znajdziecie słowniczek Scruma, który w najprostszy sposób podaje i tłumaczy terminy używane w tej książce.

W całej książce znajdziecie wiele cytatów z książki Scrum Guide (Przewodnik po Scrumie). Wszystkie pochodzą z wydania z listopada 2017 roku.

Podziękowania

Mam to szczęście, że jestem częścią wspaniałej rodziny, która inspiruje i motywuje mnie do tego co robię, niezależnie od tego, gdzie mnie to zaprowadzi. Bez mojej żony i trójki dzieci nie doszedłbym do niczego.

Jestem wdzięczny Martine Devos za skontaktowanie mnie z niektórymi wspaniałymi autorami, ale jeszcze bardziej za jej ciche zaufanie i zachętę. Znaczy to dla mnie wiele, gdyż Martine działa w świecie Scruma od jego wczesnych dni i zawzięcie go promuje.

W ciągu lat spędzony ze Scrumem pracowałem z wieloma ludźmi i organizacjami. Widziałem jak ludzie przychodzą i odchodzą. Dziękuję Hansowi Lindhoutowi za to, że jest wyjątkową osobą, u której napotkałem prawdziwą wzajemność biznesową i zdolność do wykraczania poza motywy komercyjne. Gdyby tylko było więcej ludzi takich jak on.

Nie mniej niż 68 praktyków poświeciło swój wysiłek, aby napisać dla was jeden lub więcej esejów o Scrumie. Nie zapraszaliśmy ich ze względu ich tytuły naukowe, zasługi czy pozycję. Zaprosiliśmy ich, gdyż mają cenne spostrzeżenia, którymi mogą się podzielić z innymi praktykami, takimi jak wy. Dziękuję każdemu z nich.

Dziękuję wam, Czytelnicy, za kupienie tej książki, ale jeszcze mocniej za stosowanie Scruma i dzielenie się tym, jak go wykorzystujecie, realizując wasze konkretne wyzwania. Dalej bądźcie inspiracją dla innych praktyków Scruma.

Ta książka nie powstałaby bez niesamowitego zespołu O’Reilly Media. Wielkie podziękowania dla wszystkim w to zaangażowanych, a zwłaszcza dla Chrisa Guzikowskiego i Ryana Shawa za zainicjowanie tego przedsięwzięcia oraz dla Corbina Collinsa za podtrzymanie go. Cieszcie się lekturą i… nadal stosujcie Scruma.

Gunther Verheyen
niezależny opiekun Scruma
Antwerpia, BelgiaPięć rzeczy, których nikt wam nie powie o Scrumie
Marc Loeffler

Myślicie o przekształceniu swego świata pracy, rozpoczynając stosowanie Scruma? Oto kilka rzeczy, których nikt wam wcześniej o Scrumie nie powiedział.

1. Scrum nie rozwiąże waszych problemów

Niektórzy mają nadzieję, że Scrum w sposób magiczny rozwiąże ich problemy, jakby to był cudowny środek. Ale procesy Agile, do których należy Scrum, przypominają bardziej teściową patrzącą wam cały czas na ręce: pokazują wszystkie wasze problemy i błędy, czyniąc je transparentnymi. W końcu to wy musicie je rozwiązać i wykonać całą ciężką pracę.

2. Scrum nie daje żadnych korzyści, jeśli działamy tylko zgodnie z procedurami

Widziałem zespoły Scruma, które postępowały dokładnie według zasad. Mieli codzienne spotkania, spotykania dotyczące planowania sprintów, robili przeglądy sprintu, retrospekcje, a nawet spotkania w celu ulepszenia rejestru produktu. Jednak korzyści, które uzyskiwali ze Scruma, były niewielkie, gdyż umknęło ich uwadze, że Agile dotyczy bardziej tego, żeby być niż, żeby robić. Przyjęcie zasad Agile wymaga zmiany sposobu myślenia, który towarzyszy zmianie procesu. Tylko ujęcie wszystkich 12 zasad stojących za Manifestem Agile i wartościami Scruma pozwoli rozwinąć pełny potencjał Scruma.

3. Nie ma „przełącznika Scruma”

Wysłanie wszystkich swoich pracowników na dwudniowe szkolenie certyfikacyjne Scruma nie wystarczy, aby firma stała się firmą scrumową. Nie ma przełącznika, który pozwoli przestawić firmę na „Scrum”, aby z dnia na dzień stała się Agile. Opisy procesu Scruma sprawiają, że wydaje się to łatwe, ale prawda leży gdzie indziej: przyjęcie Scruma jest trudne. Mamy wiele do nauczenia się: minimalizacja ilości potrzebnej pracy, eliminowanie istniejących spotkań, dostarczanie wersji gotowych do produkcji w każdym sprincie, podjęcie trudnych zagadnień organizacyjnych i wiele więcej. Możecie „przełączyć się” na Scrum, ale będzie to proces stopniowy – zajmuje to miesiące, a nawet lata i okazuje się nigdy nie kończącą się opowieścią.

4. Przejście na Scrum oznacza przekształcenie waszej organizacji

Większość inicjatyw, aby przejść w kierunku Agile zaczyna się przy rozwoju produktu, ale nie powinny tam pozostać. Jeśli reszta organizacji z zadowoleniem ignoruje inicjatywę, przypomina to sadzenie kwiatów na pustyni: powolne umieranie. Nie ma sposobu na wprowadzenie Scruma bez przekształcenia organizacji całości lub w części. Jeśli nie jesteście gotowi, aby się z tym zmierzyć, nie jesteście gotowi na Scruma.

5. Scrum nie jest szybszy

Choć termin „sprint” pozwala wnioskować, że Scrum jest szybki, to przynajmniej na początku zmieńcie swoje oczekiwania. Jeśli na koniec każdej iteracji chcecie mieć produkty gotowe do wypuszczenia na rynek, nie będziecie w stanie dostarczyć więcej w tym samym czasie. Scrum pomoże ma skrócić czas dotarcia na rynek, ale na różne sposoby:

• Scrum to stopniowe zwiększanie nieukończonej pracy. Skupiajcie się na tym, czego naprawdę potrzebują wasi klienci, zamiast tworzyć naszpikowane elementami produkty, których nikt nie potrafi użyć i które będą miały funkcje nikomu niepotrzebne. Prowadzi to oczywiście do krótszych (i jaśniejszych) rejestrów produktu i szybszego dostarczania, a więc w rezultacie skraca czas dotarcia na rynek.

• Scrum polega na tworzeniu od samego początku w dobrej jakości. To pomoże wam stworzyć miejsce na tworzenie innowacyjnych funkcji zamiast tracić czas i energię na niekończące się poprawianie błędów. Zmniejszy się także ogromnie czas potrzebny na utrzymanie.Mentalność ma większe znaczenie niż praktyka
Gil Broza

Czy wasz codzienny Scrum robi wrażenie spotkań organizacyjnych?

Czy menedżerowie i interesariusze traktują rejestr produktu jako plan projektu?

Czy Scrum Master przede wszystkim zarządza zadaniami i zapewnia zgodność procesu?

Jeśli odpowiedzieliście „tak” na te trzy pytania, to mogę odgadnąć inne symptomy waszego Scruma. Retrospektywy zespołów nie przynoszą dużej poprawy. Członkowie mało ze sobą współpracują i nie ma wspólnej, solidnej definicji „zrobione”. Jeśli wasz zespół opracowuje oprogramowanie, to ma dość niskie pokrycie automatycznymi testami i pobieżnie (i rzadko) refaktoryzuje kod, a wdrażanie do produkcji wymaga wiele planowania i uwagi. Podczas gdy wydaje się, że podążacie według praktyk, zapewne nie macie zbyt dużej zwinności. Dlaczego tak się dzieje?

Aby zrozumieć sytuację, musimy wiedzieć dlaczego zespoły Scruma używają określonych praktyk, spotkań, ról i artefaktów. Zobaczmy najpierw, jakie zasady wchodzą w grę, gdy taktyka ta jest stosowana efektywnie.

Weźmy pod uwagę codzienny Scrum. Jest on z punktu widzenia Agile najbardziej efektywny, gdy członkowie zespołu współpracują i samoorganizują się w celu wykonania pracy, która ma znaczenie. Czują się psychicznie bezpieczni, będąc przejrzyści i biorąc udział w sposób pełny i uczciwy.

Rejestr produktu (Product Backlog) to uporządkowana lista potencjalnie wartościowych prac. Gdy tak jest traktowany, ten prosty artefakt skupia pracę zespołu na znaczących rezultatach. Mogą oni łatwo stwierdzić, że są skuteczni i odłożyć wiele decyzji związanych z elementami pracy, takich jak szczegóły, podziały i testy akceptacji na ostatni właściwy moment.

Scrum Master jest przywódcą służebnym, który pomaga zespołowi rozwinąć się w solidny zespół Agile. Osiągają oni ten cel, tworząc środowisko bezpieczeństwa, zaufania i szacunku dzięki podtrzymywaniu komunikacji, współpracy i przejrzystości.

Scrum wdraża wyżej wymienione zasady (i kilka innych), gdyż wspomagają one cztery wartości Agile: adaptację, częste dostarczanie wartości, współpracę z klientem i stawianie ludzi na pierwszym miejscu. Ludzie przyjmują te wartości – „optymalizują je” lub traktują jako przewodnik we wszystkim co robią – gdy wierzą, że w ten sposób osiągną swoje cele. Wartości i zasady, wraz z przekonaniami, to trzy elementy mentalności.

Gdy organizacja przyjmuje Scruma, ma już jakąś ustaloną mentalność. Ponieważ organizacje startują z różnych punktów, ich mentalność ma nieco podobieństw, które można określić jako „tradycyjne”. Ich wartości zwykle obejmują: dostarczanie od razu poprawnych elementów, wczesne podejmowanie zobowiązań, dostarczanie na czas i w ramach budżetu oraz przestrzeganie standardów. Działają na rzecz tych standardów za pomocą takich zasad jak: planuj pracę i działaj zgodnie z planem, ograniczaj zmiany i wymagaj podpisów zatwierdzających. Ustalają prace centralnie, mają „zasoby” (ludzi) przekazujących pracę jedni drugim i maksymalizują ich wykorzystanie. Przed Scrumem wdrażali te zasady za pomocą takiej taktyki jak plany projektu, procent wykonania, częste spotkania i ustalone kody. Co dzieje się, gdy taka organizacja zastępuje dotychczasową strategię taktyką Scruma bez zmiany mentalności, jaka ją ukształtowała.

Planuj pracę, ograniczaj zmiany i maksymalizuj wykorzystanie sprawiają, że codzienny Scrum staje się spotkaniem dotyczącym stanu, które sprawia że każdy jest obciążony: centralne ustalanie pracy powoduje, że staje się to serią wymian jeden na jednego ze Scrum Masterem. A ponieważ bezpieczeństwo i przejrzystość nie pojawiają się magicznie w wyniku codziennych spotkań zespołu, ludzie będą składać długie sprawozdania o tym, jak są zajęci w odpowiedzi na pytanie „Co zrobiliście od wczoraj?” i będą niechętnie odpowiadać na „Jakie są przeszkody?” stwierdzeniem „Utknąłem i potrzebuje pomocy”.

Podobnie mentalność organizacji będzie wpływać na każdą praktykę w Scrumie, rolę, spotkanie i artefakt. Im bardziej ta mentalność jest odległa od tej w Agile, który jest podstawą Scruma, tym bardziej osłabia ona taktykę Scruma, pozostawia członków zespołu zdezorientowanych i rozczarowanych oraz zmniejsza rzeczywista zwinność. Aby osiągnąć prawdziwą zwinność, skupcie się na mentalności – ma ona znacznie większe znaczenie niż praktyki.To naprawdę nie jest o Scrumie
Stacia Viscardi

Scrum wydaje się być prostą kreacją, która mówi nam między innymi, jak wykonywać sprinty, tworzyć wykresy spalania i definiować „zrobione”. Przypomnijcie sobie, jak czytaliście zwroty o Scrumie takie jak: „Scrum jest łatwy z wierzchu, ale trudny do wdrożenia”. Jest tak dlatego, że na wierzchu fasada Scruma jest prosta, jak dokładnie ułożone cegły. Jednak gdy pokopiemy trochę głębiej, znajdziemy sękate, pokręcone korzenie zarządzania złożonymi i chaotycznymi sytuacjami, kamień węgielny ludzi i motywacji oraz pozostałości podstaw podejścia „Lean”. Są jak starożytne akwedukty biegnące pod nowoczesną ulicą. Scrum jest ostatecznie balkonem, z którego możemy oglądać rzeczywistość, jakakolwiek by ona była, aby ludzie mogli podejmować lepszej jakości decyzje na podstawie nowszych i poprawionych wersji tej rzeczywistości.

Jakiś czas temu napisałem tweeta, że „Scrum jest testem integracji systemu, sprawdzającym czy jest możliwe, aby organizacja dostarczyła wartość w sprincie. Ten test ujawnia wady systemu lub przeszkody, które następnie trzeba usunąć”. Te „błędy” – wyboje na drodze, przeszkody – stanowią klucz do tego, co ogranicza zdolność organizacji do dostarczenia tego, co jest naprawdę istotne: funkcjonalności, która sprawi, że użytkownicy, klienci i/lub rynek będą szczęśliwi.

Nagle zaczynacie wdrażać Scruma, tego demaskatora rzeczywistości, ten wielki test, i nie jest zaskoczeniem, że napotykacie pewien sprzeciw. Podobnie jak w projektach kaskadowych, deweloperzy niechętnie przekazują kod testerom po koszmarnym kamieniu milowym „zamrożenia kodu”. Zespoły i organizacje nie są chętnie, by dowiedzieć się, co mogą odkryć, gdy przekazują rzeczywistą sytuację do przejrzystego testu o nazwie sprint.

Praktykowanie Scruma jest także utrudnione przez jego wpływ na strukturę podejmowania decyzji w organizacji. Teraz właściciel produktu jest odpowiedzialny za co i dlaczego, zespół tworzący odpowiada za to jak i jak szybko następuje dostarczenie, a Scrum Master ma rolę facylitatora i „ujawniającego przeszkody”. Te role i proste mechanizmy zostały utworzone po to, aby złożone projekty mogły być realizowane sprint po sprincie i aby „tworzenie oprogramowania stało się znów zawodem”, w którym ludziom można ufać i ich szanować, a więc mogliby odkrywać rozwiązania i ostatecznie poczuć się dumni ze swej pracy. Scrum to ramy postępowania, które powstały przede wszystkim z myślą o ludziach. Jest to nierozerwalnie związane z jego pięcioma wartościami i jest często trudne do uchwycenia dla tradycyjnie myślących menedżerów, gdy wierzą oni fałszywie w metodologię, jako tę, która „zrywa łańcuchy”.

Właśnie dlatego twierdzę, że nie chodzi tu tak naprawdę o Scruma. Chodzi o używanie struktury do odkrycia tego, co wcześniej nie było znane. Zacznijcie więc i przyjmijcie to, co zostaje wam ujawnione. Stosujcie granice priorytetyzacji, podział na odcinki czasowe i role, aby pomóc zespołowi i organizacji zrozumieć to, co odkryli. Strach ludzi przed porażką i nieznanym utrudnia czasami poprawne działanie. Organizacji nie jest łatwo pogodzić się ze swoimi porażkami i mam nadzieję, że wraz z upływem czasu, dzięki stosowaniu Scruma lub inne metody empirycznej, poprawią się w tym działaniu, co będzie istotną częścią ich podróży ku odkryciom.Scrum jest prosty Stosujcie go takim, jaki jest
Ken Schwaber

Scrum jest mentalnością: podejście do przekształcenia złożonych, chaotycznych problemów w coś, co można stosować. Razem z Jeffem Sutherlandem oparliśmy go na następujących filarach:

1. Małe, samoorganizujące się, samozarządzające zespoły

2. Szczupłe (lean) zasady

3. Empiryzm, używanie ciągłych inspekcji i adaptacji do kierowania pracą zespołów, aby uzyskać najlepszy możliwy rezultat

Scrum Guide jest zasobem wiedzy, który wyraźnie definiuje, czym jest Scrum (i, domyślnie, czym nie jest). Scrum Guide nie mówi wam, jak używać Scruma, jak go wdrażać ani jak budować za jego pomocą produkty.

Ludzie uczyli się, czym Scrum jest i jak go używać, na kursach, jeżdżąc na konferencje, czytając książki i blogi i temu podobne, ale przede wszystkim próbując tworzyć użyteczne rzeczy na podstawie wizji, pojęć i chęci, wykorzystując swoje zrozumienie Scruma. Gdy w to wchodzili, Scrum zaczynał mieć sens. Scrum pomógł im zarządzać rezultatami. Jednak gdy ludzie próbowali używać Scruma, dowiedzieli się, że trudność Scruma polega na osiąganiu wspólnego pojmowania tego, co jest pożądane, co jest możliwe i co ich umiejętności pozwolą im stworzyć we wspólnej pracy przy wkładaniu maksymalnego wysiłku.

W roku 2009 doszedłem do wniosku, że przełamaliśmy formę kaskadową. Ludzie zrozumieli (w dużej mierze), że nasze „zwinne, lekkie” podejście działa i jest odpowiednie przy pojawiającej się złożoności świata. Jednak, podobnie jak w próbach kontaktu za pomocą poczty głosowej, było wiele interpretacji Scruma. Czasami chodziło o wadliwą komunikację, niewłaściwe pouczanie lub inne przyczyny komercyjne. Ludzie, którzy czuli, że Scrum powie im jak budować produkt, aby zaspokoić ich potrzeby, czuli słabość Scruma, ponieważ nie mówił im wprost, jak to zrobić.

Dokładnie tak. Jak często mówiłem, Scrum jest łatwy. Rozwiązywanie problemów za pomocą Scruma jest bardzo trudne.

W roku 2009, gdy założyłem Scrum.org, napisałem definicję Scruma. Była ona krótka, ale zawierała wszystko, co wynikało z ważnych przemyśleń i nauk moich i Jeffa. Sprawdziłem, że zachowuje tożsamość Scruma jako ram postępowania i wystrzega się włączania opinii, praktyk zależnych od kontekstu i czegokolwiek, co ograniczałoby go do jednego konkretnego zastosowania. Ramy postępowania, a nie metodologia.

To był pierwszy Scrum Guide i był to zdecydowanie zasób wiedzy (body of knowledge). Wszystko, co nie znalazło się w przewodniku lub nie było z nim zgodnie, nie było Scrumem. Jeff Sutherland przyłączył się do mnie, aby go udoskonalać, wspierać i utrzymywać.

Scrum Guide powstał w wyniku pracy mojej i Jeffa oraz wszystkich tych, którzy próbowali korzystać ze Scruma. Od tego czasu poprawiliśmy go. Scrum Guide nie ma celów komercyjnych poza oferowaniem papierka lakmusowego do sprawdzenia, czym jest Scrum. Wraz Jeffem mamy dług wobec ludzi, którzy przetłumaczyli przewodnik, i tych, którzy pomagają nam go utrzymać.

Pamiętajcie: Scrum jest prosty. Przestańcie się martwić o udoskonalanie go, aby się stał idealny, gdyż nigdy taki nie będzie. W każdym razie na świecie jest zbyt wiele złożonych, chaotycznych sytuacji, w których wasze umiejętności pomogą innym działać. Nie musimy marnować naszego czasu, patrząc na swój własny pępek.Zacznijcie Scruma od pytania „dlaczego”
Peter Goetz i Uwe Schirmer

„Czy jest to poprawne według Scruma?” – to pytanie, które wciąż nam zadają. Zwykle następuje potem opis konkretnej praktyki zespołu, a osoba zadająca pytanie chce wiedzieć, czy stosują Scrum poprawnie (tj. zgodnie ze Scrum Guide).

Wprawdzie pytanie jest poprawne, próbujemy zrozumieć dlaczego zostało zadane. Zespoły i organizacje często skupiają się na mechanizmach Scruma i zapominają o swoim prawdziwym celu, którym zwykle jest wygenerowanie i zwiększenie wartości dla klientów, interesariuszy i ich samych.

Nie zrozumcie nas źle: Scrum Guide jest dla nas ważny. Opisuje podstawowe elementy rozwiązywania złożonych problemów adaptacyjnych i jak one ze sobą współgrają. Traktujemy to poważnie, gdyż pomaga nam skupić się na wspólnym i kreatywnym rozwiązywaniu naszych problemów – na czymś, co wykracza poza samo czytanie i stosowanie Scrum Guide.

Jest jeden powód istnienia Scruma: „dostarczenie możliwego do wypuszczenia przyrostu ‹‹zrobionego›› produktu na końcu każdego sprintu”. Wspomagają to wszystkie elementy Scruma. Role dzielą i współdzielą odpowiedzialność ludzi zaangażowanych w pracę. Artefakty tworzą minimum przejrzystości potrzebnej do iteracyjnego i przyrostowego dostarczania przyrostu możliwego do wypuszczenia. A zdarzenia są okazją do inspekcji i adaptacji zgodnie z informacjami zebranymi w artefaktach i tworzą rytm informacji zwrotnych w różnych obszarach zainteresowania. Ten rytm poprawia przepływ pracy zespołu Scruma. Wartości Scruma opisują wspólną mentalność, która jest niezwykle pomocna, gdy ciągle oceniamy i poprawiamy nasz sposób wspólnej pracy.

Możecie mechanicznie przestrzegać reguł opisanych w Scrum Guide. Możecie wyznaczyć właściciela produktu, Scrum Mastera i zespół deweloperski. Zorganizować sprint i zaprosić zespół (a czasami też interesariuszy) do udziału w zdarzeniach. Ustawiacie narzędzie do zarządzania rejestrem produktu i rejestrem sprintu i mówicie zespołowi Scruma, aby zaczęli działać. Jeśli dlaczego u podstaw Scruma nie jest zrozumiałe i żywe, nie nastąpi żadna poprawa. Zespół Scruma może nawet zdenerwować się tą nową grą, nie widząc sensu w regułach. W najgorszym przypadku wypalają się przez stres, który nowe elementy wnoszą w porównaniu ze starym sposobem pracy.

Dlatego sugerujemy inne podejście. Zachęcamy organizacje, aby najpierw porozmawiały o swoich wyzwaniach i o tym, w jakich miejscach bieżąca strategia nie pomaga lub musi zostać poprawiona. Możemy potem pomyśleć o sposobach przezwyciężenia tych ograniczeń i zbadania, jak Scrum może w tym pomóc. Tylko wtedy ma sens rozpoczynanie wprowadzania Scruma.

Dwa pytania powinny być Gwiazdą Polarną w tej niekończącej się podróży:

1. Czy potrafimy dostarczyć wartościowy i możliwy do wypuszczenia przyrost produktu w każdym sprincie?

2. Jak możemy poprawić nasz sposób wspólnej pracy?

Te pytania odwracają uwagę od czystej mechaniki Scruma. Uczymy się, jak ich używać do uzyskania jaśniejszych celów i problemów. Będziemy wciąż doskonalić swoje umiejętności i narzędzia, aby robić postępy w realizacji tych celów. To spowoduje wzrost naszej motywacji i doprowadzi do większego szczęścia i humanizacji miejsca pracy.

I – najprawdopodobniej – nadal będziemy pracować zgodnie ze Scrum Guide. Nie dlatego, że tak jest w nim napisane, ale dlatego, że ma to sens.Adoptuj, zanim zaadaptujesz
Steve Berczuk

Scrum stanowi dość minimalne ramy postępowania, które adaptujecie tak, aby działały najlepiej w waszym zespole. Czasami zespoły przyjmujące (inaczej adoptujące) Scruma próbują rozszerzyć ideę na adaptację i „adaptować” proces Scrum tak, że staje się po prostu fasadą dla istniejącego (często tradycyjnego) procesu. Adaptacja udaje się najlepiej wtedy, gdy zespół ma wewnętrzne zasady i wartości procesu Scruma. Zrozumienie innego sposobu pracy wymaga praktyki i doświadczenia.

Popularnym przykładem przedwczesnej adaptacji podczas przyjmowania Scruma polega na tym, że zespół przyjrzy się zdarzeniom w Scrumie i zdecyduje, że nie sprawdzą się w ich przypadku. Spotkania związane z planowanie sprintu zostają skrócone lub nie obejmują całego zespołu, co w rezultacie daje rejestry sprintu, które zawierają więcej pracy niż, jak wynika z wcześniejszych doświadczeń, zespół może udźwignąć. Codzienne spotkania scrumowe stają się spotkaniami dotyczącymi postępów – lub, co gorsza, inne takie spotkania nie zostają osunięte z harmonogramu. Spotkania związane z oceną sprintu i retrospektywą odbywają się w pośpiechu lub są pomijane. Krótko mówiąc, można mieć zdarzenia z oficjalnymi nazwami, ale nie są one wypełnione wartościami Scruma. To zły pomysł, gdyż w najlepszym razie spowoduje, że zespół nie zyska ze Scruma żadnej wartości, a w najgorszym – da gorszą wydajność, ponieważ podejścia pozorne lub hybrydowe wprowadzają niepotrzebne koszty ogólne.

Powody, dla których to się zdarza, zmieniają się zależnie od organizacji, ale w grę niemal zawsze wchodzą dwa czynniki. Przede wszystkim, każda zmiana jest trudna i wymaga pracy i nauki, a w chwilach stresu ludzie łatwo wracają do starych, znanych zachowań. Ponadto Scrum jest łatwy do nauczenia się, ale trudno dobrze go opanować. Scrum to coś więcej niż samo organizowanie zdarzeń Scruma. Każdy członek zespołu musi być zdyscyplinowany, aby robić wszystko, co w jego mocy, co może pomóc w dobrym działaniu procesu.

Przyjmijcie (adoptujcie) praktyki Scruma, zanim je zaadaptujecie. Praktyka pomoże wam zrozumieć i przyswoić nowy sposób pracy. Opierajcie się pokusie dostosowywania Scruma do czasu, gdy zespół będzie rozumiał, jak jego praktyki dodają wartość i będzie wspierać zasady Scruma. Postępujcie zgodnie z zasadami Scruma „według książki” (dosłownie, korzystając ze Scrum Guide’a lub, jeśli potrzebujecie więcej wskazówek, z jednej ze świetnych książek na temat Scruma), przez co najmniej trzy do pięciu sprintów. I zostawcie czas na retrospektywy sprintów. Wykorzystajcie retrospektywy do zbadania, jak proces wpłynął na współpracę i dostarczenie produktu, dając możliwość odczuwania satysfakcji w miarę jak ludzie dostrzegają zachowania, które umożliwiają ramy postępowania Scruma.

Jeśli naprawdę wierzycie, że rozumiecie wartości Scruma, możecie go adaptować od razu. Ponieważ Scrum jest całkiem innym sposobem pracy niż ten, do którego przyzwyczajona jest większość organizacji, większość zespołów potrzebuje praktyki, aby zrozumieć wartości jego praktyk. Choć nie jest to niezbędne do pomyślnego przyjęcia Scruma, najlepiej jest mieć dobrą podstawę do adaptacji.Regularnie wracajcie do najprostszych rzeczy, które mogą zadziałać
Todd Miller

Uproszczenie prowadzi do bogatszych rezultatów

Yvon Cgouinard

Wiele lat temu odszedłem z pracy, gdzie byłem Scrum Masterem, aby pełnić tę samą funkcję w innej firmie. Pozostawiłem doskonały zespół Scruma. Świetnie pracowali ze sobą, rozwijali się w zakresie stosowania Scruma, wdrożyli praktyki, które się doskonale sprawdzały i tworzyli świetny produkt. Ale ja byłem gotów na nowe wyzwanie.

Stałem się częścią nowego zespołu Scruma, który miał stworzyć nowy produkt. W pierwszych dniach pracy jako zespół spędziliśmy sporo czasu, dyskutując o Scrumie. Pomogło nam to uzyskać wspólne zrozumienie i zacząć używać tego samego języka podczas wzajemnego poznawania się. Wszyscy byli zaangażowani i podzielali entuzjazm do wykorzystania Scruma przy budowanie nowego, złożonego produkt.

W międzyczasie powstał wystarczający rejestr produktu, abyśmy czuli się swobodnie, rozpoczynając pierwszy sprint. Przed nim mieliśmy jeden dzień na rozkręcenie się jako zespół. Skrupulatnie zaplanowałem porządek obrad na ten dzień, wraz ze współdzieleniem i promowaniem praktyk, które uważałem za odpowiednie dla nas. Chciałem przenieść spostrzeżenia i lekcje z mojego poprzedniego zespołu Scruma do tego nowego. Dołożyłem wszelkich starań, aby wszystko poskładać i ułatwić ten dzień intensywnej współpracy.

Pierwsze sesje poszły nieźle. Zespół Scruma omawiał bieżący rejestr produktu, sprawdzając, czy praca zaplanowana na kilka pierwszych sprintów była dobrze zrozumiana i utworzył definicję pojęcia „zrobione”, która była więcej niż tylko wystarczająca na początek. Ale gdy wprowadziłem kolejny temat – tworzenie porozumienia dotyczącego pracy zespołu – sprawy zaczęły przyjmować dziwny obrót. Członkowie zespołu zaczęli pytać, dlaczego to jest potrzebne. W końcu pierwszy tydzień współpracy przebiegał dobrze, Ponieważ poczułem w sali szybko rosnące napięcie, odłożyłem ten pomysł i przeszedłem do kolejnego punktu agendy. Ku memu zdziwieniu napotkałem podobny opór i – co gorsza – rósł on wraz z każdym kolejnym punktem, nad którym chciałem pracować.

Potem nagle zadano mi pytanie, na które nie byłem przygotowany: „Dlaczego tak wszystko komplikujesz?”. Moją jedyna odpowiedzią było: „Te praktyki sprawdzały się w mojej poprzedniej pracy”. To nie było satysfakcjonujące nie tylko dla zespołu, ale nawet bardziej dla mnie samego. Poczułem się niezręcznie, ale zdecydowałem się porzucić mój plan, moje ambicje, na dzień rozpoczęcia i zadeklarowałem, że jesteśmy gotowi do pierwszego sprintu.

Choć na początku byłem zdziwiony, cała sytuacja zmieniła się dla mnie w ważną lekcję. W złożonej dziedzinie pracy nie ma gwarancji, że to co działa w jednej sytuacji, będzie działać w innej. Mój nowy zespół Scruma zaczął wykonywać wspaniałe rzeczy, odkrywając i zmieniając w trakcie pracy swoje praktyki.

To doświadczenie nadal działa jako przypomnienie, że w złożonej pracy najważniejszy jest empiryzm: proces częstego sprawdzania i adaptowania przy zapewnieniu przejrzystości. Empiryzm rozciąga się w Scrumie poza samo odkrywanie możliwości produktu w zakresie praktyk stosowanych w Scrumie. Nie dotyczy to jedynie nowych zespołów Scruma. Istniejące zespoły często znajdują się w otoczeniu tylu uzupełniających praktyk, że wpływa to negatywnie na ich zdolność do wejrzenia w głąb (inspekcji), zmiany kierunku (adaptacji) lub ujawniania wszystkich spraw (przejrzystość).

Często sprawdzajcie, czy praktyki używane przez was w waszym Scrumie dalej mają sens i czy optymalizują wasz empiryzm, a nie są dla niego przeszkodą.Czy Scrum będzie działał w pracy prowadzonej w wielu lokalizacjach?
Pete Deemer

Uwaga, spojler! Tak! Scrum świetnie działa w pracach prowadzonych w różnych lokalizacjach! Jednak Scrum to nie jest cudowny środek, dzięki któremu wszystko działa magicznie.

Scrum to bardzo prosty zbiór praktyk, które razem tworzą duży stopień przejrzystości, pokazując nam wyraźniej realia naszej sytuacji. Scrum tworzy przejrzystość wokół tego, co jesteśmy w stanie zrobić w ciągu jednego do czterech tygodni. Scrum pozwala nam jasno dostrzec jakość i poprawność tego, co zrobiliśmy i ile udało nam się skończyć. Scrum konfrontuje nas z efektywnością naszych praktyk, w tym z wzorcami dysfunkcji i popełnianymi błędami. Najważniejsze jest to, że Scrum daje nam możliwość wykorzystania tych spostrzeżeń do poprawy w następnym sprincie. Tak więc stwierdzenie „Scrum świetnie działa w pracy prowadzonej w wielu lokalizacjach!” oznacza, że Scrum jest świetny w jasnym pokazywaniu nam wszystkich dysfunkcji i braków efektywności, których doświadczamy. A rozproszone projekty mają ich zwykle wiele!

U podstaw rozwoju oprogramowania leży działanie, która wykorzystuje wytwór ludzkiej myśli i logicznego rozumowania i sprawia, że staje się to powtarzalne w postaci kodu. Dla zespołu tworzącego oprogramowanie ich zdolność do łączenia swoich myśli dzięki wspólnemu zrozumieniu, współpracy i komunikacji, stanowi kluczową siłę napędową rezultatów. W projektach prowadzonych w wielu lokalizacjach zadanie to jest najtrudniejsze ze względu na mierzenie się z wieloma postaciami rozproszenia: rozdzieleniem fizycznym, rozdzieleniem wynikającym ze stref czasowych, rozdzieleniem kulturalnym i językowym oraz trudnościami, które pojawiają się wraz z barierami językowymi i kulturowymi. Pierwszy sprint zrealizowany w wielu lokalizacjach będzie zapewne bogatym kręgiem dysfunkcji – i prawdopodobna konkluzja będzie brzmieć „to po prostu nie działa”. Uświadomienie sobie tego jest pierwszym ważnym krokiem na drodze do sukcesu. Kolejny krok to wyliczenie wszystkiego, co nie działało dobrze i sformułowanie działań, które sprawią, że w kolejnym sprincie wyjdzie to lepiej.

Na przykład w pierwszym sprincie może się okazać, że przyrost produktu nie jest zgodny z definicją „zrobione”. W retrospektywie sprintu zespół Scruma identyfikuje podstawowe przyczyny, takie jak brak jasnego wspólnego zrozumienia celu sprintu, brak komunikacji w ramach zespołu prowadzący do braku koordynacji oraz brak zaufania między członkami zespołu. W wyniku tego w drugim sprincie podejmowane są działania (pomysły możecie znaleźć w artykule Distributed Scrum Primer) i sprint ten daje nieco lepsze wyniki. Często zdarza się, że w kolejnych sprintach widoczne stają się inne zestawy problemów i za każdym razem identyfikowane są całe nowe zestawy ulepszeń. Zespół Scruma stopniowo ewoluuje, ze sprintu na sprint, w kierunku coraz lepszego sposobu pracy.

Czy Scrum „magicznie” sprawi, że każdy rozproszony zespół stanie się skuteczny? Nie. W istocie żadna metodologia nie ma takiej zdolności, choć niektóre to obiecują. Radykalną innowacją Scruma jest zawarta w nim idea odrzucenia metodologii opartej na ścieżce do sukcesu. W to miejsce Scrum daje proste ramy postępowania zbudowane wokół inspekcji i adaptacji, które tworzą ciągłą przejrzystość wokół niepowtarzalnego środowiska i cech danej sytuacji, tworząc jednocześnie okazję do ulepszeń. Jedynym pytaniem jest, jak bardzo odważne działania zespół chce i potrafi przyjąć!Poznaj różnicę między wieloma zespołami Scruma a Scrumem wielozespołowym
Markus Gaertner

Gdy stosujemy Scrum do produktu tworzonego przez więcej niż jeden zespół deweloperski, Scrum Guide da nam niewiele wskazówek, gdyż skupia się on na Scrumie jednozespołowym. Jedyną wskazówkę znajdziecie w części poświęconej rejestrowi produktu:

Często nad tym samym produktem pracuje razem wiele zespołów Scruma. Jeden rejestr produktu jest używany do opisania nadchodzącej pracy nad produktem. Można wtedy zastosować atrybut rejestru produktu, który grupuje elementy.

Dowiadujemy się, że przy wielu zespołach powinniśmy nadal używać jednego rejestru produktu. Nie ma mowy o rolach właściciela produktu, zespołu deweloperskiego ani Scrum Mastera, poza tym, że „wiele zespołów Scruma” pracuje nad tym samym produktem.

Ale jak będziecie decydować o priorytetach? Jeśli potraktujemy Scrum Guide dosłownie, mógłby być więcej niż jeden właściciel produktu, w każdym zespole Scruma pracującym nad produktem lub też może to być jedna osoba dla wszystkich zespołów zaangażowanych w pracę. Ogólnie jest to rozróżnienie między „wieloma zespołami Scruma” a „Scrumem wielozespołowym”.

Wiele zespołów Scruma

To określenie zwykle oznacza, że każdy zespół deweloperski ma swojego właściciela produktu, choć istnieje jeden rejestr produktu. Oznacza to, że potencjalnie różni ludzie w roli właściciela produktu muszą koordynować ze sobą swoje priorytety i dojść do najbardziej wartościowych elementów wypracowanych dla tego produktu.

Czasami taki układ może być połączony z różnymi specjalizacjami zespołów deweloperskich, gdzie różne zespoły pracują w określonych obszarach działania produktu. To się sprawdza, jeśli nakład pracy na każdy ze specjalistycznych tematów jest równo rozłożony między różne zespoły – i będzie tak w najbliższej przyszłości. Jeśli jest inaczej (co jest bardzo prawdopodobne), to jeden zespół może pracować z niższym priorytetem pracy, a więc na niższą wartość produktu tylko dlatego, że dany rodzaj pracy jest ich specjalnością.

Taki układ zmniejsza ogólne przejrzystość i wgląd w całość produktu. Nie tylko chodzi o to, że dogłębna wiedza o produkcie jest podzielona między różne zespoły Scruma, lecz także między różnych właścicieli produktu. Po zakończeniu pracy nad określonymi funkcjami potrzebna jest dodatkowa koordynacja różnych wyników częściowych produktu, aby zintegrować je w cały produkt, który może zostać przekazany klientowi i użytkownikowi. Niestety ustawienie „wiele zespołów Scruma” daje niewiele bodźców do współpracy międzyzespołowej, gdyż wszystko zostanie załatwione w ramach dodatkowej koordynacji związanej z tym układem.

Scrum wielozespołowy

W takim ustawieniu mamy nie tylko jeden rejestr produktu, lecz także jednego wła- ściciela produktu, który pracuje z wieloma zespołami deweloperskimi. Jeden właściciel produktu podejmuje decyzje dotyczące całego produktu i są one w pełni przejrzyste w ramach jednego rejestru produktu i tworzonych wersji produktu.

To ustawienie wymaga więc koordynacji między samymi zespołami. Może nadal istnieć specjalizacja w dziedzinie klienta, ale będzie musiała się ona rozmyć, gdy priorytety i zapotrzebowanie zaczną się zmieniać. Na przykład jeden zespół pracujący nad funkcją księgowości będzie musiał przejść od funkcji księgowania do innego rodzaju funkcji, jeśli w rejestrze produktu nie ma już funkcji księgowych o najwyższym priorytecie

To ustawienie powoduje wymaganie koordynacji między samymi zespołami. Muszą one mieć pewność, że na koniec każdego sprintu dostarczą zintegrowany przyrost produktu.

Zależnie od punku wyjścia może to dać w rezultacie stromą krzywą uczenia się. Warto to zrobić.Co zdefiniujecie jako „zrobione”?
Gunther Verheyen

Zespoły i organizacje chcą zarabiać na możliwościach biznesowych i rynkowych. Scrum oferuje tę opcję, zapewniając przyrost „zrobionego” – tj. możliwa do wypuszczenia wersja produktu jest dostępna nie później niż na końcu każdego sprintu. Ponieważ sprint zajmuje nie więcej niż cztery tygodnie (a często mniej), organizacja może dotrzeć szybciej na rynek, wygrać szansę i wygenerować wartość.

Bez wyraźnego określenia, co zawiera w sobie „zrobione”, Scrum nie może być skutecznie zastosowany. Dzięki definicji „zrobionego” każdy rozumie, co oznacza to określenie. Jest to niezbędne, gdy rozważamy oportunistyczną wartość cech produktu oferowaną w ramach przyrostu. Definicja „zrobionego” zapewnia także zespołowi deweloperskiemu jasność przy prognozowaniu pracy uznanej za wykonalną w sprincie. Przez cały sprint definicja „zrobionego” kieruje nim przy ocenie, czy praca na elementach rejestru produktu i przyrost produktu jest zakończona.

Profesjonalna organizacja wypuszcza jedynie „zrobione” przyrosty. Specjaliści Scruma trzymają się definicji „zrobionego”. Zawsze. Żadna „niezrobiona” praca nie będzie częścią przyrostu. Żadna „niezrobiona” praca nie zostanie wdrożona do produkcji. Nigdy. Zaangażowani specjaliści wyrażają opinię o sposobach poprawy jakości produktu w sposób odzwierciedlany w definicji „zrobionego”.

Wydaje się, że wiele zespołów na całym świecie nie potrafi tworzyć przyrostów produktu, które naprawdę nadają się do wypuszczenia. Kod jest wprowadzany i ewentualnie testowany w ramach zespołu. Ale rzeczywisty przyrost pozostaje rozproszony i ukryty w długowiecznych oddziałach. Lub praca dostarczana ma końcu sprintu musi być jeszcze zintegrowana z pracą innych zespołów. Lub też – co gorsza – musi być w tym celu wysłana do innego wydziału. W tych przypadkach Scrum pokazuje, że mamy do czynienia z ważną dysfunkcją organizacyjną wpływającą na zwinność organizacji. Jest duża ilość „czasu na niezrobione”: czasu, który zabiera przejście od niezrobionej części pracy do przyrostu „zrobionego”. Te marnotrawne opóźnienie zabija możliwość korzystnego finansowo wypuszczenia na rynek.

Celem sprintu w Scrumie nie jest jedynie zrobienie czegoś, co można dostarczyć innemu zespołowi, grupie funkcjonalnej lub wydziałowi. Przyrost powinien być w stanie użytkowym, gotowy do produkcji. Przyrost powinien przynajmniej być w stanie gotowym do wdrożenia produkcji. Definicja „zrobionego” opisuje ten stan.

Najczęściej zespoły włączają do swojej definicji „zrobionego” działania rozwojowe, które mają być wykonane, aby przyrost mógł być uważany za „możliwy do wypuszczenia: programowany w parach lub z oceną kodu, po testach jednostkowych, po testach akceptacji przez użytkownika, po testach integracji, regresji i wydajności. To są ważne standardy deweloperskie, które rozszerzają przejrzystość, ale czy są też dobrą definicją „zrobionego”? Pomyślcie o każdej branży innej niż produkcja oprogramowania. Czy możecie wyobrazić sobie „jakość” wyrażaną w kategoriach używanych maszyn, narzędzi i praktyk? Czy nie jest to określenie jak tworzyć jakość, a nie definiowane samej jakości?

Jakość jest optymalnie definiowana przez właściwości, jakie powinien mieć produkt. Produkt „zrobiony” nie jest w Scrumie produktem, do którego zastosowano rygorystyczne, poprawne standardy deweloperskie. Produkt „zrobiony” wykazuje cechy, które są zgodne z wyobrażeniami organizacji: wewnętrzną budowę produktu i przestrzegane standardy organizacji i utrzymania, tylko z wartościową funkcjonalnością i z zachowaniem wszystkich obowiązujących standardów użyteczności.

Zawrzyjcie w swojej definicji „zrobionego” więcej niż tylko pracę potrzebną do wykonania przyrostu możliwego do wypuszczenia. Przesuńcie to tak, aby uzyskać wskazówki tworzenia wartościowych przyrostów.Jak nauczyłem się przestać się martwić i zacząć używać Scruma
Simon Reindl

Ta historia dotyczy mojego pierwszego zespołu Scruma i wydarzyła się około roku 2006. Budowaliśmy nowy system, który był złożony i wymagający, obejmował skanowanie i przetwarzanie dokumentów, które miały być zarządzane z call center.

Wielu członków zespołu (włączając mnie) przeszło z projektu, który wykorzystywał praktyki extreme programming (XP). Chcieliśmy zastosować Scrum, aby poprawić dostarczany produkt.

Zaczęliśmy od sprintu w trzytygodniowych cyklach. Mieliśmy zautomatyzowane środowisko, które według naszych wyobrażeń miało generować pliki instalacyjne i skrypty, kopiować je na serwery testowe oraz instalować i uruchamiać testy z dnia na dzień. Naszym zdaniem było to dość dobre podejście.

Wszystko to miało być robione z wykorzystaniem bardzo nowej technologi, która była kamieniem węgielnym architektury i strategii produktu. Po kilku sprintach sprawy zaczęły się komplikować. Ukończyliśmy dużo podstawowych prac i próbowaliśmy włączyć fragment, który nie chciał się poprawnie zintegrować. Lokalny ekspert z zakresu naszej technologii nie był dostępny w krytycznym czasie, jaki nam został w sprincie prowadzącym do jego przeglądu.

Nadszedł przegląd sprintu, a my nie potrafiliśmy dodać i zintegrować fragmentu, który sobie założyliśmy. W istocie nie mieliśmy nic do pokazania. Ostatnia kompilacja była wadliwa i nie chciała się nawet zainstalować. Zostaliśmy bez niczego przetestowanego i jako zespół nie mieliśmy odwagi, aby podzielić się tym, co było dostępne. Nasz główny interesariusz, którym był menedżer odpowiedzialny za zespół call center, był obecny i miał wysokie oczekiwania.

Jako zespół wiedzieliśmy, że nie mieliśmy przyrostu. I poinformowaliśmy o tym wszystkich obecnych. Powiedzieliśmy, że nie mamy niczego do pokazania i nie udało nam się nawet spełnić własnej definicji „zrobionego”.

Nastąpiła pełna napięcia cisza, gdyż oczekiwano przynajmniej czegoś do pokazania. Rozmawialiśmy o naszym celu na ten sprint, co wynikło z naszego planu i o naszych wyzwaniach. Opisaliśmy, co dla nas znaczyło „zrobione” i że produkt nie osiągnął tego stanu. Omówiliśmy nasz plan otrzymania działającej wersji produktu i o następnych wprowadzanych funkcjach.

Po cierpliwym wysłuchaniu nas powiedziano nam w bardzo jasny sposób, że projekt nie będzie kontynuowany, jeśli nie potrafimy zbudować działającego produktu, i że lepiej by było, abyśmy wkrótce mieli coś do pokazania.

Interesariusze wyszli.

Przeszliśmy do retrospektywy sprintu.

Zebraliśmy się w dużym napięciu – byliśmy źli, sfrustrowani i zawiedzeni. Poświęciliśmy tygodnie ciężkiej pracy i nie tylko nie mieliśmy nic do pokazania, lecz także groziło nam odwołanie dalszych prac. Zrobiło się gorąco, słychać było podniesione głosy, Pojawiły się oskarżenia, narzekania i argumenty. Na szczęście po tym wszystkim przeprowadziliśmy bardzo ukierunkowaną dyskusję. Nikt z nas nie chciał się znaleźć ponownie w takiej sytuacji. Pojawiło się jednak poczucie strachu i paniki, że nasz projekt zostanie wstrzymany.

Podczas przeglądu sprintu kilka sprintów później mieliśmy ukończoną nową funkcję i byliśmy tym podekscytowani – była naprawdę niezła. Pokazaliśmy ją głównej interesariuszce.

„Czy to naprawdę może zadziałać?” – zapytała nas.

„Tak, wymaga jedynie autoryzacji, gdyż musimy mieć podpis szefostwa, aby popchnąć cały proces”.

„Dopilnujcie, aby to działało na jutro na 9 rano. Ta funkcja jest wiele warta dla mojego zespołu”.

Ponieważ element był naprawdę „zrobiony”, wprowadziliśmy go natychmiast do produkcji. Wkrótce okazało się, że była to jedna z funkcji, którą po prostu uwielbiał zespół korzystający z produktu, a menedżer był w końcu zadowolony.

Tak nauczyłem się, że należy przestać się martwić i zacząć korzystać ze Scruma.