💡 Scrum to metodyka ramowa – zestaw unikalnych zasad organizowania pracy zespołowej. Chociaż metodyka ma charakter wytwórczy, niektóre z tych zasad mogą sprzyjać kreatywności, działaniom generatywnym i eksploratywnym – pomagają bowiem zespołom wytwarzać wysokiej jakości rozwiązania, adaptować projekt do zmieniających się potrzeb interesariuszy, a jednocześnie nieustannie doskonalić procesy – zarówno te twórcze, jak i te wytwórcze. W artykule omówiono genezę i źródła koncepcyjne metodyki, opisano najważniejsze jej zalecenia, a ostatecznie wskazano na wybrane elementy funkcjonalne, które mogą wspierać zespół projektowy w trakcie kreatywnej pracy.  

Jaka jest geneza metodyki Scrum?

Początki metodyki Scrum sięgają drugiej połowy lat osiemdziesiątych XX wieku i wiążą się z publikacją artykułu The New New Product Development Game w Business Harvard Review. Na podstawie analizy takich firm jak Honda, Canon i Fuji-Xerox, Hirotaka Takeuchi i Ikujiro Nonaka (1995), autorzy artykułu, poddali krytyce sekwencyjne (typu waterfall) – sztafetowe – podejście do zarządzania projektami rozwoju produktu, tzw. PPP (phased program planning), w którym to kolejne zespoły funkcjonalne (R&D, marketing, inżynierowie produkcji) przekazują sobie pałeczkę wedle kolejności przepływu faz projektu, tj. od rozwoju koncepcji i testowania wykonalności, poprzez projektowanie produktu i rozwój produktu, aż po produkcję pilotażową i produkcję finalną.

The traditional sequential approach to product development may conflict with the goals of maximum speed and flexibility (Takeuchi i Nonaka, 1995).

Obserwacja tych innowacyjnych firm umożliwiła badaczom zaproponowanie własnej metody – koncepcji zachodzących na siebie faz realizacji projektu (overlapping), przebiegających nie w sposób liniowy, lecz wyłaniających się w postaci iteratywnych eksperymentów z ciągłych interakcji multifunkcjonalnego zespołu, odpowiedzialnego za realizację projektu od początku do końca. Koncepcję tę jej autorzy przyrównali do gry w rugby, w której piłka przekazywana jest wielokrotnie do tyłu i do przodu. Rdzeniem koncepcji Japończyków jest sześć integralnych elementów: (1) wbudowana niestabilność, (2) samoorganizujące się zespoły, (3) zachodzące na siebie fazy rozwoju produktu, (4) zespołowe uczenie się, (5) subtelna kontrola i (6) organizacyjny transfer wiedzy (Takeuchi i Nonaka 1986, Wyrozebski 2011).

Under the old approach, a product development process moved like a relay race, with one group of functional specialists passing the baton to the next group. Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish. Rather than moving in defined, highly structured stages, the process is born out of the team members’ interplay (Takeuchi i Nonaka, 1995).

Rozwój koncepcji Takeuchiego i Nonaki

Pomysł Japończyków był sukcesywnie rozwijany. Podobno pierwszymi, którzy użyli określenia „scrum” na podejście opisane przez Takeuchiego i Nonakę, byli Peter DeGrace i Leaslie Stahl (1990) (Ćwiklicki, 2010). Autorzy książki pt. Wicked Problems, Riglueous Solutions zaproponowali model „wszystko na raz” (all-at-once model), który zakładał jednoczesną pracę nad wszystkimi etapami rozwoju oprogramowania, pod przewodnictwem jednego super-programisty. Model ten przeciwstawiony został przez autorów metodom kaskadowym (waterfall) – niedostosowanym do potrzeb wytwarzania oprogramowania, m.in. ze względu na częste zmiany zakresu wymagań w trakcie procesu tworzenia oprogramowania (Wyrozębski 2011).

Narodziny Scruma

W roku 1993 Jeff Sutherland i jego zespół w korporacji Easel stworzył proces Scrum, łącząc ze sobą koncepcje przedstawione w artykule Takeuchi’ego i Nonaki z ideami programowania zorientowanego obiektowo, empirycznej kontroli nad procesem, wytwarzania w sposób iteracyjny i przyrostowy, analizy procesów i wydajności wytwarzania oprogramowania oraz złożonych systemów adaptacyjnych (Rubin, 2013). W tym czasie powstał także pierwszy zespół scrumowy. Okazało się, że metodyka Scrum jest skuteczna w realizacji złożonego projektu. Na to pierwsze zastosowanie miały wpływ (Ćwiklicki, 2010):

• 📚 teoria ograniczeń (Theory of Constrains) opracowana w latach 70-tych XX wieku przez Eliyahu M. Goldratta. W dużym uproszczeniu teoria ta propaguje systemowe spojrzenie na przedsiębiorstwo i łańcuch dostaw. Utrzymuje ona, że każdy system posiada przynajmniej jedno ograniczenie, które powstrzymuje go przed optymalnym wykorzystaniem zasobów. Główna przesłanką tej koncepcji jest stwierdzenie, że każde ograniczenia limitują działanie systemu. Aby wykorzystać maksymalny potencjał systemu, należy dokonać identyfikacji ograniczeń (wąskich gardeł), a następnie podporządkować wszelkie decyzje maksymalnemu wykorzystaniu możliwości wąskiego gardła (Ćwiklicki, 2001).
• 📚 terminy muri, mura i muda zaczerpnięte z koncepcji Lean Management. Terminy te zostały zaczerpnięte z Toyota Production System, gdzie są używane do definiowania marnotrawstwa.
  • Muda oznacza: bezcelowość, nieprzydatność, bezczynność, marnotrawstwo, straty, nieekonomiczność.
  • Mura oznacza: nierównomierność, nieregularność, niejednostajność, nierówność.
  • Muri oznacza: brak racjonalności, niemożliwość, nadmierną trudność, wymuszanie, przymus, nadmiar, nieumiarkowanie – chodzi o przeciążenie ludzi lub maszyn.
• 📚 idea codziennych spotkań zaczerpnięta została z doświadczeń James’a Copliena, który w okolicy roku 1994 prowadził projekt Borland Quattro Pro i opisał praktykę codziennych spotkań, jako hiperproduktywną (hyperproductive):

One of the elements of Borland team’s “secret sauce” was that they would have everyone on the team meet every single day to discuss how they were performing. Getting everyone together in a room was key, because it gave the team the opportunity to self-organize around challenges (Scruminc.com).

Jeff Sutherland przedstawił wyniki zastosowania podejścia Scrum Kentowi Schwaberowi, który podjął się dalszych prac ukierunkowanych na opracowanie skodyfikowanej metodyki. Ken Schwaber po raz pierwszy zaprezentował publicznie metodę Scrum w 1995 r. podczas konferencji „Object-Oriented Programming, Systems, Languages and Applications” zorganizowanej przez Object Management Group. Od 1995 roku powstało 7 różnych wersji podstawowego podręcznika metodyki (Scrum Guide), z których pierwsza wydana została w 2010 roku.  

Czym jest Scrum?

Scrum to 💡 metodyka ramowa (framework) – oferuje jedynie uproszczone i ogólne ramy a nie dokładny tok postępowania, powodujący zatratę pierwiastka twórczego (Ćwiklicki, 2010).

Fundamentem Scruma jest 💡 empiryzm. Istotą empiryzmu jest to, że wiedza wynika z doświadczenia, a decyzje podejmowane są na podstawie tego, co można zaobserwować (Scrum Guide, 2020). Stosowana jest tzw. 💡 empiryczna kontrola procesu (empirical control process) – koncepcja, która powstała w wyniku krytycznego podejścia do matematycznych prób ujęcia współczesnych zjawisk gospodarczych (→ ramka 1) (Ćwiklicki, 2010).

Ramka 1. Czym jest empiryczna kontrola procesu?  Zdaniem Kenta Schwabera, w rozwoju produktów możemy wyróżnić dwa rodzaje procesów: procesy zdefiniowane i procesy empiryczne. Procesy zdefiniowane (defined processes) można powtarzać a ich wynik jest przewidywalny. Natomiast procesy empiryczne (empirical processes) to takie, których wynik jest nieokreślony, a możliwość wystąpienia w nich nieprzewidzianych sytuacji jest wysoka (Schwaber, 1996; Ćwiklicki, 2010): A defined process is predictable; it performs the same every time. An empirical process requires close watching and control, with frequent intervention. It is chaotic and unrepeatable, requiring constant measurement and control through intelligent monitoring (Schwaber, 1996). W odniesieniu do kontroli procesów zdefiniowanych, u podstaw funkcjonowania których leżą mechanizmy dobrze zrozumiałe, stosuje się tzw. zdefiniowaną kontrolę procesu, tj. czyli podejście teoretyczne do modelowanie (Schwaber, 2005). Natomiast kontrola procesów empirycznych, złożonych i nieprzewidywalnych, wymaga zastosowania tzw. empirycznej kontroli procesu (empirical control process), która polega na kierowaniu procesem krok po kroku, zapewniając jego zbieżność w kierunku akceptowalnego stopnia dokładności (Schwaber, 2005). W przypadku tego rodzaju kontroli nie jest wymagana żadna wiedza początkowa na temat procesu: No a priori knowledge about the process is necessary; a process is treated like a black box. W praktyce realizacja tego podejścia polega na iteracyjnym dostarczaniu kolejnych przyrostów funkcjonalności (Ćwiklicki, 2010). Jak jest realizowana empiryczna kontrola procesu? Ken Schwaber wskazuje na trzy filary które utrzymują każdą implementację empirycznego procesu kontroli: przejrzystość (transparency), inspekcję (inspection) i adaptację (adaptation). Przejrzystość: aspekty procesu, które wpływają na wynik, muszą być jednoznaczne i widoczne dla tych, którzy kontrolują proces. Inspekcja: aspekty procesu muszą być poddawane kontroli wystarczająco często, aby wykryć nieakceptowane odchylenia w procesie. Adaptacja: dostosowywanie procesu, w sytuacji gdy jakikolwiek aspekt procesu wykracza poza dopuszczalne limity lub jeśli uzyskany produkt jest niemożliwy do zaakceptowania.

Warto także zauważyć, że z punktu widzenia metodologicznego, Scrum jest również przykładem praktycznego stosowania koncepcji 💡 teorii złożoności (Ćwiklicki, 2010) – pojęcie to wyjaśniono w ramce 2.

Ramka 2. Scrum a nauka o złożoności Nauka o złożoności zajmuje się badaniem systemów złożonych. W ogólnym ujęciu system traktuje się jako złożony, jeżeli występuje w nim duża liczba oddziałujących ze sobą elementów. Złożoność wynika z dwóch cech: wielości (dużej liczby elementów) oraz relacyjności (wysokiego stopnia wzajemnych powiązań między elementami). Zachowania systemu złożonego są trudne do określenia i predykcji – a niemożliwe do przewidzenia na podstawie analizy systemu zredukowanego do jego elementów składowych. Szczególnego rodzaju podklasą systemów złożonych są złożone systemy adaptacyjne (ZSA). Złożony system adaptacyjny to dynamiczna sieć oddziałujących ze sobą podstawowych elementów zwanych agentami. Elementy tej sieci działają równolegle, wpływając na inne elementy i reagując na ich wpływ. Wpływ ten polega na komunikacji, konfliktach, kooperacji i negocjacjach. W złożonym systemie adaptacyjnym brak jest jakiejkolwiek scentralizowanej kontroli. Elementy tego systemu pozostają w pełni autonomiczne, co oznacza, że mają one możliwość kontroli nad swymi stanami wewnętrznymi. Jakiekolwiek spójne działanie systemu jako całości wynika ze współpracy i konkurencyjnych działań elementów (agentów). Działanie całego systemu jest więc wynikiem bardzo dużej liczby decyzji podejmowanych w każdej chwili przez indywidualne elementy. Złożony system adaptacyjny ma następujące cechy (Mesjasz, 2007): samopodobieństwo (self-similarity), złożoność (complexity), wyłaniające się cechy (emergence) oraz samoorganizację. Scrum jest odzwierciedleniem pewnych założeń ZSA – i nie chodzi tutaj tylko o samoorganizację, ale np. także o wyłanialność zachowań i cech. Zachowania i cechy zespołu stanowią wypadkową wielu zachowań i cech indywidualnych, a wyłaniający się (emergentny) produkt pracy twórczej jest efektem złożonej sieci interakcji między uczestnikami procesu.

Popularność Scrum

Chociaż podstawowe założenia metodyki nie mogą być modyfikowane, środowisko scruma jest adaptowalne – w każdej organizacji może powstać unikatowa wersja Scruma, dostosowana do potrzeb jego użytkowników.

Scrum jest obecnie najbardziej popularną metodyką Agile (digital.ai, 2021; Papadakis i Tsironis, 2018). Chociaż została opracowana na potrzeby wytwarzania produktów cyfrowych, jest obecnie szeroko stosowana do tworzenia produktów nie będących oprogramowaniem.

Praktyki Scrum

Struktura metodyki Scrum oparta jest wartościach oraz na trzech grupach elementów – są to: role, wydarzenia i artefakty.  

👥 Role:

• właściciel produktu (product owner),
• szef Scruma (scrum master),
• zespół (scrum team),

🎭 Wydarzenia:

• spotkanie planowania sprintu (sprint planning meeting),
• spotkanie przeglądu sprintu (sprint review meeting),
• codzienne zebrania (daily scrum meeting),

🎩 Artefakty:

• wykaz prac produktu (product backlog),
• wykaz prac sprintu (sprint backlog),
• wykres malejący (burndown chart).

Nie będziemy ich w artykule wszystkich opisywać, ale przypomnę niektóre. Na koniec artykułu wskażę na wybrane cechy Scruma, które wspierają twórcze myślenie w zespole projektowym oraz kreatywność w organizacji.  

Wartości Scrum

Scrum wskazuje na pięć wartości – są to:

• zaangażowanie (commitment),
• odwaga (courage),
• skupienie (focus),
• otwartość (openness),
• szacunek (respect).

Z punktu widzenia twórczego myślenia i kreatywności, istotna jest otwartość oraz odwaga do mierzenia się z trudnymi problemami. Warto pielęgnować także szacunek, w tym także dla pomysłów innych uczestników procesu.

Zespół Scrum

Produkcja w Scrumie opiera się na przynajmniej jednym zespole scrumowym , na który składają się trzy role scrumowe: Właściciela Produktu, Scrum Mastera i Zespołu Deweloperskiego.

Zespół Scrum jest samozarządzającym się (self-managing), tj. samodzielnie podejmuje decyzje o tym, kto będzie wykonywał określone zadania, kiedy i jak (Scrum Guide, 2020). Chodzi de facto o stan pogłębionego upełnomocnienia (empowerment) i zdolność do pełnej samoorganizacji (self- organization) (→ ramka 3) oraz autonomicznego, świadomego decydowania o sposobie realizacji zadań (Scrum.org).

Zespół Scrum nie dzieli się na podzespoły, nie obowiązuje w nim hierarchia. Scrum Guide zaleca, aby scrum teamy były interdyscyplinarne (cross-functional), tj. posiadały umiejętności niezbędne do wytwarzania wartości bez konieczności współpracy z osobami spoza zespołu. Chodzi także o zdolność do efektywnego współtworzenia – uzupełniania się talentami i umiejętnościami: Scrum is built upon by the collective intelligence of the people using it (Scrum Guide, 2020). Zdaniem Schwabera i Sutherlanda, model zespołu w Scrum został zaprojektowany, aby optymalizować elastyczność, kreatywność i produktywność (Scrum Guide, 2020).

Ramka 3. Naukowo o samoorganizacji 💡 Samoorganizacja to pojęcie zaczerpnięte ze słownika nauk o złożoności – jest to: zdolność systemu do samorzutnego wzrostu złożoności, uporządkowania, zmiany jego organizacji i funkcji przy elastycznej reakcji na wpływ czynników zewnętrznych. Posługując się językiem teorii chaosu, można powiedzieć, że samoorganizacja to generowanie struktury atraktorów w oparciu o lokalne oddziaływania (Dombrowski, 2013). Samoorganizacja umożliwia szybkie reagowanie na dynamikę otoczenia, zarówno wewnętrzną (polegającą na implementowaniu w systemie wiedzy powstałej wskutek uczenia się jednostek i pozyskiwanych doświadczeń a następnie zmianie relacji między zasobami organizacji), jak i zewnętrzną (Ćwiklicki i in., 2010). W kontekście podejść zwinnych, samoorganizacja to usamodzielnianie zespołów pracowniczych w realizacji zadań, celów i procesów (Ćwiklicki i in., 2010). Można powiedzieć, że w samoorganizujących się zespołach poszczególne osoby podejmują niezbywalną odpowiedzialność za zarządzanie własnym obciążeniem, wymieniają się zadaniami na podstawie potrzeb i najlepszych predyspozycji, uczestniczą w zespołowym podejmowaniu decyzji (Highsmith, 2005). Co można powiedzieć o systemie samoorganizującym się? Samoorganizacja powstaje na potrzeby realizacji konkretnych celów. W efekcie samoorganizacji (Ćwiklicki i in., 2010): system integruje funkcje zarządzania i wykonywania pracy, system modyfikuje procesy, zadania i operacje w celu maksymalizowania wartości przekazywanej do otoczenia (klienta wewnętrznego i zewnętrznego), system pozyskuje informacje ze wszystkich możliwych źródeł otoczenia, system dąży do rozwoju własnego potencjału – pozyskuje, przetwarza i rozwija zasoby wiedzy otoczenia dla identyfikacji mocnych stron i dobiera strategie umożliwiające dostosowanie do zmian w otoczeniu, system eskaluje i wzmacnia zachowania w układzie dynamicznym – uwzględnia samoreferencję umożliwiającą kreowanie (tj. rozwijanie i inicjowanie) potencjału jej rozwoju, system permanentnie doskonali procesy pracy i produkty działalności poprzez eksperymentowanie i uczenie się w działaniu. Samoorganizacja oparta jest na zasadach: (1) harmonizacji, (2) najkrótszej drogi, (3) delegowania uprawnień, (4) współmierności uprawnień i odpowiedzialności oraz (5) zasadzie wyjątku, natomiast w mniejszym stopniu istotne są zasady podziału pracy i koncentracji, specjalizacji oraz zasady hierarchii i rozpiętości kierowania (Ćwiklicki i in., 2010).

Właściciel produktu

Właściciel Produktu (product owner) to kolejna rola w zespole scrumowym. Właściciel Produktu ponosi odpowiedzialność za maksymalizowanie wartości produktu będącego efektem pracy zespołu scrumowego. Utrzymuje i komunikuje on uczestnikom procesu wizję celu, identyfikuje i definiuje funkcjonalności produktu, decyduje które cechy produktu powinny zostać zbudowane i nadaje tym cechom priorytety. Do jego uprawnień należy także akceptacja bądź odrzucenie wykonanej pracy.

Podczas sprintu Właściciel Produktu współpracuje ze wszystkimi uczestnikami zespołu. Odpowiada na wszystkie pytania dotyczące produktu (np. co należy zbudować i jak użytkownicy będą korzystali z rozwijanych funkcji) i podejmuje drobne decyzje dotyczące działania produktu. Product Owner ponosi również odpowiedzialność za skuteczne zarządzanie wykazem prac produktu, czyli Backlogiem Produktu. Product Owner powinien mieć odpowiednie umocowanie w strukturze organizacji a jego decyzje być respektowane przez całą organizację.  

Scrum Master

Scrum Master pomaga uczestnikom procesu w zrozumieniu i przestrzeganiu wartości, zasad i praktyk Scruma. Przewodzi on procesowi i wspiera zespół oraz pozostałą część organizacji w rozwinięciu unikalnej wersji Scruma. Nie posiada uprawnień rozkazodawczych, nie pełni roli kierownika zespołu ani projektu, nie jest właścicielem planu (może jedynie pomagać zespołowi w jego opracowywaniu), chociaż działa jako lider i pomaga zespołowi podejmować decyzje. Jest także odpowiedzialny za usuwanie przeszkód, które ograniczają produktywność zespołu oraz za jego ochronę przed ingerencjami z zewnątrz.

Zespół deweloperski

Zadaniem zespołu deweloperskiego (development team) jest wytworzenie działających funkcjonalności produktu, wskazanych przez Właściciela Produktu. W skład zespołu wchodzi od 5 do 9 osób posiadających umiejętności specjalistyczne konieczne do pracy w projekcie i osiągnięcia celów sprintu. Zespół charakteryzuje się zupełnie płaską strukturą i organizuje się samodzielnie (zgodnie z opisanymi wcześniej zasadami) – samodzielnie określa najlepszy sposób realizacji wyznaczonego przez Właściciela Produktu celu oraz zobowiązując się do dostarczenia wartościowych i użytecznych elementów z Backlogu Produktu. Uczestnicy zespołu mogą wybrać dowolną ścieżkę działania pod warunkiem, że prowadzi ona do osiągnięcia celu sprintu i na jego koniec będą mogli zaprezentować działający inkrement produktu. Podejście to zapewnia dużą autonomię i swobodę zmiany sposobu pracy, gdy pojawią się nowe fakty dotyczące projektu.

Proces w Scrum

Proces w Scrum odzwierciedla podejście iteracyjne i przyrostowe. 💡 → Podejście iteracyjne oparte jest na cyklach krótkich przejść (zwanych → sprintami) mających na celu dostarczenie określonych dla nich produktów. Zgodnie z założeniami empirycznej kontroli procesu, z każdym cyklem zespół adaptuje się do zmian – udoskonala produkt i metody działania. Natomiast 💡 → podejście przyrostowe oznacza, że prace są dzielone na następujące po sobie sprinty; rozwój produktu dokonywany jest poprzez kolejne przyrosty, czyli funkcje i funkcjonalności rozszerzające zakres projektu. Podejście przyrostowe ogniskuje wysiłek zespołu na elementach dostarczających klientowi największą wartość, a ponadto pozwala na uzyskanie zdatnych do użycia inkrementów produktu już w trakcie przebiegu projektu, czyli jeszcze przed jego zakończeniem.

Sprint

Sprinty są pulsem Scruma. W Sprintach pomysły są przekształcane w wartość. Każdy sprint trwa nie dłużej niż miesiąc (i nie krócej niż tydzień, przy czym raz ustalona długość sprintu pozostaje niezmienna) i powinien być zakończony dostarczaniem widocznej, użytecznej wartości dla klienta lub użytkownika, tzw. potencjalnie zdatnym do wdrożenia przyrostem produktu. Kolejne sprinty realizowane są bezpośrednio jeden po drugim. Ma to za zadanie wprowadzić określoną dynamikę pracy oraz równe, jednostajne i jednocześnie w miarę szybkie tempo pracy całego zespołu (Wyrozębski, 2021). W trakcie trwania sprintu zmianom nie dokonuje się żadnych zmian, które zagrażałyby osiągnięciu tzw. celu sprintu. zakres prac może jednak (ewentualnie) ulec zmianie, w miarę jak zespół pogłębia swoje zrozumienie projektu. Sprint może zostać przerwany tylko w przypadku, gdy cel sprintu stanie się nieaktualny.

Cykl życia projektu

Cykl rozpoczyna stworzenie wizji produktu, która następnie przybiera formę listy, składającej się z uporządkowanych zgodnie z priorytetami elementów funkcjonalności tworzonego produktu. Lista ta nazywana jest 💡 → Backlogiem Produktu (product backlog). Backlog Produktu to, w uproszczeniu, lista funkcjonalności  produktu uporządkowana według priorytetów nadanych przez Właściciela Produktu. W przypadku nowego produktu, Backlog Produktu zawiera początkowo funkcjonalności (a także pomysły na innowacje) wymagane do zrealizowania wizji produktu, natomiast w przypadku produktu już istniejącego Backlog Produktu może obejmować nowe funkcjonalności, zmiany funkcjonalności, poprawki techniczne, a także wymagające naprawy błędy. Funkcjonalności produktu przedstawiane są często w formie krótkich i prostych historyjek napisanych z perspektywy użytkownika i opisujących sposób korzystania z danej funkcji produktu (oprogramowania). 📜 Historie użytkowników powinny pomagać zespołowi zrozumieć klientów, odpowiadając na trzy pytania: Kim jest użytkownik? Co użytkownik chce robić? Dlaczego użytkownik chce to robić? Dla każdej historii użytkownika definiuje się definicję ukończenia (Defintion of Done, DoD) i zamieszcza się na odwrocie karty z opisem danej historii.  Wszelka działalność związana z tworzeniem i uszczegóławianiem elementów Backlog Produktu, ich ocenianiem i nadawaniem im priorytetów określana jest mianem doskonalenia  (Product Backlog refinement).

Planowanie sprintu

Drugą aktywnością jest planowanie sprintu (sprint planning meeting) – Właściciel Produktu i Zespół Deweloperski zgadzają się na cel sprintu (sprint goal), który określa co ma zostać osiągnięte poprzez realizację nadchodzącego sprintu. Mając ten cel na uwadze, zespół dokonuje przeglądu Backlogu Produktu i 💨 zasysa (system pull – jest to kolejna inspiracja koncepcjami lean management i product development) z listy elementy o wysokim priorytecie, które jest w stanie zrealizować pracując w podtrzymywalnym tempie, tj. z prędkością zapewniającą komfort pracy w długim okresie. Raz zaakceptowany przez zespół i Właściciela Produktu zakres prac nie podlega zmianom w trakcie trwania sprintu. Następnie wybrane funkcjonalności (historie użytkowników) dekomponowane są na zadania cząstkowe (sprint tasks). Określana jest czasochłonność tych zadań wyrażona w godzinach pracy. Określana jest definicja ukończenia każdego elementu. Stworzony w ten sposób przegląd sprintu – lista – nazywana jest → Backlogiem Sprintu (sprint backlog) lub wykazem prac sprintu. W momencie spisania wykaz prac sprintu niekoniecznie musi być kompletny, gdyż plan konstruowany jest przy danym (niepełnym) stanie wiedzy zespołu. Lista ta z pewnością będzie aktualizowana w miarę upływu czasu trwania danej iteracji. Niekiedy do wizualizowania prac stosuje się tzw. tablice kanbanowe, dzielące zadania na: jeszcze nierozpoczęte (To do), w trakcie realizacji (Doing), zakończone (Done).

Wykonanie zadań

Po zakończeniu planowania, zespół wykonuje kolejne zadania, aż do ukończenia wszystkich zaplanowanych funkcjonalności. Bardzo ważną zasadą metodyki Scrum jest warunek niezmienności listy funkcjonalności przyjętej do realizacji w danym sprincie. Oznacza to, że gdy Zespół Deweloperski i Właściciela Produktu raz osiągną porozumienie co do zakresu prac do wykonania, żadna ze stron nie może go zmienić. Zapobiega to sytuacjom, w których kierownictwo w przebiegu sprintu próbuje wymóc na zespole dodatkową pracę lub z dużą częstotliwością zmienia priorytety zadań. Jeśli w czasie trwania sprintu któryś z członków zespołu odkryje, że podjął się zbyt wielu zadań lub że może zrobić więcej, powinien poinformować o tym Właściciela Produktu, który może dostosować Backlog Sprintu do możliwości zespołu lub go zakończyć i rozpocząć planowanie nowego, w przypadku, gdy dostarczanie działającego inkrementu oprogramowania okaże się być niemożliwe.

Daily Scrum

W czasie realizacji przeprowadzane są krótkie działania scrumowe – trwające do 15 minut 👥 spotkania codzienne (daily scrum meeting, codzienny scrum). Zebrania te animowane przez Scrum Mastera, który zadaje każdemu uczestnikowi trzy pytania:

• Co udało ci się osiągnąć od ostatniego spotkania?
• Nad czym zamierzasz pracować do czasu kolejnego spotkania?
• Jakie przeszkody lub utrudnienia stoją na przeszkodzie do osiągnięcia postępu w pracy?

Spotkanie nie ma formy tradycyjnego statusu, nie służy też rozwiązywaniu problemów (o takowych można rozmawiać w gronie zainteresowanych, po zakończeniu spotkania scrumowego) –  jest to raczej realizowana codziennie aktywność inspekcyjno-adaptacyjna i synchronizacyjna, która pozwala samoorganizującemu się zespołowi na lepsze wykonywanie pracy. Udzielone odpowiedzi zapewniają zespołowi codzienną pętlę informacji zwrotnych, a podejmowanie decyzji w ostatnim sensowym momencie (last responsible moment), gdy dostępnych jest najwięcej informacji na temat projektu, pozostawia otwarte opcje i ułatwiają adaptację do zmian. Obecność na spotkaniu scrumowym nie jest obowiązkowa. Udział w spotkaniu mogą też brać interesariusze, ale muszą pozostać cichymi obserwatorami.

Zakończenie sprintu

Wynik sprintu jest potencjalnie zdatnym do wdrożenia przyrostem produktu zgodnym z uzgodnioną przez zespół scrumowy na etapie planowania definicją ukończenia (DoD). Dlatego po zakończeniu sprintu wszystkie elementy nie spełniające definicji ukończenia nie są akceptowane przez Właściciela Produktu i wracają do Backlogu Produktu, nawet jeśli zespół ukończył znaczną część (a nawet większość) pracy nad nimi.

Na koniec każdej iteracji wykonywane są dwie dodatkowe aktywności inspekcyjno-adaptacyjne: przegląd sprintu i retrospektywa sprintu.

Przegląd sprintu

💡 Przegląd sprintu (sprint review meeting) ma na celu inspekcję i adaptację produktu będącego w procesie wytwarzania. Spotkanie ma formę dyskusji, w której obok zespołu, Właściciela Produktu i Scrum Mastera uczestniczyć mogą także interesariusze, sponsorzy, klienci i zainteresowani tematem uczestnicy innych zespołów. Celem dyskusji jest przegląd ukończonych właśnie funkcjonalności oraz wykreślenie pozycji wykonanych i odebranych z Backlogu Produktu. Zespół przedstawia wyniki swojej pracy oraz demonstruje działające funkcjonalności produktu, zaś Właściciel Produktu ma za zadanie zapoznać się z rozwiniętym produktem i przekazać zespołowi aktualne informacje na temat wizji produktu i stanu rynku. W trakcie debaty zespół scrumowy może podnieść wartość biznesową i marketingową produktu dzięki informacji zwrotnej na temat zbieżności produktu z celami klientów i użytkowników. Pozycje z wykazu prac produktu, które zostały wykonane i odebrane w całości, wykreśla się. Pozycje, które wymagają dalszej pracy, nie mogą być prezentowane na spotkaniu i wracają do zestawienia, gdzie będą oczekiwać na zaktualizowane priorytety od Właściciela Produktu.

Retrospektywa sprintu

💡 Retrospektywa sprintu (sprint retrospective meeting) (raczej unika się sfomułowania retrospekcja) stanowi ostatnią aktywność przed rozpoczęciem planowania nowego sprintu. Jest to czas przeznaczony na inspekcję i adaptację procesu – uczenie się i doskonalenie uczestników scruma, aby kolejne iteracje przebiegały sprawniej od poprzednich. W trakcie spotkania każdy z uczestników wypowiada się na temat przebiegu ostatniego sprintu, odnosząc się do tego, co robione było dobrze, do tego, co robione było źle oraz wypowiadając się na temat zmian, jakie należałoby wprowadzić od kolejnego sprintu. Wynikiem spotkania powinna być lista problemów odkrytych podczas sprintu oraz zestaw działań naprawczych, jakie zostaną wdrożone przez zespół w kolejnym sprincie.

Zakończenie sprintu

Zakończenie sprintu to moment, w którym Właściciel Produktu aktualizuje wykaz prac produktu, czyli Backlog Produktu – uwzględnia w nim nie tylko postęp realizacji, ale także informacje i zmiany w otoczeniu projektu (np. oczekiwania co do funkcjonalności produktu ze strony użytkowników). Ze względu na zachodzące zmiany, w backlogu mogą pojawić się nowe pozycje, inne natomiast z niego wypaść – stracić swoje uzasadnienie. Z tego względu Właściciel Produktu musi na nowo uporządkować funkcjonalności produktu nadając im priorytety. Zgodnie z metodyką Scrum nowy sprint powinien rozpocząć się bezzwłocznie po zakończeniu ostatniego. Najlepiej aby spotkanie planujące sprint zostało przeprowadzone już w kolejnym dniu roboczym po spotkaniu przeglądu sprintu. Cykl zaczyna się zatem na nowo.

Czy Scrum sprzyja kreatywności?

Przejdźmy zatem do najważniejszego pytania – czy Scrum sprzyja kreatywności? Jak zostało już powiedziane, metodyka scrum to zestaw unikalnych zasad organizowania pracy zespołowej. Zasady te mogą sprzyjać działaniom kreatywnym – pomagają bowiem zespołom wytwarzać wysokiej jakości rozwiązania, adaptować projekt do zmieniających się potrzeb interesariuszy, a jednocześnie nieustannie doskonalić procesy – zarówno twórcze, jak i wytwórcze. Z punktu widzenia twórczego myślenia i kreatywności w organizacji, zwrócić można uwagę na następujące elementy Scruma:

Empiryczny model kontroli procesu: podejście iteracyjne i przyrostowe pozostawia przestrzeń dla zmian dostosowawczych i innowacyjnych – sprzyja adaptowaniu wytwarzanego rozwiązania do zmieniających się wymagań interesariuszy i pozostawia możliwość wytwarzania i wdrażania twórczych zmian w przebiegu projektu (czego nie daje podejście tradycyjne, sewkencyjne, typu waterfall).

Interaktywne wydarzenia scrum: Przewidziane w przebiegu cyklu liczne aktywności inspekcyjno-adaptacyjne i synchronizacyjne sprzyjają wymianie wiedzy, perspektyw, doświadczeń, pomysłów oraz działaniom o charakterze eksploratywnym i generatywnym. Za szczególnie istotne z punktu widzenia kreatywności należy uznać spotkanie przeglądu sprintu (którego celem jest inspekcja i adaptacja produktu będącego w procesie wytwarzania) oraz spotkanie retrospektywne (którego celem jest inspekcja i adaptacja procesu wytwarzania). Powyższe zdarzenia stanowią naturalną okazję do twórczej debaty – wzbogacania wytwarzanego produktu o nowe rozwiązania oraz doskonalenia procesów, w tym także procesów twórczych.

Samoorganizacja zespołu: zasady metodyki rozszerzają autonomię pracy, uczestnicy mają realny wpływ na rozwój projektu i uzyskują poczucie współdecydowania, które zwiększa ich zaangażowanie i motywację do aktywnego poszukiwania rozwiązań lepszych, bardziej nowatorskich. Poczucie autonomii (w zakresie decydowania o procesie – sposobach wykonywania pracy – niekoniecznie o efektach końcowych) oraz wsparcia ze strony organizacji od dawna uważane są za czynniki o kluczowym znaczeniu dla kreatywności pracowników (Amabile, 1998).

Scrum Master jako opiekun zespołu: Scrum Master usuwana przeszkody, które ograniczają produktywność zespołu oraz chroni zespół przed ingerencjami z zewnątrz. Ta dodatkowa ochrona ułatwia uczestnikom zespołu skoncentrowanie energii na tym co twórcze i dostarcza rzeczywistą wartość – a jest nią, obok użytecznego inkrementu produktu, także innowacja – innowacyjne produkty i usługi. Ponadto, Scrum Master wspiera procesy uczenia w zespole oraz łączy zespół z otoczeniem, przez co wzbogaca dostępny materiał poznawczy o nowe elementy – nowe cząstki wiedzy, perspektywy i pomysły. Działa również jako lider i pomaga podejmować decyzje, współodpowiada zatem za ocenę kreatywności. Wiele badań wskazuje, że tzw. upełnomocniający i służebny styl kierowania (→ ramka 4) w istotnym stopniu stymuluje twórcze myślenie uczestników zespołu oraz pobudza innowacyjność organizacji (np. Hughes i in., 2018).

Ramka 4. Scrum Master a przywództwo służebne i upełnomocniające 💡 Przywództwo służebne (servant leadership) to koncepcja zorientowana na człowieka, której cechą charakterystyczną jest stawianie na pierwszym miejscu interesu innych. Termin ten został wprowadzony do literatury przedmiotu w 1970 roku przez Robert Greanleafa. Wyróżniono 10 podstawowych cech przywództwa służebnego (Spears, 2005): słuchanie ze zrozumieniem, empatia, samoregeneracja, świadomość siebie i innych, perswazja, konceptualizacja, dalekowzroczność, służenie innym, zaangażowanie w rozwój innych, budowanie wspólnoty. 💡 Przywództwo upełnomocniające (empowering leadership) polega na dzieleniu się z podwładnymi władzą. Celem jest zwiększenie motywacji i zaangażowania w pracę współpracowników poprzez zapewnienie uczestnictwa w podejmowaniu decyzji, podkreślenie znaczenia pracy, usuwanie barier biurokratycznych, pokładanie zaufania w zdolności pracowników (Bratnicka, 2011).

Należy jednocześnie pamiętać, że autorzy Scruma niewiele uwagi poświęcili sposobom wspierania twórczego myślenia, oraz że jest to przede wszystkim metodyka wytwórcza. W opublikowanych przez autorów scruma materiałach odnaleźć można jedynie takie ogólne stwierdzenia, jak np.: Scrum uwalnia kreatywność zespołów (Sutherland i Schwaber, 2011), Scrum wspiera twórcze podejście do rozwoju złożonych i innowacyjnych systemów (Sutherland i Schwaber, 2011). Spostrzeżenia te nie są jednak poparte głębszą analizą, ani prezentacją praktyk, które miałyby re cele realizować. Tym samym, twórcza użyteczność metodyki zależy od umiejętnego dostosowania jej zaleceń do potrzeb uczestników procesu.  

Referencje / References:

Amabile, T. (1998), How to kill creativity, „Harvard Business Review”, Sept/Oct, 77–87.

Bratnicka, K. (2011a), Rola przywództwa w stymulowaniu twórczości w organizacjach, „Organizacja i Kierowanie”, nr 4(147), s. 129–141.

Ćwiklicki M. (2001), Wprowadzenie do współczesnych narzędzi harmonizacji, Zeszyty Naukowe Akademii Ekonomicznej w Krakowie, nr 564.

Ćwiklicki, M., Jabłoński, M., Włodarek, T. (2010), Samoorganizacja w zarządzaniu projektami metodą Scrum, Mfiles.pl, Kraków.

Degrace P., Stahl L.H. (1990), Wicked Problems, Righteous Solutions, Yourdon Press, Englewood Cliffs.

digital.ai. (2021), 15th Annual State of Agile Report (dostęp 20.04.2022).

Dombrowski, M. (2013), Złożona natura złożoności, Diametros, nr 36, s. 47-61.

Highsmith, J. (2005), APM: Agile Project Management, Jak tworzyć innowacyjne produkty, Wydawnictwo Mikom, Warszawa.

Hughes, D., Lee, A., Tian, A., Newman, A., Legood, A. (2018), Leadership, creativity, and innovation: A critical review and practical recommendations, „The Leadership Quarterly”, t. 29, nr 5, s. 549-569.

Mesjasz, C. (2007). Złożone systemy adaptacyjne, „Przegląd Organizacji”, nr 11, s. 3-6.

Papadakis, E., and Tsironis, L. (2018), Hybrid methods and practices associated with agile methods, method tailoring and delivery of projects in a non-software context, „Procedia Computer Science”, 138, 739–746.

Rubin, K. (2013), Scrum. Praktyczny przewodnik po najpopularniejszej metodyce Agile, Helion, Gliwice.

Schwaber K. (1996), Controlled Chaos: Living on the Edge, Advanced Development Methods, Inc., „American Programmer”.

Schwaber K. (2005), Sprawne zarządzanie projektami metodą Scrumv, Microsoft Press, Warszawa.

Spears, L. C. (2005), The understanding and practice of servant-leadership, „The International Journal of Servant-Leadership”, t. 1, nr 1, s. 29-45.

Wyrozebski. P. (2011), Metodyka SCRUM, [w:] M. Trocki, P. Wyrozebski, B. Grucza, W. Metelski, M. Juchniewicz, E. Buklaha, Metodyki zarządzania projektami, Bizzare, Warszawa, s. 251-269.

Wyrozębski, P. (2021), Zwinność: od zwinnych zespołów do zwinnego zarządzania, Oficyna Wydawnicza SGH.

Sutherland, J., Schwaber, K. (2011), The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework, Licoln, MA. Takeuchi, H., Nonaka, I. (1986), The new new product development game, „Harvard Business Review”, t. 64, nr 1, s. 137-146.