Na podstawie oryginalnego Scrum Guide autorstwa Ken Schwabera i Jeffa Sutherlanda (40)

Zebrane Opracowania tworzą Scrum Guide: Rozszerzenia
Ten dokument jest zbiorem niezależnych prac. Każda sekcja zachowuje swój oryginalny status licencji lub praw autorskich, jak wskazano. Prosimy o zapoznanie się z każdą sekcją w celu uzyskania szczegółowych praw użytkowania i wymagań.

Sekcja 1: Scrum Guide: Rozszerzenie 1 (Adaptacja)
Tytuł: Scrum Guide: Rozszerzenie Adaptacja: Oryginalnego Scrum Guide
Autorzy: Ralph Jocham, John Coleman i Jeff Sutherland.
Źródło: 2020 Scrum Guide , Scrum Guide Expansion Pack
Licencja: Creative Commons Attribution-ShareAlike 4.0 International ( CC BY-SA 4.0 ).
© 2025 Ralph Jocham, John Coleman i Jeff Sutherland.
Informacja o modyfikacji: To jest adaptacja oryginalnego 2020 Scrum Guide . Wprowadzono zmiany w stosunku do oryginału.
Zastrzeżenie: Nie udziela się żadnych gwarancji. Używasz na własne ryzyko.
Ta sekcja jest oferowana na licencji Attribution-ShareAlike 4.0 International Creative Commons.
Używając tego Scrum Guide: Rozszerzenia, zgadzasz się na warunki licencji CC BY-SA 4.0 .

Kontekst

Ken Schwaber i Jeff Sutherland kierowali rozwojem frameworka (ram postępowania) Scrum. Scrum Guide 2020 (40) opisuje podstawy Scruma. A Simple Guide to Scrum (58) autorstwa Tobiasa Mayera to skrócona, zredagowana wersja oficjalnego Scrum Guide Kena Schwabera i Jeffa Sutherlanda. Scrum Hexis (52) rozwijają Scrum Guide 2020 (40) uwzględniając perspektywę 2025 roku. Dla możliwie jak najszerszego przyjęcia, Scrum Guide (40) musiał być prosty.

Powód powstania Rozszerzeń do Scrum Guide

Dla skuteczniejszego wdrażania Scrum niniejsze Rozszerzenie oferuje dodatkowe wskazówki dostosowane do współczesnych realiów, bazując na Scrum Guidzie 2020 autorstwa Kena Schwabera i Jeffa Sutherlanda (40). Wkład Ralpha Jochama (89) w Scrum Guide 2020 nadał temu Rozszerzeniu dodatkową głębię, przenosząc do niego pierwotne idee Scrum Guide’a 2020 (40).

Rozszerzenie do Scrum Guide’a wyjaśnia co i dlaczego każdego elementu Scruma próbując spojrzeć w przyszłość. Każda część pełni konkretną funkcję i przyczynia się do ogólnej wartości oraz rezultatów osiąganych dzięki Scrumowi. Niniejsze Rozszerzenie będzie regularnie ewoluowało. Czytelnik powinien zapoznać się z dokumentem sekwencyjnie, przynajmniej za pierwszym razem.

Ten dokument zakłada pewną biegłość w Scrumie oraz znajomość powiązanej z nim terminologii. Przydatne może być wcześniejsze przeczytanie Scrum Guide’a 2020 przed zapoznaniem się z niniejszym tekstem. Przypisy mają ułatwić dotarcie do tekstów źródłowych. Dodatek i przypisy stanowią okazję do pogłębienia wiedzy oraz dalszych badań dla szerszego i głębszego zrozumienia tematu.

Praktycy oraz interesariusze powinni wdrażać Scrum tam, gdzie jest to odpowiednie, kierując się sprawczością, poczuciem pilności, odwagą, przejrzystością, inspekcją, adaptacją, rytmem i rezyliencją, oraz stale się doskonalić, by wspierać cele produktu i organizacji. Oczekuje się, że wdrożenia Scrum przekroczą wytyczne przedstawione tutaj – zarówno w zakresie teorii, ról, artefaktów, wydarzeń, skalowania, jak i wszystkich innych aspektów omawianych w niniejszym dokumencie – i w ten sposób zainspirują trwałą ciekawość do eksplorowania, kwestionowania status quo i ciągłego doskonalenia.

To Rozszerzenie zostało zaprojektowane, aby wspierać wszystkie aspekty dostarczania produktów przez samoorganizujący się Scrum Team (49), motywowany potrzebami lub oczekiwaniami interesariuszy w odpowiedzi na problemy lub szanse. Dotyczy to m.in. odkrywania produktu, rozwoju, dostarczania oraz realizacji wartości. Choć Scrum pierwotnie wywodzi się z obszaru tworzenia oprogramowania, został szeroko zaadaptowany w różnych dziedzinach, umożliwiając dostarczanie wartości dzięki pracy o złożonym charakterze (30-35). Wraz z rozszerzaniem się jego zastosowania, specjaliści tacy jak inżynierowie, programiści, badacze, analitycy, prawnicy, specjaliści marketingu oraz naukowcy coraz częściej z powodzeniem stosują Scrum w swoich obszarach.

Wartość dla interesariuszy odnosi się do wszelkich odczuwalnych potrzeb, które interesariusze (w tym m.in. klienci, decydenci, użytkownicy) uważają za istotne i które zespół dostarcza. Jednak interesariusze nie zawsze są świadomi tego, co mogłoby być dla nich wartościowe. Obserwacje lub dowody mogą celowo lub przypadkowo ujawniać wartość oraz wpływać na priorytety. Wraz z pojawianiem się nowych informacji potencjalnie wartościowe elementy powinny być identyfikowane, poddawane inspekcji, analizowane i adaptowane. Wartość pozostaje hipotetyczna do momentu jej potwierdzenia przez dowody, takie jak obserwacje czy mierzalne rezultaty (outcomes).

Scrum w pigułce

Scrum to framework do dostarczania złożonego (30-35) Produktu, w którym wiedza ekspercka jest cenna, lecz niewystarczająca, a zależności przyczynowo-skutkowe są zrozumiałe dopiero z perspektywy czasu. Scrum obejmuje pełny cykl życia Produktu, w tym (choć nie jest do tego ograniczony) tworzenie, zastępowanie, utrzymywanie, adaptowanie, ciągłą zmianę, oraz wycofywanie Produktów lub ich funkcjonalności. Scrum pomaga osobom, zespołom i organizacjom zachować elastyczność oraz tworzyć wartość poprzez dostosowywanie się do zmian.

Scrum pomaga rozwijać środowisko sprzyjające zrozumieniu i spójnemu reagowaniu na potrzeby Interesariuszy. Iteracyjne i przyrostowe podejście Scruma ogranicza ryzyko oraz wspiera ciągłe usprawnianie. Scrum pomaga zespołowi osiągnąć równowagę pomiędzy eksplorowaniem problemów, odkrywaniem potrzeb Interesariuszy (w tym, lecz nie wyłącznie, klientów), dostarczaniem rozwiązań, proaktywnym zarządzaniem ryzykiem oraz walidowaniem wartości.

Ryzyko to każdy czynnik, który może skutkować negatywnymi konsekwencjami w przyszłości. Ponieważ ekspozycja na ryzyko pozostaje nieprzewidywalna nawet wraz z upływem czasu, kluczowe jest bycie przygotowanym. Ekspozycja ta może obejmować (choć nie jest do tego ograniczona) ryzyko rynkowe, dopasowanie problem-rozwiązanie (problem-solution fit), dopasowanie produkt-rynek (product -market fit), technologię, wykrywanie sygnałów, responsywność, zgodność regulacyjną, działania naprawcze czy niewłaściwe kompromisy. Scrum wspiera proaktywne zarządzanie ryzykiem oraz odkrywanie możliwości.

Scrum zachęca do zmniejszania dystansu między Interesariuszami i ich problemami oraz możliwościami a osobami, które się nimi zajmują.

W pigułce Scrum opiera się na środowisku, w którym:

1. Interesariusze Wspierający (dalej nazywani Supporterami) proaktywnie wspomagają wdrożenie Scruma, przy wsparciu i przewodnictwie przez Scrum Mastera.
2. Product Owner ustala Cel Produktu, kluczowy dla dostarczania wartości Interesariuszom.
3. Samozarządzający się Scrum Team (49) definiuje, doprecyzowuje i przekształca wybrane prace w wartościowe outcomes.
4. Scrum Team i Interesariusze dokonują inspekcji rezultatów w trakcie Sprintu i dostosowują działania.
5. Supporterzy pomagają Scrum Teamowi prosperować.
6. Powtórz.

Wydanie to proces udostępniania nowej lub zaktualizowanej wersji Produktu Interesariuszom (w tym, ale nie tylko klientom, decydentom i użytkownikom końcowym). Oznacza punkt zwrotny w cyklu rozwoju i reprezentuje przejście Produktu od wytwarzania do momentu, gdy staje się dostępny do użycia, oraz potencjalnej realizacji wartości dla Interesariuszy.

Scrum jest celowo niekompletny. Zamiast narzucać szczegółowe procesy, dostarcza framework, który kieruje relacjami i celowymi interakcjami. Różne procesy, techniki i metody mogą uzupełniać Scrum, ale ich zastosowanie zależy od kontekstu i różni się w zależności od różnych zastosowań Scruma.

Scrum integruje się z istniejącymi praktykami lub, w niektórych przypadkach, czyni je niepotrzebnymi lub przestarzałymi. Poprzez przejrzystą ocenę efektywności Scrum Teamu, Supporterów, obecnej kadry zarządzającej, środowiska pracy i technik, Scrum umożliwia ciągłe usprawnianie.

W kontekście pracy opartej na wiedzy, termin Scrum, zapożyczony z rugby, został ukuty przez (Hirotakę) Takeuchiego i (Ikujiro) Nonakę (29) do opisania zespołów, które pracowały w ten sposób i gdzie wiedza była szybko rozprzestrzeniona w całej organizacji w celu dostarczania znakomitych Produktów.

Teoria wspierająca i uzupełniająca

Scrum opiera się na samozarządzającym się Scrum Teamie (49), emergencji, empiryzmie (67) oraz myśleniu lean (63). Wspierają go poniższe uzupełniające teorie oraz idee takie jak:

• Odpowiedzialność (Accountability),
• Ograniczanie marnotrawstwa niedodającego wartości (w tym nieefektywności organizacyjnych),
• Formułowanie pracy jako problemów lub szans,
• Discovery, dostarczanie i realizacja wartości, oraz
• Ciągłe usprawnianie.

Złożoność - Dlaczego Scrum?

W przypadku złożonej pracy, takiej jak budowanie Produktów, niewiadomych jest więcej niż wiadomych, sama wiedza ekspercka jest cenna, lecz niewystarczająca, a zależności przyczynowo-skutkowe są czytelne dopiero z perspektywy czasu. Myślenie o złożoności (30-35) dostarcza cennych narzędzi i idei oraz ułatwia wgląd w problemy. Członkowie Scrum Teamu potrzebują czasu na przemyślenia, wzajemne wsparcie, wprowadzenie poprawek lub zmianę kierunku. Różnorodność poznawcza i empiryzm mogą pomóc w radzeniu sobie ze złożoną pracą.

Wszystko, co uważa się za „znane”, w tym rynek i Interesariusze (nie ograniczając się do klientów), może okazać się błędne. Niektóre oczekiwania, potrzeby lub pragnienia mogą z czasem wyłaniać się lub tracić znaczenie i pilność. Podejście empiryczne dostarcza mechanizmy do testowania założeń oraz inspekcji i adaptacji.

Zasadniczo, nic nie pozostaje w tej samej przestrzeni na zawsze. Scrum Team może znajdować się na granicy chaosu, badając i realizując coś bezprecedensowego, czego nigdy wcześniej nie robiono. Z czasem, gdy odkrywane są wzorce i heurystyki, sytuacja staje się mniej chaotyczna, a bardziej złożona. Po pewnym czasie, w danej sytuacji, Scrum Team może przesunąć się bliżej przestrzeni uporządkowanej, co jest trudne, lecz możliwe do zaplanowania. Może się także zdarzyć odwrotnie. Dobrą praktyką dla Scrum Teamu jest zatrzymanie się i zastanowienie, czy naprawdę znajduje się w tej przestrzeni, którą zakładał dla konkretnej sytuacji. Kluczowe jest to, że rozwój produktu często wiąże się z nieprzewidywalnością, a Scrum może być bardziej użytecznym podejściem niż metody oparte na złudzeniu przewidywalności.

Możliwości płynące z emergencji poprzez Inspekcję i Adaptację odnoszące się do tego kto, dlaczego, co, jak, gdzie i kiedy są liczne. Ważne jest, aby wyciszać to, co nie działa, a wzmacniać to, co działa. Transparencja, Inspekcja i Adaptacja ukierunkowane na ustalone cele, oparte na informacji zwrotnej z wyników (result feedback) (a także skutkach niezamierzonych), umożliwiają tworzenie wartości, generowanie spostrzeżeń, identyfikację ryzyk i podważanie przyjętych założeń; może to wspierać ciągłe usprawnianie.

Buduj zaufanie poprzez samozarządzający zespół, Inspekcję, Adaptację, dostarczanie wartościowych wyników pracy oraz odkrywanie nowych spostrzeżeń.

Emergencja

Emergencja (71) to zjawisko, które zachodzi, gdy znaczące wzorce lub zachowania wyłaniają się z interakcji w ramach złożonych (30-35) systemów-wzorców, których nie można przewidzieć, patrząc jedynie na poszczególne części. W Scrumie emergencja nie jest ściśle kontrolowana, lecz kierowana ograniczeniami umożliwiającymi (enabling constraints), takimi jak timeboxy, role oraz pętle informacji zwrotnej, które tworzą warunki dla samozarządzania i adaptacyjności bez narzucania dokładnych outcomes. Te struktury działają jak „wyspy” na morzu nieprzewidywalności, podobnie jak w systemach fizycznych mogą spontanicznie formować uporządkowane wzorce pośród losowości, co opisał Stephen Wolfram (38). Kluczowe jest to, że struktura Scruma zapewnia zespołom wystarczające wskazówki, aby mogły się samozarządzać i pozwalały na wyłanianie się nowych rozwiązań, zamiast dyktować każdy szczegół.

Na Scrum Teamy, działające jako złożone systemy adaptacyjne, wpływa się (a nie kieruje nimi) poprzez krótkie, równoległe eksperymenty o kontrolowanym ryzyku (safe-to-fail) oraz ciągłą informację zwrotną. Wzorce (53) takie jak Swarming, Stabilne Zespoły czy Kaizen pomagają identyfikować i kształtować zachowania emergentne¹. Scrum zamiast wymuszać rezultaty, umożliwia Scrum Teamowi odkrywanie pożądanych wzorców, w tym innowacyjnych rozwiązań czy nowych metod pracy, wzmacniając je, a jednocześnie ograniczając te niekorzystne.

Zgodnie z tym podejściem samozarządzanie (49) nie jest czymś, co można zaprojektować odgórnie, lecz czymś, co powinno być odkrywane w odpowiednim środowisku - środowisku, które doświadcza się jako celowe, spójne i żywe, nawiązując do koncepcji Christophera Alexandra o „jakości bez nazwy” (Quality Without a Name) (39). Ostatecznie Scrum traktuje emergencję nie jako ryzyko do wyeliminowania, lecz jako siłę, którą należy pielęgnować, aby osiągnąć znakomitość w rozwoju Produktu.

Samozarządzający Scrum Team

Samozarządzający (49) Scrum Team sprawdza, czy znajduje się na właściwej ścieżce, podejmuje działania, gdy tak nie jest, decyduje jak pracować, rozwiązuje konflikty w Scrum Teamie oraz naprawia problemy w jego obrębie. Zasadniczo oznacza to, że menedżerowie (111), jeśli są częścią otoczenia, nie mówią Scrum Teamowi co robić ani nie decydują, którego członka Scrum Teamu wziąć na stronę, aby rozwiązać problemy, bezpośrednio lub pośrednio. Jeśli menedżerowie istnieją, to generalnie lepiej, jeśli wykazują przywództwo (leadership).

Samozarządzające Scrum Teamy zorganizowane wokół wartości są kluczowe dla kreatywnego rozwiązywania problemów i uchwycenia emergencji; poleganie na niesamozarządzających Scrum Teamach utrudnia radzenie sobie ze złożonością (30-35). Samozarządzających Scrum Teamów (49) nie należy mylić z indywidualnym samozarządzaniem. To płynna współpraca pozwala na wyłonienie się świetnego zespołu. Ułatwienie autonomii zespołu i bardziej efektywnego podejmowania decyzji w strukturze niehierarchicznej może pomóc Scrum Teamom w usprawnieniu ich samozarządzania.

Profesjonalizm

Profesjonalizm polega na dążeniu do doskonałości i współpracy w dostarczaniu wartości w sposób pełen szacunku, transparentny i z poczuciem odpowiedzialności (accountability). Bycie profesjonalistą oznacza, że zawsze będzie się robić pewne rzeczy, a innych nigdy, niezależnie od okoliczności.

Bycie Profesjonalistą oznacza przejęcie pełnej odpowiedzialności (accountability) za Produkt, od kołyski po grób, przez cały jego cykl życia. Bycie profesjonalistą obejmuje prace utrzymaniowe, często w formie administracji systemów, i zapewnia doskonałe możliwości uczenia się dla Product Developerów dzięki informacji zwrotnej z rezultatów prac inżynierskich.

W kontekście rozwoju oprogramowania profesjonalizm obejmuje - choć nie jest do tego ograniczony - doskonałość techniczną (technical excellence) (112). Doskonałość techniczna obejmuje - choć nie jest do tego ograniczona - następujące elementy: Specification by Example, Clean Code, Unit Testing, Test-Driven Development, Test Automation, Continuous Integration, Continuous Delivery, Architecture and Design, Acceptance Testing oraz celowe i intencjonalne uwzględnienie testowania.

Myślenie Lean

“Myślenie Lean (63) redukuje marnotrawstwo w pracy i sposobie jej wykonywania oraz koncentruje się na przepływie wartości i ciągłym doskonaleniu.” Zasady Lean są zbudowane na ciągłym usprawnianiu i szacunku dla ludzi. Skupiając się na zasadach Lean, organizacje mogą poprawić skuteczność przy najniższych długoterminowych kosztach i dostarczać lepszą wartość klientom, jednocześnie wspierając atmosferę ciągłego uczenia się i rozwoju.

Empiryzm

Empiryzm (67) to zasada podejmowania decyzji w oparciu o obiektywne lub obserwowalne dowody w cyklach uczenia się, często o charakterze eksploracyjnym. Może być on przydatny w sytuacjach, kiedy sama wiedza ekspercka nie wystarcza. Scrum jest oparty na empiryzmie. Decyzje są podejmowane w oparciu o dowody lub to, co zostało zaobserwowane. Podejście empiryczne obejmuje ciągłą obserwację, rozwój lub udoskonalanie teorii, operacjonalizację oraz testowanie i modyfikowanie, w celu ustanowienia skutecznych pętli zwrotnych.

Empiryzm może pomóc Scrum Teamom dostarczyć coś, co Interesariusze uznają za wartościowe, gdy co lub jak jest niepewne. Scrum polega na uczynieniu tego, co nieprawdopodobne prawdopodobnym przez odkrywanie, dostarczanie i realizację wartości; często wiąże się to z kompromisami lub eksperymentowaniem. Eksperymenty są generalnie oparte na testowalnych hipotezach, ale czasami na uzasadnionych przypuszczeniach. Kluczową odpowiedzią na eksperymentowanie jest podejmowanie decyzji w oparciu o dowody [dane dostępne po przeprowadzeniu eksperymentu].

Zatrzymanie się i refleksja łączą elementy empiryzmu i myślenia Lean, tworzą podstawę dla Transparencji, Inspekcji i Adaptacji w kierunku Celu Produktu oraz pomagają Scrum Teamowi i Supporterom doskonalić siebie i swoje otoczenie.

Efektywne wdrożenie Scruma zmniejsza dystans pomiędzy Interesariuszami przedstawiającymi problemy lub możliwości a osobami, które się nimi zajmują. Zmniejszenie tego dystansu następuje dzięki utrzymywaniu konkretnych i znaczących celów oraz szybkiemu i częstemu dostarczaniu wartości. Interesariusze często mylnie zakładają pewność odnośnie tego, co i jak powinno być zrobione. Scrum Team często mylnie zakłada pewność odnośnie tego, kto zostanie dotknięty zmianami. Inspekcja i Adaptacja powinny być cenione wyżej niż dotrzymywanie obietnic czy służenie niewłaściwym Interesariuszom. Każde założenie może być błędne.

Kadencja

Praca w Sprintach zapewnia stały rytm, który pomaga Scrum Teamowi skupić się na jasnych, krótkoterminowych celach. Ta kadencja wspiera regularną Inspekcję i Adaptację, umożliwiając Scrum Teamowi uczenie się i dostosowywanie w oparciu o informację zwrotną. Z czasem buduje zrównoważone tempo dostarczania, poprawiając przewidywalność i wspierając ciągłe usprawnianie.

Trzy Filary Empirycznej Kontroli Procesu w Scrumie

Empiryzm w swojej istocie jest filozofią, według której wiedza pochodzi z doświadczenia i obserwacji. Wartościowe spostrzeżenia powstają z ciekawości, doświadczenia, eksperymentowania, danych, wizualizacji i obserwacji. Empiryczna kontrola procesu (64-66) to metoda zarządzania złożonymi (30-35) procesami, takimi jak te w Scrumie, poprzez adaptację opartą na obserwowanych rezultatach, opierającą się na trzech filarach: Transparencji, Inspekcji i Adaptacji.

Transparencja (Transparency)

Transparencja jest filarem Scruma. Ujawnia rzeczywistość i zapewnia klarowność pracy, umożliwiając empiryzm. Dzięki Transparencji uzyskujemy dokładniejsze postrzeganie rzeczywistości, stanowiące punkt wyjścia do Inspekcji i Adaptacji. Emergentny proces, praca oraz jej rezultaty muszą być widoczne dla osób wykonujących pracę lub otrzymujących jej wynik (dalej output²) w postaci (realizowanych) celów, elementów Backlogu Produktu oraz powiązanych wyników w postaci Incrementów.

Ważne decyzje podejmowane są w oparciu o artefakty, eksperymenty, wydania lub informacje zwrotne dotyczące rezultatów. Niska Transparencja może utrudniać Inspekcję, prowadząc do decyzji, które zmniejszają wartość i zwiększają ryzyko. Transparencja umożliwia Inspekcję.

Informacja zwrotna o rezultatach to dane - najlepiej zarówno ilościowe, jak i jakościowe - które mogą wynikać ze zmian w Produkcie lub jego otoczeniu. Wpływają one na wartość dostarczaną Interesariuszom, nakład pracy, zaangażowane środki lub poniesione koszty. Ludzie nie są zasobami.

Osiągnięcie Transparencji jest nierealistyczne i potencjalnie niemające zastosowania, jeśli istnieją nieefektywności instytucjonalne lub brakuje zaufania. W efekcie Scrum może uwidocznić instytucjonalne nieefektywności, a przy wspólnej woli możliwe jest budowanie zaufania.

Inspekcja

Inspekcja jestem filarem Scruma. Inspekcja to patrzenie na rzeczywistość, z uwzględnieniem kierunku rozwoju Produktu (Celu Produktu) oraz skuteczności działania Scrum Teamu i Interesariuszy. Inspekcja umożliwia Adaptację. Inspekcja to celowe spojrzenie na rzeczywistość w oparciu o to, co wcześniej stało się transparentne, w tym o dowody lub obserwacje. Aby wspierać Inspekcję i Adaptację, Scrum zapewnia rytm w postaci swoich wydarzeń.

Artefakty Scruma, powiązane z nimi zobowiązania oraz postęp w kierunku uzgodnionych celów muszą być często i dokładnie poddawane Inspekcji w celu wykrycia emergencji (71). Inspekcja artefaktów, eksperymentów, wydań, rynku lub informacji zwrotnej dotyczącej rezultatów może prowadzić do nowych wniosków lub efektów ubocznych. Efekty uboczne to nieoczekiwane lub niezamierzone rezultaty lub konsekwencje.

Inspekcja bez Transparencji jest niepełna, wprowadza w błąd i prowadzi do marnotrawstwa.

Adaptacja

Adaptacja jest filarem Scruma. Uwzględniając kierunek rozwoju Produktu, oczekuje się, że Scrum Team oraz Interesariusze dostosują się do rzeczywistości w momencie pojawienia się możliwości usprawnień, takich jak rezultaty eksperymentów, nowe spostrzeżenia, ryzyka lub szanse. Adaptacja staje się trudniejsza, gdy istnieją instytucjonalne nieefektywności lub gdy osoby zaangażowane nie są gotowe, chętne lub zdolne do wykonania tego, co jest konieczne.

Adaptacja rozpoczyna się od zaakceptowania „rzeczywistości” w oparciu o dowody. Adaptacja typowo zachodzi w Artefaktach Scruma, powiązanych z nimi zobowiązaniach, Scrum Teamie, Interesariuszach, liderach oraz organizacji. Jeżeli jakiekolwiek aspekty odbiegają od akceptowalnych granic, lub gdy powstały Produkt jest nieakceptowalny, niezbędne jest jak najszybsze wprowadzenie zmian korygujących kurs.

Bez Adaptacji Transparencja i Inspekcja tracą sens.

Wartości Scruma

Wartości Scrumowe - Skupienie, Otwartość, Zaangażowanie, Odwaga oraz Szacunek - pomagają stworzyć środowisko Scrum Teamu wspierające bezpieczeństwo psychologiczne i pozytywną współpracę, zgodne z zasadami zidentyfikowanymi przez neuronaukę jako korzystne dla uczenia się i efektywnej pracy zespołowej. Należy zawsze uwzględniać kontekst.

Wartości Scrumowe wzmacniają Transparencję oraz zaufanie, zapewniając spójność słów i czynów. Razem tworzą solidny fundament współpracy, wydajności oraz spójności działania w Scrum Teamie.

Skuteczne wdrożenie Scruma zależy od tego, czy Scrum Team oraz Supporterzy (i inni Interesariusze) dają przykład profesjonalizmu. Wartości Scrumowe mogą pomóc poprawić zaufanie pomiędzy Scrum Teamem a Interesariuszami. Zachęcają również do etycznej postawy, odpowiedniego słownictwa, tonu, sposobu pracy, zachowań oraz działań budujących zaufanie. Pomagają także zmniejszyć lub uniknąć rozbieżności między słowami a działaniami.

Scrum Team oraz Supporterzy zgadzają się na Otwartość co do wszelkich prac oraz wyzwań. Pokora wspiera Otwartość. Otwartość wymaga zaufania, a zaufanie wymaga otwartości. Scrum Team oraz Supporterzy powinni prosić o konstruktywny feedback oraz dzielić się nim. Rutynowo współpracują i uczą się poprzez rozmowy umożliwiające szeroki przepływ informacji (high-bandwidth conversations) oraz jakościowy lub ilościowy feedback.

Rozmowy umożliwiające szeroki przepływ informacji to rozmowy wspierające komunikację, pozwalające na najbogatszą, najszybszą i najbardziej klarowną wymianę informacji. Typowo obejmują one rozmowy twarzą w twarz - osobiście, poprzez wideokonferencje, zarządzanie wizualne lub tablice (fizyczne lub cyfrowe), gdzie uczestnicy mogą wykorzystać nie tylko słowa, lecz także ton głosu, mimikę, rysunki czy mowę ciała do pełnego wzajemnego zrozumienia.

Ponieważ Sprinty są krótkie, wszelkie niepowodzenia powinny być niewielkie i szybko identyfikowane, a ryzyko zarządzane jest poprzez szybki i otwarty feedback. Być może jedyną prawdziwą porażką jest brak uczenia się.

Scrum Team oraz Supporterzy powinni mieć Odwagę, aby postępować właściwie oraz stawiać czoła trudnym wyzwaniom. Powinni odważnie eksplorować nieznane, zmieniać kierunki działań, prosić o informacje i dzielić się nimi oraz angażować się w pełne szacunku spory, np. zdrowe konflikty i konstruktywny sprzeciw. Scrum Team powinien prosić o pomoc Supporterów i liderów, jeśli jest potrzebna.

Scrum Team Zobowiązuje się (commits) do realizacji Celu Sprintu oraz wzajemnego wspierania się. Zaangażowanie (Commitment) oznacza wykonanie odpowiednich prac w kierunku realizacji Celu Sprintu zgodnie z Definition of Output Done najpóźniej przed zakończeniem Sprintu, a najlepiej znacznie wcześniej. Zaangażowanie oznacza także osiąganie pożądanych outcomes poprzez realizację wartości.

Podstawowym obiektem Skupienia jest osiągnięcie możliwie najlepszego postępu w kierunku Celu Sprintu. W drugiej kolejności celem jest osiągnięcie możliwie najlepszego postępu w kierunku Celu Produktu. Supporterzy Zobowiązują się do zapewnienia bezpieczeństwa psychologicznego i środowiska dla Scrum Teamu do dostarczania Incrementów; Skupiając się Scrum Team oraz Supporterzy Zobowiązują się do znalezienia czasu na ciągłe uczenie się i adaptację oraz transfer wiedzy między Scrum Teamami dla zapewnienia długoterminowej skuteczności. Scrum Team oraz Interesariusze powinni celowo podejmować kwestie kompromisów, w tym rozważać krótkoterminowe korzyści wobec długoterminowych konsekwencji.

Scrum Team oraz Supporterzy (i inni Interesariusze) okazują sobie Szacunek jako profesjonalistom; Szanują różnorodność doświadczeń i perspektyw oraz konstruktywnie podchodzą do sporów. Zachowania oparte na Szacunku wspierają zaufanie. Scrum Team oraz Supporterzy powinni kwestionować idee lub podejścia, a nie osoby, w celu znalezienia skuteczniejszych rozwiązań.

Szacunek pomaga uniknąć traktowania pozostałych Wartości Scrumowych jako broni (weaponization). Okazywanie Szacunku może obejmować (ale nie ograniczać się do): szczere pochwały, wzajemne wsparcie, pokorę, bezpieczeństwo psychologiczne, konstruktywną niezgodę oraz różnorodność poznawczą.

Członkowie Scrum Teamu oraz Interesariusze mogą spojrzeć na Wartości Scrumowe przez pryzmat modelu OODA Johna Boyda (99, 100, 102). OODA został stworzony przez pułkownika Johna Boyda, aby pomóc pilotom podejmować szybkie, inteligentne decyzje w szybko zmieniających się sytuacjach, przechodząc przez cztery etapy: obserwowanie (Observe), orientowanie (Orient), decydowanie (Decide) oraz działanie (Act). To prosty, ciągły, iteracyjny i potężny sposób radzenia sobie z niepewnością - na przykład zauważanie zmian rynkowych (Observe), analizowanie trendów i ryzyk (Orient), wybieranie funkcjonalności Produktu do przetestowania (Decide) oraz dostarczanie ich (Act). OODA pomaga zachować elastyczność i efektywnie reagować na zmieniające się okoliczności. Scrum może usprawnić OODA.

Poszczególni członkowie Scrum Teamu mogą patrzeć na Wartości Scrumowe przez pryzmat OODA, wykorzystując Scrum do wyłaniania się rozwiązań. W kontekście Scruma, Wartości Scrumowe obejmują wszystkie etapy OODA, szczególnie pomagając w następujący sposób:

• Obserwowanie - Otwartość i Szacunek mogą wspierać zbieranie wszystkich istotnych dowodów oraz różnorodnych perspektyw.
• Orientowanie - Odwaga jest potrzebna do interpretacji rzeczywistości, nawigowania w niepewności oraz podejmowania decyzji o adaptacji lub zmianie kierunku.
• Decydowanie - Wymaga terminowej analizy, jak np. refinement Backlogu, oraz wprowadzenia potencjalnych kolejnych kroków do Skupienia poprzez równoległe eksperymenty.
• Działanie - Przy klarowności tego, “co”, “dlaczego” i “przez kogo” ma być zrobione, Zaangażowanie może napędzać skuteczne wykonanie w ramach ograniczeń, takich jak timeboxowane Sprinty, sprzyjając wyłanianiu się rozwiązań.

Więcej wspierających i uzupełniających teorii

Myślenie produktowe (Product thinking)

Ludzie konsumują Produkty (w tym usługi), nie projekty. Produkt jest nośnikiem wartości, równoważącym perspektywę krótkoterminową i długoterminową. Dlatego w Scrumie mamy Product Ownera, a nie Project Ownera. Produkty mają długie cykle życia i wymagają wspierania przez cały okres istnienia, podczas gdy projekt jest ograniczony czasowo i często pozostawia „osierocony” Produkt po zakończeniu realizacji.

Myślenie produktowe (Product Thinking) (86-88) odnosi się do napięcia (111), które wynika z faktu, że Produkty muszą skupiać się na wzroście „tu i teraz”, a jednocześnie uwzględniać perspektywę długoterminową - np. zyskanie aprobaty pierwszych użytkowników (early adopters), „przeskakiwanie przepaści” (crossing the chasm) (5), ekspansję, aktualizacje wersji Produktu, ciągłe zmiany, wartość klienta w całym cyklu życia oraz całkowity koszt posiadania (total cost of ownership).

Aby „przeskoczyć przepaść”, konieczna jest zmiana strategii: z koncentrowania się na entuzjastach, którzy są skłonni do ryzyka, na pozyskiwanie bardziej pragmatycznych, ostrożnych decydentów, użytkowników lub innych Interesariuszy, skupiając się na konkretnej niszy rynkowej oraz dostarczając kompletne, niezawodne rozwiązania, które odpowiadają na ich realne problemy. Ten krok ma kluczowe znaczenie w przejściu Produktu od sukcesu niszowego do szerokiego przyjęcia na rynku - od wczesnych użytkowników do tzw. „wczesnej większości”. Wczesna większość często oczekuje jasnych dowodów na niezawodność Produktu oraz jego skuteczność w rozwiązywaniu problemów w określonym kontekście. Dzięki koncentracji na niszy oraz dostarczeniu kompletnego rozwiązania, organizacja może budować wiarygodność, zdobyć klientów referencyjnych i ugruntować swoją pozycję na rynku - skutecznie „przeskakując przepaść” pomiędzy wczesnymi użytkownikami a rynkiem masowym.

Product Ownerzy muszą opanować sztukę równoważenia kompromisów między teraźniejszością a przewidywaną przyszłością (tu i teraz kontra tam i potem) (148) z odwagą, pokorą, poprzez konsultacje, współpracę, zdrowy konflikt itd.

Jeśli osoby zaangażowane w rozwój Produktu kierują się wyłącznie myśleniem krótkoterminowym, mogą doświadczyć długoterminowych skutków ubocznych - takich jak dług techniczny, niska motywacja Scrum Teamu, nadmierne obciążenie pracą czy koncentracja na outputs. Z tego względu należy wdrożyć działania zapobiegawcze, które wspierają podejście długoterminowe.

Dług techniczny to dodatkowa praca, która narasta - świadomie lub nie - w wyniku skrótów w implementacji lub projektowaniu, by coś szybciej dostarczyć. Z czasem dług techniczny spowalnia pracę, podobnie jak prawdziwy dług - z „odsetkami” - ponieważ utrudnia przyszłe zmiany i zwiększa ryzyko. Profesjonaliści starają się minimalizować dług techniczny i niedbałość. Jeśli zdecydują się na jego zaciągnięcie, powinien on być transparentny, a jeśli to możliwe - należy wdrożyć emergentny plan ograniczania ryzyka.

W przypadku Produktów, Scrum wspiera wykonalność, użyteczność, pożądanie, wartość i opłacalność w granicach etycznych (57) poprzez:

• Projektowanie (design) Produktu
• Zarządzanie Produktem
• Celowe uwzględnienie spójnej współpracy Interesariuszy, badań, celów, odkrywania, projektowania, dostarczania i ciągłej realizacji wartości
• W przypadku technologicznych Produktów - poprzez inżynierię Produktu.

Scrum wspiera zdrową równowagę między podejściem krótkoterminowym i długoterminowym. Orientacja na cel umożliwia osiąganie potencjalnych outcomes, kładąc nacisk na wartość i ograniczanie ryzyka. Cel Sprintu (tu i teraz) powinien stanowić krok w stronę Celu Produktu (tam i potem), który z kolei umożliwia długofalowy rozwój. Cel Produktu często wspiera strategię Produktu oraz Wizję Produktu.

Myślenie systemowe

Myślenie systemowe (55) uznaje współzależność elementów w kontekstach organizacyjnych i społecznych, zauważając, że działania w jednym obszarze mogą wywoływać skutki w innych - nie zawsze przewidywalne ani liniowe. Eksperymenty oparte na teorii, pętle informacji zwrotnej i analiza danych po ich zebraniu pomagają ujawniać wartościowe i możliwe do zastosowania spostrzeżenia. Myślenie systemowe dostarcza użytecznych narzędzi i koncepcji oraz ułatwia generowanie wglądów.

Aby organizacja mogła stać się organizacją adaptacyjną (80), należy unikać lokalnych suboptymalizacji, takich jak obniżanie jednostkowych kosztów przy jednoczesnym wzroście kosztów długoterminowych, podważanie celów jakościowych prowadzące do utraty zaufania klientów lub doskonalenie Scrum Teamu, przepływu pracy albo procesu, który w ogóle nie powinien istnieć. W pracy złożonej (30-35) powiązania przyczynowo-skutkowe są zwykle możliwe do uchwycenia dopiero z perspektywy czasu. Pomocne jest jednak rozważenie potencjalnych i rzeczywistych skutków interwencji w ujęciu wstecznym, równoległym i dalszym.

Discovery

Discovery (tj. odkrywanie Produktu) (50-51) często zaczyna się od zrozumienia oczekiwań, potrzeb i pragnień ludzi - poprzez obserwację, analizę, rozmowy i syntezę - w kierunku pożądanego outcome. Po uzyskaniu spostrzeżeń, Scrum Team określa problem lub szansę oraz porządkuje je według potencjalnej wartości. Zespół zbiera pomysły na rozwiązania, unikając ich zbyt wczesnej oceny. Jeśli potencjalna wartość jest wysoka, ale brakuje dowodów na możliwość jej realizacji, Scrum Team powinien przeprowadzić badania, testowanie założeń lub stworzyć proste prototypy, które można przetestować z rzeczywistymi klientami, decydentami lub użytkownikami. Discovery nigdy się nie kończy - warto cyklicznie prowadzić wywiady lub obserwacje klientów, decydentów lub użytkowników.

Discovery to proces uczenia się w kierunku pożądanego outcome, poprzez priorytetyzację, realizowanie, (świadome) niepodejmowanie lub ciągłe udoskonalanie pomysłów na podstawie obserwacji użytkowników, informacji zwrotnych i innych źródeł wiedzy. Akcentuje ono współpracę, kreatywność i gotowość do podejmowania ryzyka - z możliwością niepowodzenia i ponownej próby. Discovery postrzega pracę jako problemy lub szanse i pomaga Scrum Teamowi tworzyć, priorytetyzować i testować możliwe rozwiązania, które równoważą potrzeby ludzi, możliwości techniczne i sens biznesowy - wszystko to dobrze się bawiąc.

Jeśli Discovery jest potrzebne, powinno - w miarę możliwości - być realizowane w sposób spójny ze Scrumem. Na przykład, prace związane z Discovery są ujawniane w Product Backlogu i Sprint Backlogu, członkowie Scrum Teamu praktykują Discovery i inne umiejętności, a zdobyta wiedza omawiana jest w trakcie Sprintu i podczas wydarzeń Scrumowych. W każdym Sprincie powinien powstać co najmniej jeden Increment (a najlepiej również zostać wydany), niezależnie od tego, jak wiele działań odkrywczych zostało wykonanych. Potrzebna jest równowaga: Discovery pomaga uniknąć tworzenia niewłaściwych rozwiązań, ale jego nadmiar może być kosztowny. Ostatecznie najważniejsze jest to, co wynika z informacji zwrotnej.

Przywództwo

Przywództwo to zdolność do wywierania wpływu, prowadzenia i inspirowania grupy ludzi do osiągnięcia wspólnego celu bez wywoływania demotywacji. Inspiruje działania, myślenie i zaangażowanie oraz wyznacza jasny kierunek strategiczny. Obejmuje intencjonalne „Idź, Posłuchaj i Zrozum” (Genchi Genbutsu) (84), czyli zbieranie faktów i obserwacji w celu podejmowania lepszych decyzji.

Przywództwo to dynamiczny proces społeczny, obejmujący odpowiedzialność (responsibility), budowanie relacji i dawanie innym sprawczości. Skuteczne przywództwo prowadzi do współtworzenia kierunku działania, efektywnego dopasowania zasobów i ludzi oraz wzajemnego Zaangażowania członków grupy.

Scrum promuje szczególny rodzaj przywództwa - przywództwo na rzecz odporności organizacyjnej - jako zbiór cech, a nie funkcję kierowniczą. Oznacza to m.in. tworzenie warunków dla samozarządzających Scrum Teamów, klarowności, zaufania, Transparencji, ukierunkowanej emergencji (71), poczucia spełnienia w pracy, gotowości na niepewność (72), porażki, gromadzenia dowodów dla lepszego podejmowania decyzji, proaktywnego zarządzania ryzykiem i eliminowania nieefektywności organizacyjnych.

Przywództwo powinno być obecne na wszystkich poziomach i we wszystkich kierunkach, sprzyjając refleksji we właściwym czasie. Powinno być stanowczo zorientowane na wartość, a jednocześnie empatyczne i etyczne. Wymaga ciągłego wpływu na zmiany w przepływach pracy, procesach, systemach i środowisku pracy - w tym (choć nie jest do tego ograniczone) w obszarach takich jak HR, finanse czy zarządzanie dostawcami. Liderem jest ten, kto przejawia przywództwo.

Product Ownerzy i Scrum Masterzy balansują między przywództwem, autorytetem a subtelną kontrolą, poprzez jasne określenie intencji, wzmacniając inicjatywę i odpowiedzialność (accountability). Wskazują kierunek zamiast mikrozarządzać - tak, aby Scrum Team rozumiał wizję i cele, miał autonomię działania i ponosił odpowiedzialność (accountable) za outcomes. W razie potrzeby interweniują zdecydowanie, zachowując przy tym autonomię odpowiedzialności (accountabilities) w ramach Scrum Teamu. Developerzy Produktu przejawiają przywództwo poprzez samozarządzanie, profesjonalizm i ukierunkowanie na cel; samozarządzanie wiąże się z odpowiedzialnością (responsibilities). Supporterzy okazują przywództwo, wspierając usuwanie przeszkód krótko- i długoterminowych. Poprawiają spójność procesów zarządczych ze Scrumem. Jeżeli zostaną o to poproszeni, wspierają emergentną zmianę [stopniowo wyłaniającą się zmianę] w konkretnym kierunku.

Myślenie od podstaw (First Principles Thinking)

Myślenie od podstaw to metoda rozwiązywania problemów polegająca na rozłożeniu wyzwań na ich najbardziej fundamentalne prawdy i poszukiwaniu rozwiązań od nowa. Zamiast opierać się na analogii czy konwencjach, podejście to pyta: „Co wiemy na pewno?” i buduje rozumienie oraz rozwiązania w oparciu o te fundamenty. Przykłady obejmują, ale nie ograniczają się do:

• zachęcania Scrum Teamu do skupienia się na podstawowych czynnikach skuteczności, adaptacyjności (80) i terminowości - takich jak autonomia, Transparencja i Adaptacja - zamiast ślepego podążania za procesami lub kopiowania cudzych praktyk;
• kwestionowania każdego założenia i budowania rozwiązań na faktach oraz kluczowych zasadach, co może prowadzić do przełomów;
• promowania nieszablonowego myślenia, ciągłego usprawniania i Odwagi do podważania status quo - co odblokowuje kreatywność i umożliwia transformacyjne rezultaty.

Ludzie i Zmiana

Nie należy lekceważyć trudności związanych z wdrażaniem Scruma. Scrum oferuje zestaw zasad przewodnich poprzez swoje elementy. Stanowi też podejście umożliwiające powrót do fundamentalnych zasad.

Scrum nie polega na wdrożeniu narzędzi, a jednocześnie nie kończy się na usunięciu przeszkód (impediments). Przeszkoda w Scrumie to wszystko, co blokuje lub spowalnia postęp. Kluczowe jest intencjonalne, nieustępliwe i wytrwałe podejście do ludzi, zmian i komunikacji. Zmiana często obejmuje rozwój ludzi, projektowanie, przepływy pracy, procesy, systemy, postawy, zachowania, język, nawyki i klimat pracy. Kultura jest wynikiem emergencji.

Skuteczna adopcja Scruma wykorzystuje podejście emergentne, posiada skutecznych agentów zmiany i angażuje entuzjastyczne wsparcie tych, których dotyczy lub którzy mają wpływ. Intencjonalność i codzienny postęp we wdrażaniu są kluczowe - praca nad wdrożeniem nie powinna być ostatnim zadaniem realizowanym dopiero wtedy, gdy wszystko inne zostało już zrobione.

Należy zacząć od metodycznej emergentnej zmiany w określonym kierunku. Dążyć do tego, by zmiana emergentna stała się tak naturalna, że stanie się częścią zaplanowanej pracy. Adopcja Scruma ma kierunek, ale nie ma z góry określonego celu końcowego. Zmiana jest emergentna, a zatem nieprzewidywalna. Ciekawość wspiera schemat: dostrzegaj - słuchaj - ucz się - dostosuj w określonym kierunku. Kluczowe jest budowanie relacji i rozumienie perspektyw, słuchanie tego, co niewypowiedziane, i zauważanie tego, co się nie dzieje. Zmiana to ciężka, ale satysfakcjonująca praca.

Role Scrumowe w Rozszerzeniach

Cztery role w Scrumie to: Product Owner, Product Developerzy, Scrum Master oraz Interesariusz (Stakeholder). Role te darzą, nagradzają i zdobywają zaufanie, oraz umożliwiają spójne przywództwo. Tylko trzy z tych odpowiedzialności (accountabilities) - Product Owner, Product Developerzy i Scrum Master - należą do Scrum Team.

Jedna osoba może pełnić więcej niż jedną rolę Scrumową. W takim przypadku należy zachować ostrożność, aby nie przekraczać granic odpowiedzialności. Role w Scrumie zostały zaprojektowane tak, aby utrzymać wzajemny balans.

Scrum Team to zespół, który stosuje Scrum, obejmuje trzy odpowiedzialności (accountabilities) Scrumowe: Scrum Mastera, Product Ownera oraz Product Developerów, rozwiązuje problemy lub wykorzystuje szanse Interesariuszy (w tym, lecz nie tylko, klientów i użytkowników) i dostarcza użyteczne, używalne i potencjalnie wartościowe Incrementy z perspektywy Scrum Teamu i Interesariuszy, prowadząc do osiągnięcia Celu Produktu. W przypadku złożonej pracy (30-35), Scrum Team powinien być niewielki, zróżnicowany poznawczo i samozarządzający się, a jego członkowie[human members]- często wspierani przez technologię - troszczą się o wzajemną pracę i uczą się nawzajem swoich zadań.

Scrum Team powinien być cross-funkcjonalny, czyli multidyscyplinarny, łączący kompetencje z obszaru technologii i domeny biznesowej. W Scrum Teamie nie występuje wyraźna hierarchia. Zespół powinien posiadać wszelkie niezbędne umiejętności i wsparcie, aby:

• prowadzić Discovery (w tym badania i projektowanie),
• dostarczać (w tym inżynierię, gdy to zasadne), oraz
• Walidować realizację wartości (a także użyteczność, pożądalność i wykonalność w granicach etycznych (57)).

Scrum Team, wspierany przez Supporterów, wspólnie zajmuje się obszarem problemowym lub szansą, Discovery Produktu, dostarczaniem, weryfikacją i wbudowywaniem jakości, wejściem na rynek oraz walidacją wartości w kierunku Celu Produktu. Dąży do usprawnień, których wartość przewyższa koszt; jako samozarządzający się Scrum Team (49), samodzielnie decyduje kto, co, jak, kiedy i gdzie wykonuje.

Walidacja wartości to potwierdzenie (lub zaprzeczenie), w ustalonych granicach, że oczekiwany outcome(s) został osiągnięty.

Scrum Team dostarcza Increment(y) w każdym Sprincie, nieustannie sobą samozarządza (49), by znajdować i rozwiązywać problemy, synchronizuje się ciągle i często udostępnia rezultaty. Scrum Team jest wystarczająco mały, by być zwinny, i wystarczająco duży, by wykonać istotną pracę w czasie Sprintu. Czasami mniejsze Scrum Teamy lepiej się komunikują i są bardziej produktywne.

Scrum opiera się na samozarządzających Scrum Teamach (49) działających w ramach określonej struktury organizacyjnej lub Produktowej. Autonomia istnieje, lecz jest ograniczona przez wydarzenia Scrumowe, odpowiedzialności (accountabilities), artefakty, zobowiązania, filary, wartości i potrzeby organizacyjne.

Scrum angażuje grupy ludzi, którzy wspólnie posiadają lub zdobywają wszystkie umiejętności i kompetencje niezbędne do wykonania pracy oraz dzielą się nimi w razie potrzeby. Potrzebne są intencjonalne interakcje, wspierane przez liderów, by zwiększyć szanse na powodzenie.

Należy Skupić się na osiągnięciu Celu Produktu w najbardziej efektywny sposób, przy odpowiednim poziomie inwestycji, dostarczając wartościowe outcomes.

Scrum wspiera zespołową współpracę poprzez zachęcanie do ciągłej interakcji i wspólnej odpowiedzialności (accountability) zamiast pracy sekwencyjnej i działania w silosach. Takie podejście pozwala Scrum Teamowi i Interesariuszom oswajać się z niepewnością (72), umożliwiając szybsze dostosowanie oparte na bieżącym uczeniu się i informacji zwrotnej. Nachodzące się na siebie z natury Discovery, wytwarzanie i walidacja wartości, umożliwiają bardziej adaptacyjne (80), nakierowane na wartość podejście do rozwoju Produktu.

Zachodzące na siebie obszary pracy wspierają wspólną odpowiedzialność (accountability) w Scrum Teamie, co wzmacnia zaangażowanie i zobowiązanie. Scrum Team koncentruje się na odpowiadaniu na wyzwania i wykorzystywaniu szans, zachęca do proaktywnego działania, rozwija zróżnicowany zestaw umiejętności i zwiększa świadomość dynamiki rynkowej wśród wszystkich uczestników.

Scrum Team zajmuje się wszystkimi działaniami związanymi z Produktem - od współpracy z Interesariuszami po walidację wartości, w tym weryfikację, utrzymanie, wsparcie, eksperymentowanie, badania i rozwój oraz wszystko inne, co może być potrzebne. Scrum Team buduje jakość. Supporterzy zapewniają, że organizacja kształtuje odpowiedni klimat i środowisko pracy oraz daje Scrum Teamowi możliwość samozarządzania (49). Praca w Sprintach w zrównoważonym tempie poprawia Skupienie i spójność.

Scrum Team i Interesariusze nie wiedzą, czego się nauczą. Niektóre odkrycia zwiększają pewność, inne powodują wzrost niepewności (72). Pewne kwestie mogą się pojawić, zniknąć, lub stracić na pilności bądź znaczeniu.

Scrum Team posiada autonomię ukierunkowaną. Oznacza to, że ma wolność decydowania o sposobie rozwiązywania problemów przy jednoczesnym skupieniu na wspólnych celach i outcomes, co umożliwia innowacyjność i spójność organizacyjną. Kluczowe jest pielęgnowanie poznawczej różnorodności Scrum Teamu. Wymiana wiedzy, inspiracji i doświadczeń jest bardziej prawdopodobna, gdy członkowie Scrum Teamu współpracują, ufają sobie i praktykują autorefleksję.

Aby osiągnąć sukces, Scrum Team i Supporterzy powinni rozwijać gotowość do oduczania się przestarzałych zasad. Inspekcja i Adaptacja wymagają atmosfery, która antycypuje i toleruje błędy. Kluczowe jest, by krytyka Skupiała się na ideach, a nie na osobach. Wszyscy członkowie Scrum Teamu „grają do tej samej bramki”, wykonując spójną, zachodzącą na siebie pracę, i wszyscy są odpowiedzialni (accountable) za sukces.

Interesariusz

Interesariusz to rola. Interesariuszem jest podmiot, osoba lub grupa zainteresowana wkładem, działaniami i outcomes, mająca na nie wpływ lub będąca nimi dotknięta. Interesariusze mogą mieć bezpośredni lub pośredni interes wewnątrz organizacji lub na zewnątrz, w jej Produktach bądź usługach.

Przykłady interesariuszy obejmują (ale nie ograniczają się do): klientów, decydentów, użytkowników, dostawców, osoby wpływowe, menedżerów, współpracowników, liderów, prawodawców, sponsorów finansowych, ekspertów dziedzinowych oraz osoby odpowiedzialne za governance. Nieożywieni, inni-niż-ludzie Interesariusze, tacy jak prawo czy AI (Sztuczna Inteligencja), również nie powinni być pomijani. Niektórzy Interesariusze mają większy wpływ lub są bardziej dotknięci niż inni, a każdy może mieć inne priorytety. Każdy Interesariusz ma inną siłę oddziaływania lub wpływu.

Klient to każdy Interesariusz, który otrzymuje wartość z Produktu poprzez jego zakup i/lub wybór. Klienci mogą obejmować nabywców (tych, którzy płacą za Produkt lub go pozyskują), decydentów (tych, którzy zatwierdzają lub autoryzują jego wdrożenie) oraz użytkowników końcowych (tych, którzy bezpośrednio korzystają z Produktu). Czasami klient nie jest tożsamy z użytkownikiem końcowym, np. w modelach B2B2C (79) lub B2B2B (78).

Aby adopcja Scruma była skuteczna, kluczowe są regularne, intencjonalne interakcje pomiędzy Interesariuszami (w tym, ale nie tylko, klientami i użytkownikami) a Scrum Teamem.

Użytkownik to Interesariusz, który bezpośrednio korzysta z Produktu, aby osiągnąć określone cele lub rozwiązania problemów. Użytkownicy mają bezpośrednie doświadczenia z Produktem - niezależnie czy jest to usługa, platforma, czy inne doświadczenie - a ich opinie i satysfakcja są kluczowe dla dalszego rozwoju Produktu. Użytkownicy mogą, lecz nie muszą mieć wpływu na decyzje zakupowe, jednak przyswojenie przez nich produktu i ich zaangażowanie są kluczowe dla dalszego sukcesu Produktu. Czasami użytkownik nie jest tożsamy z użytkownikiem końcowym, np. w modelach B2B2C lub B2B2B. Dla skutecznej adopcji Scruma niezbędne są regularne, intencjonalne interakcje między użytkownikami (oraz, gdy to możliwe, z użytkownikami końcowymi) a Scrum Teamem.

Decydent (nazywany przez Jeffa Pattona „wybierającym”) (82) to interesariusz posiadający uprawnienia do zatwierdzania, wyboru lub autoryzowania wdrożenia lub zakupu Produktu. Decydent jest odpowiedzialny (responsible) za zbadanie opcji i podjęcie ostatecznej decyzji, często uwzględniając potrzeby użytkowników i całej organizacji. Decydenci mogą, lecz nie muszą, korzystać z Produktu bezpośrednio, jednak ich wybory bezpośrednio wpływają na to, jakie Produkty zostaną wdrożone i w jaki sposób dostarczana jest wartość innym Interesariuszom. Dla skutecznej adopcji Scruma często lepiej działać mimo niepełnych informacji i wychwytywać pojawiające się informacje zwrotne.

Prawodawcy (oraz, na potrzeby tego dokumentu, wewnętrzni lub zewnętrzni twórcy wytycznych) ustanawiają zasady, polityki i granice działania Produktu. Definiują ramy prawne, regulacyjne lub organizacyjne, które kształtują sposób dostarczania wartości interesariuszom i standardy profesjonalizmu. Dbają o to, by Produkt był zgodny z wymaganiami wewnętrznymi i zewnętrznymi, kierując jego ewolucją i trwałością. Dla skutecznej adopcji Scruma kluczowe jest, by nie przeceniać ani nie bagatelizować wymagań prawnych.

Sponsorzy finansowi zapewniają finansowanie i zasoby dla rozwoju, wdrożenia i doskonalenia Produktu. Oceniają jego wykonalność, wartość i opłacalność, inwestując w oparciu o jego potencjał do ciągłego dostarczania wartości Interesariuszom. Sponsorzy finansowi wpływają na wizję, strategię i cele Produktu, aby zapewnić zgodność z oczekiwanym zwrotem z inwestycji i długoterminową trwałością. Kluczowe dla skutecznej adopcji Scruma są elastyczne podejście i elastyczne finansowanie w odpowiedzi na pojawiające się informacje.

Eksperci dziedzinowi wnoszą głęboką wiedzę lub unikalne umiejętności niezbędne do tworzenia, rozwoju i utrzymania Produktu. Niezależnie od tego, czy koncentrują się na technologii, projektowaniu, zgodności czy konkretnej domenie, eksperci wspierają użyteczność, wykonalność, profesjonalizm i możliwość rozbudowy Produktu, ale nie przeszkadzają samozarządzającemu się Scrum Teamowi (49). Pomagają zidentyfikować i zmniejszyć luki satysfakcji oraz wspierają zdolność Produktu do adaptacji i reprezentowania lub mierzenia emergencji (71). Dla skutecznej adopcji Scruma kluczowe jest wspieranie regularnego transferu wiedzy od ekspertów do Scrum Teamu i w jego obrębie.

Luka satysfakcji (satisfaction gap) oznacza różnicę pomiędzy tym, czego Interesariusze obecnie doświadczają, a tym, jak chcieliby, aby ich doświadczenie wyglądało. Innymi słowy - to różnica między aktualnym poziomem satysfakcji z Produktu a możliwym poziomem.

Governance (ład organizacyjny) to struktury, standardy, regulacje, normy, procesy i praktyki, które świadomie ograniczają i nadają kierunek rozwojowi Produktu, podejmowanie decyzji i odpowiedzialność (accountability). Governance wspiera transparencję i prowadzi do przestrzegania standardów dotyczących wartości, wykonalności i profesjonalizmu. Stanowi mechanizm zarządzania ryzykiem i adaptacji Produktu do zmieniających się potrzeb lub środowisk, wspierając jego trwały i ewolucyjny charakter. Dla skutecznej adopcji Scruma kluczowe jest, aby governance był spójny ze Scrumem, np. poprzez jednoznaczne przypisanie punktu kontaktu do każdego obszaru governance, która ma intencjonalne interakcje z Scrum Teamem w zakresie jakości i zgodności, regularną inspekcję i adaptację governance oraz brak niespodzianek.

Supporterzy

Supporter to szczególny typ Interesariusza. Supporterzy są wspierającymi Interesariuszami i agentami zmiany. Często wchodzą w skład silnej koalicji przewodniej (83), która inspiruje i usuwa czynniki demotywujące. Supporterzy wspierają Scrum Team w rozwoju oraz wpływają na przepływy pracy, procesy, systemy, Produkty, usługi i środowisko pracy w organizacji, aby były spójne z adopcją Scruma i emergencją (71). Supporterzy powinni uczestniczyć tam, gdzie jest to potrzebne lub na życzenie. Tworzenie wartości często wymaga skutecznej i konstruktywnej współpracy z innymi Interesariuszami.

W zależności od wielkości organizacji, do grona Supporterów mogą należeć (choć nie tylko): współpracownicy, decydenci, sponsorzy finansowi, osoby odpowiedzialne za governance, menedżerowie, eksperci dziedzinowi, przedstawiciele marketingu, działu HR, finansów, zakupów oraz wczesnych użytkowników. Supporterzy, którzy nie umożliwiają Scrum Teamom działania zgodnie z zaleceniami zawartymi w niniejszym dokumencie, nie są tak naprawdę Supporterami. W szczególności członkowie zarządów i osoby na najwyższych szczeblach kierowniczych odgrywają kluczową rolę w tworzeniu klimatu, w którym Supporterzy mogą wspierać. Supporterzy powinni wykazywać przywództwo, które Scrum Team doceni.

AI (Sztuczna Inteligencja)

Sztuczna Inteligencja (AI) staje się coraz bardziej integralną częścią środowiska pracy i może znacząco rozszerzyć możliwości Scrum Teamu w obszarach Discovery, podejmowania decyzji, rozwoju Produktu i realizacji wartości.

AI może wspierać Scruma poprzez:

• Empiryczną kontrolę procesu (64-66): analiza wspierana przez AI poprawia Transparencję, Inspekcję i Adaptację,
• Rozszerzenie możliwości poznawczych: AI pozwala członkom Scrum Teamu (ludziom) skupić się na aspektach strategicznych, kreatywnych i etycznych,
• Ciągłą Adaptację Wartości: AI może na bieżąco aktualizować i nadawać priorytety Elementom Product Backlogu, bazując na informacjach zwrotnych od użytkowników w czasie rzeczywistym i obserwowanych trendach,
• Zrozumienie zależności systemowych: AI identyfikuje ukryte współzależności, wspierając podejmowanie decyzji oparte na danych.

Możliwości są nieograniczone. Scrum Teamy mogą wykorzystywać AI do:

• Odkrywania niejasności w tekście i ciągłej inspekcji własnych rekomendacji i wyników pod kątem uprzedzeń, błędów i niezamierzonych konsekwencji,
• Regularnej walidacji i adaptacji modeli oraz aplikacji,
• Wspierania transparencji w porządkowaniu kolejności w Product Backlogu,
• Tworzenia agentów AI jako członków zespołu.
• AI może być pomocne w celowym testowaniu i podważaniu aktualnego sposobu myślenia.

Zagrożenia są równie rozległe. Należy utrzymywać wyraźną odpowiedzialność (accountability) człowieka za wszystkie outcomes (zgodnie z odpowiedzialnościami w Scrumie), traktując AI jako potężnego, lecz nadzorowanego partnera decyzyjnego. Podejście to określa się jako „człowiek w pętli” (human in the loop). Choć AI może wspierać innowacyjność i efektywność przy niskich kosztach, nie zastępuje odpowiedzialności (accountability) człowieka. AI powinno wspierać - a nie zastępować - empiryczną kontrolę procesu w Scrumie (64-66) oraz podejmowanie decyzji zgodne z zasadami etycznymi (57). Scrum Team pozostaje odpowiedzialny (accountable) za dostarczanie wartościowych outcomes, ocenę dowodów i zachowywanie profesjonalizmu.

AI może być narzędziem wspierającym, jeśli jest używane z dobrą intencją. Narzędzia AI powinny być oceniane podobnie jak inne elementy wpływające na stan flow (70) i uczenie się: Czy poprawiają pętle informacji zwrotnej? Czy pomagają szybciej weryfikować założenia? Czy działają, a jeśli tak, to czy działanie to jest etyczne (57)?

Stan flow (70) to stan pełnego zaangażowania i satysfakcji z wykonywanego zadania, w którym działanie i świadomość się zlewają, a czas płynie inaczej.

Scrum zachęca Scrum Team do odpowiedzialnego eksperymentowania z AI, używając małych, czasami odwracalnych prób. Adaptacja i Inspekcja dotyczą nie tylko samego Produktu, ale także sposobu, w jaki AI jest integrowane z jego dostarczaniem.

Należy nadal skupiać się na ludzkiej dynamice pracy zespołowej i współpracy, traktując AI jako potencjalne wsparcie.

Product Developer

Product Developer to rola i odpowiedzialność (accountability). Wszyscy Product Developerzy razem wzięci powinni posiadać wszystkie umiejętności potrzebne do tworzenia Incrementów. Zbiór tych umiejętności nazywany jest często cross-funkcjonalnością.

Product Developer może być człowiekiem lub rozwiązaniem zautomatyzowanym (agentem AI). Product Developerzy (ludzie) są Zaangażowani w tworzenie, eksplorację, inspekcję i adaptację każdego aspektu możliwego do wydania Incrementu w każdym Sprincie. Ich główne Skupienie koncentruje się na trwającym Sprincie. Część ich zdolności operacyjnych jest często przeznaczona na przyszłościowe uszczegółowienie i analizę informacji zwrotnej z rezultatów, efektów ubocznych lub innego uczenia się.

Product Developerzy stosują się do Definition of Output Done i dążą do usprawnień, których wartość przewyższa koszt. Osiągają najlepsze rezultaty, jeśli koncentrują się wyłącznie na jednym Produkcie. Jeśli w danym momencie Product Owner lub Scrum Master wykonuje pracę związaną z elementami Sprint Backlogu, wykonuje ją jako Product Developer.

Product Developerzy powinni przyjmować odpowiednie postawy w zależności od sytuacji - w tym (lecz nie tylko) współtwórców, kreatorów oraz orędowników jakości technicznej, Discovery, dostarczania i walidacji wartości.

Co najmniej jeden Product Developer powinien być człowiekiem. Wielu Product Developerów, który są ludźmi często zwiększa poznawczą różnorodność, co jest pomocne w radzeniu sobie ze złożonością.

Product Developerzy zawsze wspólnie ponoszą odpowiedzialność (accountable) za:

• Tworzenie planu opartego na emergencji w Sprint Backlogu, aby osiągnąć Cel Sprintu,
• Zapewnianie jakości poprzez stosowanie i ulepszanie Definition of Output Done,
• Tworzenie co najmniej jednego użytecznego Incrementu w każdym Sprincie,
• Uczenie się, często w oparciu o dane powiązane z Definition of Outcome Done,
• Codzienną adaptację planu w kierunku Celu Sprintu,
• Jako profesjonaliści, wzajemnie wymagają od siebie odpowiedzialności (accountable), oraz,
• Netto usprawnienia (tj. usprawnienia, których wartość przewyższa koszt).

Kontekst ma znaczenie - kluczowe jest uwzględnienie konkretnych okoliczności. Jednak jako zasada ogólna: Product Developer, który nie chce, nie jest gotów lub nie jest w stanie być profesjonalistą, powinien zrezygnować z roli Product Developera.

Product Owner

Product Owner to rola i odpowiedzialność (accountability). Product Owner musi być człowiekiem. Aby być efektywnym, Product Owner powinien być liderem Produktu. Maksymalizuje on długoterminową wartość i musi wiedzieć, gdzie znajduje się wartość i kiedy jest potrzebna. Oczekuje się, że Product Owner działa na wszystkich poziomach i we wszystkich istotnych obszarach biznesowych. Współpracuje z Interesariuszami, Scrum Masterem i Product Developerami w celu tworzenia wartości.

Product Owner wykorzystuje Product Backlog do określenia, co ma zostać zbudowane i w jakim przybliżonym porządku. Zawsze ma na uwadze Cel Produktu, a jego głównym Skupieniem jest maksymalizacja długoterminowej wartości na każdym etapie.

Analizowanie i szczegółowe opisywanie elementów Product Backlogu to nie to, co definuje Product Ownera. Każda minuta zmarnowana przez brak zaufania do Product Developerów to utracona szansa na myślenie bardziej strategiczne, głębszą współpracę z Interesariuszami lub tworzenie większej wartości. W zależności od sytuacji Product Owner powinien przyjmować odpowiednie postawy, w tym (ale nie wyłącznie) być wizjonerem, reprezentantem klienta, współpracownikiem, osobą wywierającą wpływ, eksperymentatorem, decydentem oraz orędownikiem zaangażowania Interesariuszy, przejrzystości, jakości Produktu i realizacji wartości.

Product Owner ponosi zawsze odpowiedzialność (accountable) za:

• zaangażowanie Interesariuszy, ich samych i zrozumienie ich wpływu, oczekiwań, potrzeb i pragnień;
• ciągłe obserwowanie, słuchanie, uczenie się i dostosowywanie się w razie potrzeby;
• nieustanne równoważenie kompromisów, w tym (ale nie wyłącznie) obejmujących:
  • jakość, szybkość, możliwości, ograniczanie ryzyka, wartość, prostotę (149),
  • Interesariuszy i ich wielość, często konkurujących ze sobą oczekiwań oraz ograniczeń,
  • wartość, atmosferę pracy, potencjalnych klientów;
• rozwijanie i jednoznaczne komunikowanie Celu Produktu;
• rozwijanie i skuteczne przekazywanie spójnej narracji dla Produktu;
• tworzenie i przejrzyste komunikowanie elementów Product Backlogu;
• porządkowanie elementów Product Backlogu;
• zapewnienie transparentności i zrozumienia Product Backlogu;
• skuteczne komunikowanie outcomes popartych miarami określonymi w Definition of Outcome Done;
• podejmowanie ostatecznej decyzji dotyczącej Definition of Outcome Done;
• wspieranie wysokiej jakości tworzenia, discovery, dostarczania i walidacji wartości;
• oraz inne działania związane z zarządzaniem Produktem, jeśli są wymagane.

Product Owner może wykonywać powyższe działania samodzielnie lub współpracować ze Scrum Teamem w celu uzgodnienia, kto będzie odpowiadać (responsible) za wykonanie powyższej pracy. Niezależnie od tego, Product Owner ponosi za nie odpowiedzialność (accountable)³.

Aby Product Owner mógł odnieść sukces, wszyscy Interesariusze i Supporterzy powinni Szanować jego decyzje. Decyzje te są widoczne w treści i kolejności elementów Product Backlogu oraz w poddanym inspekcji Incremencie podczas Sprint Review. Product Owner ma umocowanie płynące z organizacji.

Product Ownership wymaga silnych umiejętności zarządzania Produktem oraz znajomości domeny. Product Owner, który nie posiada tych umiejętności, może potrzebować wsparcia i wskazówek, dopóki ich nie rozwinie. Kontekst ma znaczenie, ale jako ogólna zasada - Product Owner, który nie chce, nie jest gotowy lub nie potrafi nabyć umiejętności zarządzania Produktem, powinien ustąpić. Ekspert merytoryczny z danej dziedziny niekoniecznie jest najlepszym wyborem na Product Ownera, ponieważ potrzebne są również kompetencje z zakresu zarządzania Produktem i przywództwa; np. odpowiedzialność (accountability) Product Developera może być w takim przypadku bardziej odpowiednia.

Jeśli Scrum Team pracuje nad wieloma Produktami, platformami lub projektami, (co jest niezalecane), każdy z managerów tych elementów powinien być Interesariuszem (i Supporterem) Product Ownera i współpracować z nim w celu maksymalizacji długoterminowej wartości. Scrum zachęca Scrum Team do utrzymania Skupienia i Zaangażowania, co pomaga dostarczać wartościowe outcomes i unikać pułapek pracy jako „fabryka funkcjonalności” (feature factory).

Product Owner to jedna osoba - nie komitet ani technologia. Osoby chcące zmienić Product Backlog muszą przekonać do tego Product Ownera. Product Owner maksymalizuje długoterminową wartość i często dokonuje kompromisów.

Scrum Master

Scrum Master to rola i odpowiedzialność (accountability). Scrum Master musi być człowiekiem. Jest agentem zmiany, który działa na wszystkich poziomach organizacji i w różnych obszarach biznesowych. Scrum Master przewodzi przez dawanie przykładu (leads by example) i wspiera skuteczność Product Ownera, Scrum Teamu, Interesariuszy i Supporterów w adopcji Scruma. Scrum Master rozumie złożoność (30-35) i potrafi wspierać podejmowanie kolejnych właściwych kroków.

Scrum Master powinien przyjmować odpowiednie zachowania w zależności od sytuacji, w tym (ale nie tylko) być przewodnikiem, coachem, mentorem, nauczycielem, obserwatorem, usuwać przeszkody, agentem zmiany, facylitatorem efektywności oraz orędownikiem ciągłego doskonalenia. Scrum Master nie jest administratorem zespołu, menedżerem statusów, zarządzającym zadaniami, dyktatorem zasad, rezerwatorem salek, administratorem raportów i dashboardów, przewodzącym spotkaniom, bohaterem, koordynatorem ani Scrum Masterem nieobecnym, pozostawiającym wszystko „samozarządzaniu”.

Scrum Master ponosi odpowiedzialność (accountable) za skuteczność Scrum Teamu, Interesariuszy, Supporterów oraz osób zaangażowanych w przyjęcie empiryzmu (67), samozarządzania i adopcji Scruma, jak opisano w niniejszym dokumencie. Scrum Master zajmuje się tym, co przeszkadza lub spowalnia postępy Scrum Teamu i nie może zostać rozwiązane przez sam zespół.

Scrum Master wspiera Scrum Team, Product Ownera i Supporterów na wiele sposobów, w tym:

• Pomaga w zrozumieniu teorii i praktyki Scruma oraz edukację lub coaching w razie potrzeby;
• Umożliwia Scrum Teamowi i Supporterom ciągłe usprawnianie się na różne sposoby;
• Wspiera terminowe, celowe i intencjonalne interakcje;
• Upewnia się, że Scrum Team posiada odpowiednią Definition of Output Done;
• Upewnia się, że wszystkie wydarzenia Scrum się odbywają i są konstruktywne, produktywne oraz mieszczą się w timeboxach;
• Sprawia, że przeszkody w pracy nad Produktem i efektywnej adopcji Scruma są usuwane;
• Oferuje coaching w zakresie samozarządzania (49) i crossfunkcjonalności;
• Pomaga w zrozumieniu roli Interesariuszy i Supporterów we wspieraniu wartościowych Incrementów, spełniających Definition of Output Done, zgodnie z Celem Produktu i Definition of Outcome Done;
• Zwiększa adaptacyjność (80) i optymalizację przepływu wartości;
• Wzmacnia pewność opartą na dowodach, ale z empatią i rozwagą, by uniknąć nadmiernej pewności siebie;
• Wspiera gotowość Scrum Teamu i Supporterów do działania i wprowadzania zmian;
• Zachęca do zachowań zgodnych z Wartościami Scruma, wspierających zaufanie, współpracę i wysoką efektywność;
• Wspiera Scrum Team w szybkim i częstym dostarczaniu wartościowej pracy, pozyskiwaniu informacji zwrotnej i jej uwzględnianiu.

Scrum Master wspiera Scrum Team na wiele sposobów, w tym:

Wspiera jego formowanie, rozwijanie kompetencji i ciągłe doskonalenie; Pomaga w zrozumieniu potrzeby klarownych i zwięzłych Elementów Product Backlogu dostarczających wartość; Czuwa nad tym, by cały Scrum Team współpracował celowo i intencjonalnie, respektował Definition of Output Done i koncentrował się na tworzeniu wartościowych Incrementów zgodnych z Definition of Outcome Done.

Scrum Master wspiera Product Ownera na wiele sposobów, w tym:

• Pomaga w wyborze technik skutecznego definiowania Celu Produktu i zarządzania Product Backlogiem;
• Pomaga w tworzeniu emergentnego planowania Produktu w złożonym (30-35) środowisku;
• Pomaga w wyrażaniu outcomes jako miar w Definition of Outcome Done;
• Pomaga w tworzeniu klarownych i zwięzłych Elementów Product Backlogu dostarczających wartość;
• Pomaga w Skupieniu się na realizacji wartości.

Scrum Master wspiera Interesariuszy na wiele sposobów, w tym:

• Gdy sama wiedza ekspercka nie wystarcza, wspiera osoby zaangażowane i Interesariuszy w zrozumieniu i przyjęciu:
  • empirycznego podejścia do pracy w warunkach złożoności (30-35), gdzie przyczyna i skutek są spójne dopiero z perspektywy czasu,
  • wyjścia poza empiryczną kontrolę procesu, np. poprzez uruchamianie wielu równoległych eksperymentów o kontrolowanym ryzyku, poszukiwanie świeżego spojrzenia, egzaptację lub testowanie uzasadnionych przypuszczeń.Egzaptacja oznacza wykorzystanie czegoś, co zostało stworzone lub używane w jednym celu, do innego celu - zwłaszcza w nowych lub niejasnych sytuacjach.
• Wspiera działania zgodne z mottem „Przestań zaczynać, zacznij kończyć”;
• Facylituje współpracę Interesariuszy, gdy zachodzi taka potrzeba;
• Pomaga w zrozumieniu potrzeby tworzenia klarownych i zwięzłych Elementów Product Backlogu dostarczających wartość;
• Pomaga Interesariuszom w Skupieniu się przede wszystkim na realizacji wartości.

Scrum Master współpracuje z Supporterami na wiele sposobów, w tym:

• Prowadzi, szkoli i coaching Supporterów w zakresie adopcji Scruma;
• Wyjaśnia, co utrudnia skuteczną adopcję Scruma;
• Facylituje kontrolowane i stopniowe wdrażanie zmian w kierunku wspierającym adopcję Scruma;
• Wspiera zmiany organizacyjne sprzyjające łatwości dostarczania zamiast łatwości zarządzania.

Scrum Master współpracuje z organizacją na wiele sposobów, w tym:

• Przewodzi, szkoli i oferuje coaching organizacji w zakresie adopcji Scruma;
• Planuje i doradza w zakresie adopcji Scruma w organizacji;
• Współpracuje z działami wspierającymi wdrożenie Scruma;
• Usuwa bariery w adopcji Scruma.

Scrum Masterzy mogą współpracować z innymi Scrum Masterami lub Supporterami, aby wspierać całą organizację, a także z innymi agentami zmiany i liderami, gdy zajdzie potrzeba. Scrum Master jako agent zmiany ponosi odpowiedzialność (accountable) za jakość adopcji Scruma i powinien współpracować z innymi agentami zmiany w celu jej usprawnienia.

Scrum Master to jedna osoba, nie komitet ani technologia, i służy Product Ownerowi, Scrum Teamowi, Interesariuszom oraz całej organizacji. Jako agent zmiany i lider Scrum Master powinien zapraszać ludzi do udziału w zmianie. Pomocne jest, jeśli Scrum Master rozumie przepływ wartości (flow of value) (68, 69), lean (63), teorię złożoności (30-35) oraz inne wspierające koncepcje opisane w tym dokumencie, jak również potrafi wspierać ludzi w ich stosowaniu. Korzystne jest też, jeśli Scrum Master wykazuje nieustępliwość i ogromny głód uczenia się i zmiany.

Bycie Scrum Masterem to powołanie, w którym pomaganie innym w osiąganiu sukcesu stanowi wystarczającą nagrodę. Scrum Master nie szuka uznania - jak każdy dobry lider przypisuje zasługi innym, a bierze odpowiedzialność (responsibility) za niepowodzenia. Pozostanie w tej roli przez dłuższy czas pomaga prowadzić Scrum Team ku pełnemu potencjałowi, ale tylko wtedy, gdy Product Developerzy wspólnie rozwijają samozarządzanie. Zachowania Scrum Mastera przypominające rodzica nie wspierają samozarządzającego się Scrum Teamu. Kontekst ma znaczenie, ale jako ogólną zasadę przyjmuje się, że Scrum Master, który nie chce, nie jest gotowy lub nie potrafi być agentem zmiany, powinien zrezygnować z tej roli.

Artefakty Scruma w Rozszerzeniach

Artefakty Scruma zapewniają Transparencję w zakresie tego, co zdaniem Scrum Teamu i Interesariuszy dostarczy wartość. Dzięki temu wszyscy mają wspólną podstawę do Inspekcji i Adaptacji.

Każdy artefakt zawiera zobowiązanie:

• Dla Produktu służącego Interesariuszom jest to Definition of Outcome Done.
• Dla Incrementu będącego kandydatem na aktualizację Produktu jest to Definition of Output Done.
• Dla Product Backlogu jest to Cel Produktu
• Dla Sprint Backlogu jest to Cel Sprintu

Po wydaniu Incrementu (output), to Produkt jest tym, co tworzy wartość (outcome). Wartość to mierzalne lub obserwowalne spełnienie lub tworzenie oczekiwań, potrzeb lub pragnień z perspektywy Interesariuszy.

Zobowiązania te wzmacniają filary Transparencji, Inspekcji i Adaptacji, umożliwiając empiryczną kontrolę procesu (64-66). Cel Produktu pozostaje niezmienny, dopóki dla obserwowanego Produktu nie pojawią się dowody lub obserwacje, które podważają aktualny Cel Produktu w kontekście Definition of Outcome Done. Definition of Output Done nie ulega osłabieniu w trakcie Sprintu. Co zatem może zostać zmienione lub ograniczone? Mogą to być Acceptance Criteria dla konkretnego elementu Product Backlogu, sposób implementacji lub szczegółowość (fidelity) konkretnej funkcji, a nawet alternatywne elementy Product Backlogu służące osiągnięciu Celu Sprintu itd.

Jeśli Cel Produktu zmienia się często, może to oznaczać, że coś jest nie tak - być może wynika to z braku Skupienia na tym, co naprawdę istotne. Skupienie oznacza profesjonalizm i podejmowanie decyzji nie tylko o tym, nad czym pracować, ale również czego nie podejmować.

Produkt

Produkt jest artefaktem. Produkt może być doświadczeniem lub platformą. Może również być usługą, produktem fizycznym, cyfrowym lub hybrydowym, dostarczającym ciągłą wartość Interesariuszom (w tym, ale nie tylko, użytkownikom).

Doświadczenie to konkretne rozwiązanie zaprojektowane w celu zaspokojenia potrzeb Interesariuszy, w tym użytkownika, najlepiej zewnętrznego wobec organizacji. Zapewnia bezpośrednią interakcję, która dostarcza wartość. Zazwyczaj skupia się na rozwiązaniu określonego problemu lub wykorzystaniu szansy - albo ich kombinacja - dla Interesariuszy, w tym, ale nie tylko, klientów, decydentów i użytkowników.

Platforma to architektoniczne rozwiązanie, infrastruktura bazowa lub zestaw narzędzi umożliwiających Product Developerom budowanie w celu dostarczania doświadczenia. Platformy stanowią bazę, na której można rozwijać wiele Produktów, koncentrując się na skalowalności, niezawodności i elastyczności dla inżynierów, a nie na bezpośredniej interakcji z użytkownikiem.

Scrum Team i Interesariusze muszą zawsze jasno rozumieć, czym jest Produkt, kim są klienci, użytkownicy lub decydenci oraz jakiego typu jest to Produkt - na przykład przeznaczony dla użytkowników końcowych, pracowników lub Scrum Teamów - ponieważ każdy z nich ma innych Interesariuszy i inne sposoby tworzenia wartości. Produkt ewoluuje i często istnieje przez długi czas. Produkt potrzebuje pojedynczego Product Backlogu, aby zwiększyć Transparencję i zmaksymalizować wartość.

Kontekst ma znaczenie. Jednak jako zasada, aby Produkt zyskał i utrzymał atrakcyjność, pomocne jest, jeśli Produkt:

• wystarczająco adresuje luki w satysfakcji;
• jest wartościowy, pożądany, opłacalny, użyteczny, wykonalny, bezpieczny i zabezpieczony;
• ma wbudowany profesjonalizm;
• posiada atrakcyjną, klarowną i zorientowaną na metryki outcomes Wizję Produktu, strategię Produktu oraz Cel Produktu, często zawierające intencję, uzasadnienie i anty-cele;
• adaptuje się i doskonali, aby identyfikować, reprezentować lub mierzyć emergencję (71);
• jest rozbudowywalny i łatwy w utrzymaniu.

Produkt jest ucieleśnieniem dlaczego robimy to, co robimy.

Zobowiązanie: Definition of Outcome Done

Definition of Outcome Done to zobowiązanie. Opisuje ona mierzalne dowody (ilościowe lub jakościowe) wymagane do potwierdzenia osiągniętych korzyści, często określane jako walidacja wartości. Może dotyczyć zarówno całego Produktu, jak i konkretnego celu. Najlepiej jest zdefiniować miary walidacji wartości przed rozpoczęciem realizacji, aby uniknąć uprzedzeń i błędnych interpretacji.

Outcomes oraz ich interpretacje stanowią podstawę do przyszłych adaptacji, najlepiej potwierdzając zamierzony wpływ (impact) na Interesariuszy (w tym, ale nie tylko, wpływ biznesowy lub wpływ na użytkownika) - mierząc, czy output spełnia oczekiwany outcome(s) i dostarcza realną wartość. Może to dotyczyć konkretnego celu, takiego jak większa funkcjonalność lub kilka funkcjonalności, i być walidowane poprzez telemetrię Produktu (Produkt może mierzyć własne użycie). Alternatywnie, może odnosić się do całego Produktu, gdzie chodzi najczęściej o wpływ strategiczny i walidację skuteczności wdrożonej strategii (120-124). Możliwe jest także łączenie obu podejść.

Preferuj bezpośrednie dowody nad poszlakowymi. Na przykład:

• Outcomes klientów mogą Skupiać się na dostarczaniu mierzalnej wartości dla klientów, takiej jak wzrost satysfakcji klienta, długoterminowa redukcja kosztów po stronie klienta lub liczba zaadresowanych zadań klienta.
• Outcomes użytkowników mogą odnosić się do konkretnych zmian w zachowaniu użytkowników, które rozwiązują problemy i poprawiają doświadczenia, np. szybsze wykonywanie zadań lub korzystanie z nowych funkcji.
• Outcomes interesariuszy Produktu mogą łączyć te zmiany w zachowaniu z metrykami wydajności Produktu, np. trendami w liczbie klientów Produktu, metrykami decydentów/użytkowników, czasem dostarczenia Produktu, czasem uczenia się, czasem do zmiany kierunku (pivot), itp.
• Outcomes Interesariuszy biznesowych, np. zgodność z przepisami (compliance), długoterminowa redukcja kosztów po stronie biznesu, wyniki biznesowe, trendy udziału w rynku, satysfakcja klientów we wszystkich Produktach, organizacyjny czas dostarczenia, czas uczenia się, czas do piwotowania, itp.
• Outcomes Scrum Teamu, takie jak poprawa zdolności technicznych (stan flow (70), częstotliwość wydań, narzędzia, umiejętności, dług techniczny, dług UX lub CX, pojemność zespołu), klimat/kultura sprzyjające usprawnieniom i innowacjom.

Dług w zakresie User eXperience (UX) lub Customer eXperience (CX) to suma decyzji odnośnie designu i implementacyjnych-świadomych lub nie-które sprawiają, że Produkt lub usługa staje się mniej użyteczna, przyjemna lub skuteczna dla użytkowników lub klientów. Rozpoznanie, śledzenie i adresowanie tego długu jest kluczowe dla dostarczania Produktów, które rzeczywiście spełniają potrzeby i oczekiwania użytkowników.

Miary zbierane w czasie ujawniają trendy dotyczące Produktu, rynku oraz Interesariuszy (w tym, lecz nie wyłącznie, klientów i użytkowników); mogą być analizowane w dowolnym momencie Sprintu, także podczas Sprint Review.

Increment

Increment to artefakt. Jest zintegrowanym wynikiem pracy ukończonej zgodnie ze standardem określonym w Definition of Output Done. Increment jest outputem oraz kandydatem na Produkt.

W trakcie Sprintu może powstać wiele Incrementów poprzez ukończenie Elementów Product Backlogu. Każdy Increment jest dokładnie zweryfikowany, użyteczny i zintegrowany ze wszystkimi wcześniejszymi Incrementami. Powstały w ten sposób zintegrowany Increment jest poddawany inspekcji tak szybko, jak to możliwe - najpóźniej podczas Sprint Review. Increment musi być użyteczny i przydatny, by umożliwić uzyskanie feedbacku z rezultatu. Increment odgrywa kluczową rolę w Scrumie, ponieważ umożliwia ciągłą walidację wartości.

Kandydat na Increment nie kwalifikuje się jako Increment, dopóki nie spełni standardu jakości określonego w Definition of Output Done. Tylko Increment może zostać wydany. Increment powinien być konkretnym krokiem w kierunku realizacji Celu Produktu. Incrementy mogą być dostarczane Interesariuszom lub wydane przed Sprint Review. Najlepsza walidacja wartości osiągana jest poprzez feedback z rezultatu.

Zobowiązanie: Definition of Output Done

Definition of Output Done to zobowiązanie (commitment). Formalnie opisuje miary jakości, które wyrażają należytą staranność wobec Incrementu, tak aby mógł on zostać dostarczony Interesariuszom.

Definition of Output Done zazwyczaj obejmuje (choć nie jest do tego ograniczona) zarówno standardy techniczne, jak i cechy Produktu. Jeśli nie zostało określone przez organizację jako minimum, tworzy ją Scrum Team. Jeżeli nad tym samym Produktem pracuje wiele Scrum Teamów, korzystają one ze wspólnego Definition of Output Done jako wspólnej podstawy, ale mogą je rozwijać.

Scrum Team ma obowiązek stosować się do Definition of Output Done oraz nieustannie je doskonalić. Increment ma charakter kumulatywny. Definition of Output Done służy dobru Produktu i jego Interesariuszy. Definition of Output Done stanowi ogólny standard jakości dla całego Incrementu, a nie indywidualny standard dla każdego elementu (np. Acceptance Criteria).

Wydany Increment umożliwia uzyskanie informacji zwrotnej z rezultatów służącej walidacji wartości zgodnie z Definition of Outcome Done.

Product Backlog

Product Backlog to artefakt. Stanowi emergentną, uporządkowaną (uszeregowaną) listę Elementów Product Backlogu potrzebnych do osiągnięcia Celu Produktu. Product Backlog zapewnia Transparencję (klarowność pracy) i jest jedynym źródłem pracy dla Scrum Teamu w celu realizacji Celu Produktu. Product Owner, stale mając na uwadze wartość, nadaje kolejność elementom Product Backlogu. Mniejszy Product Backlog często zwiększa Transparencję.

Element Product Backlogu

Element Product Backlogu (Product Backlog Item) to potencjalnie wartościowy element znajdujący się w Product Backlogu. Nie musi mieć z góry określonego formatu. Jego celem jest rozwiązanie problemu lub wykorzystanie szansy. Może zawierać Acceptance Criteria, które wskazują, kiedy praca została ukończona - obok Definition of Output Done. Można dostarczyć dokładnie to, co było zamówione, ale nadal nie osiągnąć wystarczających outcomes. Dlatego Element Product Backlogu może także zawierać jasno określone Outcome Criteria, które wskazują, kiedy dostarczona została wystarczająca wartość - uzupełniając zapisy Definition of Outcome Done.

Element Product Backlogu to pojedyncza jednostka pracy, która odkrywa lub dostarcza wartość. Może ewoluować w dowolnym momencie - nawet gdy Product Developerzy nad nim pracują. Podczas refinementu może zostać podzielony na mniejsze, bardziej zrozumiałe (głównie dla Scrum Teamu) elementy Product Backlogu, które mogą dostarczyć wartość. Czasami może się zdarzyć, że dany element Product Backlogu nie jest powiązany z Celem Produktu. Jeśli takie sytuacje występują często, warto sprawdzić, czy poziom Skupienia jest tam, gdzie powinien być. Scrum Team oraz Interesariusze powinni Skupić się na outcomes, a nie wyłącznie na outputs, równoważyć kompromisy i nie dopuścić, by Scrum Team stał się „fabryką funkcjonalności” (feature-factory) lub „fabryką odkryć” (discovery-factory).

Acceptance Criteria

Acceptance Criteria, jeśli istnieją, opisują, kiedy output dla danego Elementu Product Backlogu jest ukończony - oprócz zapisów Definition of Output Done. Acceptance Criteria w doprecyzowanych elementach powinny zapewniać jednoznaczną jasność co do tego, co jest wymagane. Acceptance Criteria obejmują kryteria specyficzne dla danego Elementu Product Backlogu, których nie uwzględniono w Definition of Output Done; mogą być funkcjonalne lub niefunkcjonalne. Acceptance Criteria mogą ewoluować w dowolnym momencie - nawet podczas pracy Product Developerów nad danym elementem.

Outcome Criteria

Outcome Criteria, jeśli istnieją, opisują intencję Elementu Product Backlogu - czyli dlaczego kryjące się za co. Spełnienie Outcome Criteria często uzupełnia Definition of Outcome Done dla Produktu. Mogą zawierać kryteria specyficzne dla danego Elementu Product Backlogu, których nie uwzględniono wcześniej w Definition of Outcome Done. Jeśli pojawiają się pytania, Outcome Criteria wskazują kierunek; mogą przyjmować formę narracyjną lub mierzalną - najlepiej tę drugą. Outcome Criteria mogą ewoluować w dowolnym momencie - nawet podczas pracy Product Developerów nad danym elementem.

Refinement

Refinement to aktywność. Może mieć formę formalną (dodatkowe wydarzenie) lub nieformalną. Jest to ciągły emergentny proces, który sprzyja klarowności i ograniczaniu ryzyka; buduje wystarczające zrozumienie i przekonania, że wybrane lub nadchodzące Elementy Product Backlogu są gotowe (mogą zostać ukończone zgodnie z Definition of Output Done w ciągu kilku dni lub szybciej). Uwzględnia się różne typy zależności.

Refinement obejmuje dzielenie Elementów Product Backlogu na mniejsze, bardziej zrozumiałe (głównie dla Scrum Teamu) Elementy Product Backlogu. W jego ramach można dodawać więcej szczegółów, takich jak opis, Acceptance Criteria, Outcome Criteria, kolejność i rozmiar. Atrybuty mogą się różnić, ale powinny mieć sens dla Scrum Teamu. Refinement może obejmować badania, w tym między innymi walidację problemu lub szansy, doświadczeń użytkownika lub klienta, walidację rozwiązania. Za oszacowanie rozmiaru Elementów Product Backlogu odpowiedzialni (responsible) są wyłącznie Product Developerzy. Product Owner może wpływać na Product Developerów, pomagając im zrozumieć i wybrać potencjalne kompromisy.

W Refinemencie często uczestniczą Interesariusze oraz członkowie Scrum Teamu; nie jest niczym niezwykłym, że Product Developers współpracują bezpośrednio z Interesariuszami. Refinement jest często wspierany lub facylitowany przez Product Ownera. Product Owner może bardziej Skupić się na Product ownership, jeśli Product Developers mają szerokie zrozumienie Produktu. Ogólnie rzecz biorąc, jest to aktywność zorientowana na przyszłość, która oferuje przejrzystość, kierunek i potencjalne Skupienie w nadchodzących Sprintach.

Zobowiązanie: Cel Produktu

Cel Produktu jest zobowiązaniem. Jest reprezentowany przez Product Backlog, który należy do Product Ownera. Stanowi on aktualny, pojedynczy, bardziej strategiczny, ambitny cel (czyli dlaczego). Nadaje kierunek dla Produktu i umożliwia Product Developers pracujących nad Produktem Skupienie. Zwiększa Transparencję, dostarczając jasnego, wartościowego kierunku, ku któremu Product Developers mogą zmierzać, używając bardziej taktycznego Celu Sprintu (czyli dlaczego dla Sprintu).

Cel Produktu to średnioterminowy cel dla Scrum Teamu oraz Interesariuszy (w tym i Supporterów). Scrum Team powinien zrealizować (lub porzucić) jeden Cel Produktu, zanim podejmie się kolejnego.

Cel Produktu to zazwyczaj jeszcze niezweryfikowane twierdzenie dotyczące wartości. Może być wyrażony w różnych formach, w tym jako zestaw hipotez dotyczących zamknięcia lub zmniejszenia luk w satysfakcji. Zachowuje równowagę, koncentrując się na wybranych oczekiwaniach i ograniczeniach wielu Interesariuszy (w tym, choć nie tylko, klientów lub użytkowników). Poprzez Inspekcję i Adaptację istotne jest zaakceptowanie niepewności (72), informacji zwrotnej z wyników, efektów ubocznych i innych wniosków płynących z nauki.

A co z Wizją Produktu? {#what-about-a-product-vision?}

Wiele organizacji pracuje z Wizją Produktu, która pomaga zobrazować potencjalną przyszłość. Scrum Team może wykorzystać Wizję jako wkład do zastanowienia się nad Celem Produktu. Wizja Produktu to znaczący, długoterminowy zbiór pożądanych, wartościowych outcomes. Średnioterminowy Cel Produktu jest często krokiem w kierunku długoterminowej Wizji Produktu.

W miarę jak Scrum Team i Interesariusze dokonują inspekcji i adaptacji w kierunku Celu Produktu, powinni być Otwarci na możliwość, że Wizja Produktu lub Cel Produktu również mogą wymagać adaptacji. Często realizuje się kolejne Cele Produktu w sposób sekwencyjny, pracując w kierunku jednej wizji.

Kluczową rzeczą do zapamiętania jest to, że Wizja Produktu jest często dziełem fikcji - nic z niej nie musi być prawdą. Formułowanie hipotez i przeprowadzanie eksperymentów w określonym kierunku jest niezbędne - i to właśnie tutaj Scrum może dostarczyć najwięcej wartości.

Wizja Produktu często jest inspirująca, ale może też przytłaczać. Cel Produktu redukuje to przytłoczenie, ponieważ stanowi bardziej namacalny wycinek Wizji Produktu lub działa jako czynnik umożliwiający realizację Wizji Produktu.

Sprint Backlog

Sprint Backlog to artefakt. Składa się z Celu Sprintu (dlaczego Sprint jest realizowany), zestawu wybranych Elementów Product Backlogu (co, znane również jako prognoza) na Sprint oraz często zawiera dający możliwość działania plan dostarczenia Incrementu (jak). Zapewnia Transparencję (klarowność pracy) w trakcie całego Sprintu.

Sprint Backlog to plan tworzony przez i dla Product Developerów. Jest to punkt widzenia Product Developerów na uzgodnioną pracę niezbędną do osiągnięcia Celu Sprintu (dlaczego Sprint jest realizowany). Jeśli nieustannie większość elementów Sprint Backlogu nie jest powiązana z Celem Produktu, co jest suboptymalne, to wskazuje to na brak przestrzegania wartości Scrumowych: Skupienia i Zaangażowania.

W kontekście Celu Sprintu Product Developerzy aktualizują swój plan, w tym prognozę, przez cały Sprint w miarę zdobywania wiedzy. Sprint Backlog powinien zawierać wystarczającą ilość pracy, aby zacząć, np. rozpocząć od jednego lub dwóch Elementów Product Backlogu prowadzących do realizacji Celu Sprintu. Product Developerzy dokonują inspekcji swojego postępu względem Celu Sprintu podczas Daily Scrum lub częściej. Product Developerzy uczą się dostosowywać i reagować na niepewność (72).

Zobowiązanie: Cel Sprintu

Cel Sprintu jest zobowiązaniem tworzonym i należącym do Scrum Teamu. Cel Sprintu to jedyny, jednoczący cel Sprintu (dlaczego) dla Product Developerów, tworzony podczas Sprint Planningu. Dostarczenie Celu Sprintu to zobowiązanie Product Developerów. Sprint Backlog (zawierający dlaczego, co i często jak) zapewnia Skupienie oraz elastyczność względem ewoluującej pracy, co poprawia Transparencję.

Cel Sprintu zachęca Scrum Team do pracy zespołowej, zamiast do realizacji odrębnych inicjatyw. Jeśli praca okaże się inna, niż Product Developerzy się spodziewali, współpracują oni z Product Ownerem, negocjując możliwe zmiany w ramach Sprintu, bez wpływu na Cel Sprintu. Nikt nie mówi Product Developerom, jak mają szacować rozmiar swojej pracy ani jak ją wykonywać.

Wydarzenia Scrum w Rozszerzeniach

Scrum łączy cztery wydarzenia o ograniczonym czasie trwania (timeboxy), służące Inspekcji i Adaptacji, mieszczące się w ramach piątego, nadrzędnego wydarzenia o określonej długości - Sprincie. Wydarzenia te wspierają filary Scruma: Transparencję, Inspekcję oraz Adaptację. Wydania umożliwiają dostarczanie wartości, najlepiej w sposób ciągły. Rzadkie wydania prowadzą do opóźnionej informacji zwrotnej z rezultatów.

Timebox to ustalony maksymalny czas trwania danego zdarzenia - od początku do końca - i nie należy go mylić z oczekiwaniem wykorzystania całego dostępnego czasu. Celem timeboxów w Scrumie jest promowanie wyboru najistotniejszej pracy, tworząc Skupienie niezbędne do szybkiego osiągania pożądanych rezultatów. W Scrumie długość Sprintu dla danego Scrum Teamu jest stała, więc Sprint nie jest timeboxem.

Wydarzenia nadają rytm i ograniczają potrzebę organizowania innych spotkań niezwiązanych bezpośrednio ze Scrumem. Idealnie każde wydarzenie odbywa się w tym samym miejscu i o tej samej porze, co redukuje złożoność (30-35) i sprzyja kształtowaniu nawyków. Umiejętna facylitacja zwiększa efektywność. Nieskuteczne wydarzenia mogą prowadzić do utraty Skupienia na Celu Sprintu, Celu Produktu, oraz osłabienia Transparencji, Inspekcji, Adaptacji i Wartości Scrumowych.

Każde wydarzenie ma swój cel i powinno obejmować pogłębioną, istotną pracę. Razem wydarzenia Scrumowe tworzą rusztowanie dla Transparencji, umożliwiające Inspekcję, Adaptację, zatrzymanie się i refleksję. Wspierają one uporządkowane myślenie i działanie, efektywność i zrównoważony wysiłek.

Komunikacja jest kluczowa, aby Scrum Team i Supporterzy mogli się Skupić na właściwych aspektach. Poza Sprintem, wydarzenia mogą zajmować mniej czasu, o ile nie tracą spójności.

Sprint

Sprint to wydarzenie, podczas którego pomysły zamieniają się w wartość. Sprint to zdarzenie nadrzędne. To iteracja o określonym czasie trwania, w trakcie której realizowana jest praca. Zapewnia Skupienie i stabilność. Sprint nie trwa dłużej niż cztery tygodnie. Nowy Sprint rozpoczyna się natychmiast po zakończeniu poprzedniego. Cała praca niezbędna do osiągnięcia Celu Produktu odbywa się w ramach Sprintów.

Sprinty są rytmem Scruma - to właśnie wtedy Scrum Team zamienia pomysły w użyteczne, używalne i potencjalnie wartościowe Incrementy. Increment jest wydawany jak najszybciej, biorąc pod uwagę potrzebę uzyskania wczesnej informacji zwrotnej z rezultatów. Brak wydania dla części Interesariuszy (w tym, ale nie wyłącznie: klientów, decydentów i użytkowników) może skutkować brakiem terminowej informacji zwrotnej z rezultatów. W jednym Sprincie może powstać wiele Incrementów ; Scrum Team powinien dążyć do walidacji wartości poprzez częste i wczesne wydania - tam, gdzie to możliwe.

W trakcie Sprintu:

• Nie wprowadza się zmian, które mogłyby zagrozić Celowi Sprintu;
• Nie obniża się jakości Incrementu(ów);
• Product Backlog jest doprecyzowany w razie potrzeby;
• W miarę zdobywania wiedzy bieżąca praca może być doprecyzowana i renegocjowana z Product Ownerem, bez wpływu na Cel Sprintu.

Sprinty umożliwiają osiąganie outcomes poprzez zapewnienie Inspekcji i Adaptacji postępów względem Celu Sprintu przynajmniej co cztery tygodnie. Zbyt długi Sprint może sprawić, że Cel Sprintu przestanie być aktualny, co zwiększa złożoność (30-35) i ryzyko. Krótsze Sprinty często umożliwiają więcej cykli uczenia się; mogą też ograniczać ryzyko.

Krótsze Sprinty zazwyczaj wymagają większych kompetencji (np. doskonalenia backlogu, pionowego dzielenia⁴ [elementów Product Backlogu], znajomości dziedziny technicznej i biznesowej). Kontekst ma znaczenie - Scrum Team dąży do znalezienia właściwej równowagi.

Istnieją różne praktyki uzupełniające, które służą ocenie lub prognozowaniu postępu, takie jak wykresy spalania [burn-downs, burn-ups], analityka przepływu, prognozy probabilistyczne Monte Carlo, szacowanie dużych zadań, zbiory rozmyte (110) itp. Mimo że są użyteczne, nie zastępują one znaczenia empiryzmu (67). W złożonym (30-35) środowisku to, co już się wydarzyło, może służyć do podejmowania decyzji na przyszłość, ale to, co się wydarzy, pozostaje nieznane.

Sprint można postrzegać jako mini-projekt z jasnym outcome, określoną długością i znanym kosztem. Jednakże prace w jego ramach odbywają się równolegle, a nie w liniowej, sekwencyjnej kolejności.

Sprint może zostać anulowany, jeśli Cel Sprintu straci sens. Tylko Product Owner ma umocowanie do anulowania Sprintu. Krótsze Sprinty zmniejszają prawdopodobieństwo anulowania.

Sprint Planning

Sprint Planning to wydarzenie. To pierwsze wydarzenie w Sprincie, w którym Scrum Team Skupia się się i buduje Zaangażowanie.

Podczas Sprint Planningu brany jest pod uwagę bardziej strategiczny Cel Produktu (czyli dlaczego dla Product Backlogu), który nadaje kierunek. W tym kontekście Product Developerzy tworzą Sprint Backlog, który składa się z bardziej taktycznego, krótkoterminowego Celu Sprintu (dlaczego dla Sprintu), początkowo zidentyfikowanej pracy oraz planu dostarczenia.

Sprint Planning dotyczy następujących tematów:

Dlaczego Sprintu

Product Owner przedstawia pomysły na to, jak można zwiększyć wartość i użyteczność Produktu w bieżącym Sprincie. Następnie Scrum Team współpracuje, aby zdefiniować Cel Sprintu, który komunikuje, dlaczego Sprint jest wartościowy dla Interesariuszy w kontekście Celu Produktu. Cel Sprintu musi zostać sfinalizowany do końca Sprint Planningu.

Co względem Dlaczego

We współpracy z Product Ownerem, Product Developerzy wybierają elementy z Product Backlogu do realizacji w bieżącym Sprincie. Scrum Team może je doprecyzować, co zwiększa zrozumienie i pewność. Wybrane elementy powinny być możliwe do zrealizowania zgodnie ze standardem Definition of Output Done, razem z pozostałymi elementami.

Określenie, ile pracy da się zrealizować w Sprincie, może być wyzwaniem. Im więcej Product Developerzy wiedzą o swojej historycznej wydajności, technikach pionowego dzielenia [elementów Product Backlogu], nadchodzącej dostępności i Definition of Output Done, tym większą mają pewność w prognozowaniu outcomes Sprintu.

Skuteczne Scrum Teamy nie przeciążają się. Planują one zakończenie pracy wcześniej, czasem z użyciem bufora na nieprzewidziane sytuacje (85). Pomaga to zespołowi utrzymać Skupienie, poprawiać jakość i zadowalać Interesariuszy poprzez szybsze dostarczanie wartości. Chroniczne przeciążenie lub nagłe zmiany mogą powodować nadmierny stres negatywny, który Jeff Sutherland nazywa „Bayesian surprise”. Mogą one zaburzać stan psychologicznego flow (70) i efektywność Scrum Teamu. Klarowna komunikacja, profesjonalne radzenie sobie z emergencją (71) oraz małe, regularne zmiany pomagają temu zapobiec - dlatego Scrum Teamy powinny dążyć do wcześniejszego dostarczania.

Jak dla Co

To, jak praca zostanie wykonana, zależy wyłącznie od Product Developerów. Nikt inny nie mówi im, jak mają wykonywać swoją pracę. Product Developerzy sami wybierają, co będą robić; nikt nie przydziela im elementów Product Backlogu ani nie wymusza ich realizacji - nawet Product Owner.

Sprint Planning ma timebox do maksymalnie ośmiu godzin dla Sprintu czterotygodniowego. Dla krótszych Sprintów zdarzenie to zazwyczaj jest krótsze. Kontekst ma znaczenie. Jednak jako ogólną zasadę przyjmuje się, że planowania powinno być tyle, aby można było rozpocząć pracę - np. zaplanować kilka elementów Product Backlogu wspierających realizację Celu Sprintu.

Daily Scrum

Daily Scrum to wydarzenie. Podczas Daily Scrum Product Developerzy współpracują, aby ocenić postęp w realizacji Celu Sprintu i aktualizują plan działania - Sprint Backlog - do następnego Daily Scrum. Jeśli Cel Sprintu został już osiągnięty, Product Developerzy pracują w kierunku Celu Produktu.

Daily Scrum zapewnia Skupienie, spójność i poczucie pilności oraz wspiera samozarządzanie (49). Zazwyczaj biorą w nim udział tylko Product Developerzy. Dla uproszczenia często odbywa się według tej samej kadencji, w tym samym miejscu i czasie.

Product Developerzy mogą wybrać dowolną strukturę i techniki. Daily Scrum usprawnia komunikację wokół realizacji Celu Sprintu, identyfikuje i pomaga rozwiązywać ryzyka oraz przeszkody, wspiera szybkie podejmowanie decyzji, a co za tym idzie - eliminuje potrzebę innych spotkań.

Daily Scrum nie jest jedynym momentem, w którym Product Developerzy dostosowują plan Sprintu w kontekście Celu Sprintu lub Celu Produktu. Product Developerzy często spotykają się w ciągu dnia, by omawiać szczegóły.

Aby umożliwić przepływ wartości (68, 69) i szybszą realizację potencjalnych outcomes, Product Developerzy powinni koncentrować się na jednym lub kilku elementach naraz i doprowadzać je do stanu zgodnego z Definition of Output Done, zanim przejdą do kolejnych. Osiągają to poprzez Skupienie, ograniczenie liczby zadań w toku i priorytetyzowanie kończenia pracy nad rozpoczynaniem nowej. Product Developerzy monitorują przestoje w pracy, a nie bezczynność osób.

Daily Scrum ma timebox do maksymalnie piętnastu minut dziennie; może być krótszy.

Sprint Review

Sprint Review to wydarzenie. To interaktywna, oparta na współpracy sesja robocza. Często Scrum Team dzieli się aktualnym Celem Produktu oraz przedstawia Definition of Output Done i Definition of Outcome Done Interesariuszom. Zespół dzieli się rezultatami swojej pracy, kompromisami, na które się zdecydował, oraz tym, jaki postęp został osiągnięty w kierunku Celu Produktu („dlaczego” stojące za pracą). Jeśli są dostępne, udostępniane i omawiane są bieżące i aktualne miary postępu względem Definition of Outcome Done.

Sprint Review obejmuje inspekcję wielu aspektów związanych z Produktem, takich jak: Cel Produktu, Product Backlog, Cel Sprintu, nowa wiedza, Increment, oczekiwania Interesariuszy oraz ograniczenia, informacja zwrotna z rezultatów, skutki uboczne, postęp prac nad Produktem, rynek, a także spojrzenie w przyszłość - jakie pojawiły się nowe pomysły i możliwości, jakie są potencjalne kolejne kroki.

Na podstawie zdobytych informacji:

• Uczestnicy zastanawiają się, wzajemnie się słuchają, uczą się i współpracują, by określić nad czym warto pracować dalej;
• Adaptowany jest Product Backlog (czyli „co”) oraz - ewentualnie - Cel Produktu, najlepiej przy wsparciu dowodami lub obserwacjami i ukierunkowany na Cel Produktu lub opcjonalną Wizję Produktu;
• Uczestnicy adaptują Definition of Outcome Done dla przyszłych Sprintów.

Zawsze ważne jest uwzględnianie Interesariuszy - w tym także nieożywionych, innych-niż-ludzie Interesariuszy, jak np. prawo - oraz tego, co jest dla nich wartościowe.

Nieukończone elementy Product Backlogu wracają do Backlogu i nie są prezentowane; czasami przenoszone są do kolejnego Sprintu.

Sprint Review to przedostatnie wydarzenie Sprintu, timebox wynosi maksymalnie cztery godziny dla Sprintu czterotygodniowego. Dla krótszych Sprintów wydarzenie jest zazwyczaj krótsze.

Sprint Retrospective

Sprint Retrospective to wydarzenie. Podczas tego wydarzenia Scrum Team uzgadnia, jak się usprawnić. Analizowane są również błędne założenia - takie, które popchnęły Scrum Team w niewłaściwym kierunku. Wskazywane lub wzmacniane mogą być także dobre rzeczy, takie jak konkretne technologie, procesy, wzorce itp. Zakres inspekcji często zależy od domeny pracy. Refleksja jest skuteczniejsza w środowisku zapewniającym bezpieczeństwo psychologiczne.

Sprint Retrospective koncentruje się na najbardziej pomocnych zmianach, które wspierają usprawnienia, takich jak:

• Increment,
• Outcomes,
• Profesjonalizm, np. umiejętności, praktyki techniczne, narzędzia, zdolność do innowacji;
• Przepływ zwalidowanej wartości (68, 69), np. metryki end-to-end, czas dostarczenia;
• Efektywność (jak), np. technologia, procesy, zależności;
• Interakcje i dynamika Scrum Teamu, np. współpraca, organizacja pracy;
• Radiatory informacji, np. Product Wall, metryki;
• Definition of Output Done dla przyszłych Sprintów;
• Dalsze adaptacje Definition of Outcome Done dla przyszłych Sprintów;
• Sposoby automatycznego pozyskiwania miar związanych z Definition of Outcome Done;
• I więcej.

Usprawnienia o (potencjalnie) największym wpływie powinny być wdrażane jak najszybciej. Scrum Team nie powinien jedynie rozmawiać o usprawnieniach - Scrum opiera się na istotnej ciągłej realizacji działań usprawniających. Niektóre działania wymagają wsparcia Supporterów, ale to nie oznacza, że Scrum Team nie powinien dążyć do poprawy niezależnie (np. poprzez ciągłe, choćby niewielkie usprawnienia).

Sprint Retrospective zamyka Sprint. Timebox to maksymalnie trzy godziny dla Sprintu czterotygodniowego. Dla krótszych Sprintów wydarzenie jest zazwyczaj krótsze.

Produkt Multi-Scrum-Teamów

Jeśli Scrum Team staje się zbyt liczny, powinien rozważyć reorganizację na kilka spójnych Scrum Teamów, z których każdy będzie skoncentrowany na tym samym Produkcie. W przypadku wielu Scrum Teamów pracujących nad tym samym Produktem, powinny one dzielić ten sam Cel Produktu, Product Backlog, Product Ownera, bazową Definition of Outcome Done oraz bazową Definition of Output Done.

Należy uważać na bezpodstawne założenia, że więcej Scrum Teamów oznacza więcej dostarczanej wartości. Skaluj tylko wtedy, gdy korzyści wyraźnie przewyższają dodatkowe obciążenie organizacyjne. Zanim zdecydujesz się na skalowanie, pojedynczy Scrum Team musi być w stanie niezawodnie dostarczać Increment w każdym Sprincie. Jeśli jednak musisz skalować, zastosuj podejście spójne z niniejszym dokumentem. Często mniejsza liczba zespołów prowadzi do większej liczby outcomes.

W kontekście multi-Scrum-Team, Scrum Teamy mogą zmniejszać zależności międzyzespołowe, stając się bardziej crossfunkcjonalne dzięki współpracy, wymianie wiedzy i doświadczeń (cross-pollination), transferowi nauki oraz celowym interakcjom. Umiejętności potrzebne w takim kontekście są zazwyczaj szerokie i zależą od specyfiki domeny pracy. W środowisku multi-Scrum-Team celowe i świadome interakcje oraz profesjonalizm (w tym ciągła integracja) stają się jeszcze bardziej istotne.

W konfiguracji z jednym Product Ownerem i jednym Scrum Teamem, Product Ownerem może być menedżer produktu, dyrektor marketingu, dyrektor ds. technologii itp. W konfiguracji multi-Scrum-Team dla jednego Produktu, ideałem jest nadal tylko jeden Product Owner, który powinien być liderem Produktu. Aby umożliwić Product Ownerowi pracę z wieloma Scrum Teamami przy tym samym Produkcie, Product Owner często staje się bardziej strategiczny i deleguje problemy do rozwiązania oraz szanse do wykorzystania Product Developerom, w tym np. aspekty projektowania Produktu lub zarządzania Produktem.

Product Backlog jest narzędziem zwiększającym transparencję.

Zasadniczo, im mniej Product Backlogów na Produkt - niezależnie od tego, czy są one niejawne (np. jako filtry głównego Product Backlogu), czy jawne - tym:

• mniej silosów w Produkcie i większa transparencja w odniesieniu do całego Produktu;
• bardziej przejrzyste śledzenie postępów w pracy nad całym Produktem;
• większa jasność co do wartości z perspektywy całości Produktu;
• większe prawdopodobieństwo, że Scrum Team zorientuje się, iż pracuje nad elementami o niskiej wartości z punktu widzenia Produktu;
• większe prawdopodobieństwo zaobserwowania poprawy w osiąganiu wartości; oraz
• większa szansa, że Product Owner stanie się bardziej strategiczny, delegując prace Product Developerom w obrębie całego Produktu.

Mniejsza liczba Product Backlogów dla jednego Produktu sprzyja adaptacyjności (80), jednak bez sprawczego Product ownership, spójnego zakresu kontroli oraz bezpośredniego kontaktu z odpowiednimi Interesariuszami, mogą pojawić się luki. Scrum wspiera klimat sprzyjający przypadkowym odkryciom i wieloaspektowemu uczeniu się - gdy różne osoby i Scrum Teamy współpracują, mogą dzielić się odkryciami i spostrzeżeniami, które mogą zostać wykorzystane. Jest to mało prawdopodobne w środowisku, gdzie każdy komponent ma osobny Product Backlog funkcjonujący w izolacji.

Przypadkowe odkrycia (happenstance) w kontekście „The New New Product Development Game” (29) oznaczają, że czasami użyteczne pomysły lub rozwiązania pojawiają się przypadkiem, a nie w wyniku starannego planowania. Gdy Scrum Teamy ściśle współpracują i dzielą się informacjami, mogą odkrywać nowe podejścia lub odpowiedzi po prostu dlatego, że są otwarte na nieoczekiwane zdarzenia lub przypadkowe odkrycia.

Wielokierunkowe uczenie się (multilearning) oznacza, że członkowie zespołu uczą się na wiele różnych sposobów jednocześnie. Przyswajają nowe umiejętności i wiedzę nie tylko w swoim obszarze, lecz także w innych obszarach, uczą się jako jednostki, jako grupa oraz jako część całej organizacji. To pomaga zespołowi stać się bardziej elastycznym i zdolnym do szybkiego rozwiązywania szerokiego zakresu problemów, ponieważ wszyscy uczą się od siebie nawzajem i ze wspólnych doświadczeń podczas współpracy.

Znalezienie właściwej równowagi to dylemat. Zawsze istnieją kompromisy do rozważenia. Jednak dobrą heurystyką jest: im mniej Product Backlogów - jawnych lub niejawnych - tym lepiej, co jest możliwe dzięki wielokierunkowemu uczeniu się i organizacyjnemu transferowi wiedzy pomiędzy Scrum Teamami, działami i Produktami.

Organizacyjny transfer wiedzy, opisany w „The New New Product Development Game” (29), to proces, w którym wiedza i spostrzeżenia zdobyte w jednym obszarze rozwoju nowego Produktu są regularnie udostępniane i stosowane w kolejnych obszarach lub innych działach organizacji.

Organizacje są często projektowane z myślą o łatwości zarządzania, a nie łatwości osiągania outcomes. Zadaj sobie pytanie, ile Scrum Teamów dany problem lub szansa musi zaangażować, aby dostarczyć wartość - ogólnie rzecz biorąc, im mniejsza jest ta liczba, tym lepiej.

Uwolnij zespoły od podejścia typu command and control. W razie wątpliwości, wybieraj autonomię przy zachowaniu spójności. Wspieraj celowe, intencjonalne interakcje w ramach i pomiędzy samozarządzającymi się Scrum Teamami (49). Kształtuj środowisko pracy z minimalnymi, lecz wystarczającymi procesami zarządczymi, wsparciem strukturalnym i granicami. Równoważ i pielęgnuj oczekiwania oraz granice Interesariuszy. Buduj sprawczość do wprowadzania zmiany oraz ciągłe doskonalenie w określonym kierunku - nie tylko dostarczanie - w ramach kadencji.

W razie wątpliwości, sięgnij do „The New New Product Development Game” (29), czerp z tego, co dobre we współczesnych rozwiązaniach, ale porzuć kompleks industrialny (industrial complex)⁵ (30-35), zgodnie z którym jedynie odważni ludzie mają sprawczość, by cokolwiek zdziałać.

Nota końcowa

Wdrożenie Scruma przez Jeffa Sutherlanda w 1993 roku w firmie Easel było inspirowane publikacjami Christophera Langtona (36, 37) na temat teorii Złożonych Systemów Adaptacyjnych (Complex Adaptive Systems, CAS) (74-77) z Los Alamos Labs, które pokazują, że systemy ewoluują szybciej na granicy chaosu.

Scrum został opisany w Scrum Guide 2020 (40). A Simple Guide to Scrum (58) Tobiasa Mayera to skrócona i zredagowana wersja oficjalnego Scrum Guide, którego autorami są Ken Schwaber i Jeff Sutherland. Scrum Hexis (52) rozwija Scrum Guide 2020 z perspektywy roku 2025, jednak to Scrum Guide 2020 pozostaje podstawowym odniesieniem dla Scruma.

Scrum jest jak lustro. Jeśli obraz w lustrze nie jest zgodny z oczekiwaniami - czy należy ukryć lustro?

Dbaj o wykształcenie nawyku osiągania przynajmniej jednego Incrementu w każdym Sprincie zanim zaczniesz dostosowywać Scruma do swoich potrzeb. Każda część Scruma ma swój cel - zrozumienie „dlaczego” każdej z nich jest kluczowe. Weź pod uwagę kontekst. Krótkoterminowo chodzi o dostarczanie. Długoterminowo - o skuteczną emergentną zmianę w określonym kierunku oraz o zrównoważone dostarczanie wartości. Skuteczne wdrożenie Scruma zależy od znalezienia właściwej równowagi między krótkim a długim horyzontem czasowym.

Uważaj na kopiowanie podejść innych organizacji bez jednoczesnego rozwijania kultury takiej jak ich. Emergentna zmiana w obranym kierunku jest tą zmianą. Obejmuje ona (choć nie jest do tego ograniczona) przywództwo, przepływy pracy, procesy i systemy, w tym HR, finanse, zakupy i inne. Scrum to część niekończącej się podróży ciągłego doskonalenia i ewolucji w obranym kierunku, a nie dotarcie do celu.

Podziękowania

Inspiracją dla Scruma był Lean (63), System Produkcyjny Toyoty (59-60), artykuł z Harvard Business Review pt. “The New New Product Development Game” autorstwa Hirotaki Takeuchiego i Ikujiro Nonaki (29) oraz Empiryzm w firmie Dupont (61).

Scrum został opracowany na początku lat 90. XX wieku. Ken Schwaber i Jeff Sutherland po raz pierwszy wspólnie zaprezentowali Scruma podczas konferencji OOPSLA w 1995 roku (62). Pierwsza wersja Scrum Guide (40) ukazała się w 2009 roku. Scrum stale ewoluuje.

Dziękujemy również recenzentom, którzy przekazali swoje uwagi do wcześniejszych wersji dokumentu, w tym (choć nie wyłącznie): Darynowi Bassonowi, Alexowi Benesowi, Kurtowi Bittnerowi, Debowi Bhattacharyi, Magdalenie Firlit, Nichervanowi Fazelowi, Peterowi Fischbachowi, Michaelowi Forniemu, Tomowi Gilbowi, Martinowi Hinshelwoodowi, Jesse’emu Houwingowi, Michaelowi Huynhowi, Matthew Ijogiemu, Marcowi Kaufmannowi, Tomowi Mellorowi, Christianowi Neverdalowi, Stasowi Pavlovowi, Ianowi Sharpowi, Alisie Stolze, Markowi Summersowi oraz Naderowi Talaiowi.

Rozszerzony Scrum na jednej stronie

Scrum został opisany w 2020 Scrum Guide (40). SScrum to lekki framework przeznaczony do pracy w warunkach złożoności (30-35), w szczególności w zakresie odkrywania (Discovery), tworzenia, dostarczania Produktu oraz realizacji wartości. Scrum opiera się na empirycznej kontroli procesu (podejmowanie decyzji w oparciu o dowody) i myśleniu Lean (ograniczanie marnotrawstwa i koncentrowanie się na przepływie wartości) (63). Scrum jest celowo niekompletny - nadaje kierunek interakcjom, zamiast narzucać szczegółowe instrukcje.

Dlaczego warto używać Scruma?
Scrum umożliwia Scrum Teamom identyfikowanie, przedstawianie lub mierzenie emergencji (71), akceptowanie niepewności, reagowanie na zmiany, częste dostarczanie i walidację wartości oraz ciągłe doskonalenie. Scrum wspiera współpracę, odpowiedzialność (accountability) i podejmowanie decyzji w oparciu o dowody, co pozwala osiągać najlepsze możliwe outcomes w dynamicznie zmieniającym się środowisku. Samozarządzające Scrum Teamy, zorganizowane wokół wartości, są kluczowe dla kreatywnego rozwiązywania problemów i wykorzystywania szans; Scrum Teamy niesamozarządzające ograniczają zdolność radzenia sobie ze złożonością (30-35). Samozarządzające Scrum Teamy nie powinny być mylone z indywidualnym samozarządzaniem.

Elementy Scruma

1. Teoria Scruma - oparta na trzech filarach:

• Transparencja - Uwidacznianie pracy i wartości dla Inspekcji.
• Inspekcja - Regularna ocena postępów i outcomes na potrzeby Adaptacji.
• Adaptacja - Dostosowywanie planów w oparciu o spostrzeżenia i informacje zwrotne.

2. Wartości Scruma:

Skupienie, Otwartość, Odwaga, Zaangażowanie i Szacunek umożliwiają efektywną pracę zespołową; wspierają zaufanie.

3. Role / Odpowiedzialności (Accountabilities):

• Scrum Team - mały, samozarządzający, crossfunkcjonalny i poznawczo zróżnicowany zespół składający się z:
  • Product Ownera - maksymalizuje długoterminową wartość, angażuje Interesariuszy i zarządza Product Backlogiem.
  • Scrum Mastera - wspiera wdrożenie Scruma, usuwa przeszkody i wspomaga ciągłe doskonalenie.
  • Product Developerów - dostarczają Incrementy w każdym Sprincie dzięki swoim crossfunkcjonalnym kompetencjom.
• Interesariusz (Stakeholder) - jednostka, podmiot lub grupa, która jest zainteresowana, której dotyczy lub która wpływa na dane wejściowe, działania i outcomes, mając bezpośredni lub pośredni interes wewnątrz lub na zewnątrz organizacji, jej Produktów lub usług.
  • Supporter (typ Interesariusza) - wspiera klimat i środowisko pracy oraz uczestniczy w procesie zgodnie z potrzebą.
  • AI - jako narzędzie, a potencjalnie również jako Product Developer, jednak nie w pełni godny zaufania na obecnym etapie.

4. Wydarzenia i Aktywności Scruma

• Scrum działa w ramach Sprintów (iteracji o określonej długości do czterech tygodni), obejmujących cztery wydarzenia z timeboxem:
• Sprint Planning - określenie Celu Sprintu i zaplanowanie pracy.
• Daily Scrum - Product Developerzy codziennie synchronizują się w kontekście postępu względem Celu Sprintu lub Celu Produktu.
• Sprint Review - inspekcja Incrementu, wartości i rynku oraz adaptacja Product Backlogu.
• Sprint Retrospective - refleksja i doskonalenie Scrum Teamu.
• Refinement - doprecyzowanie nadchodzącej lub wybranej pracy, formalnie (jako opcjonalne wydarzenie) lub nieformalnie.

5. Artefakty Scruma i Zobowiązania

• Produkt i Definition of Outcome Done - Produkt oraz wartościowe outcomes, które dostarczają dowodów na zrealizowane korzyści.
• Przyrost i Definition of Output Done - Potencjalnie wartościowy, możliwy do wydania kandydat na aktualizację Produktu.
• Product Backlog i Cel Produktu (Product Goal) - uporządkowana (sekwencyjna) lista prac prowadzących do średnioterminowego, bardziej strategicznego celu.
• Sprint Backlog i Cel Sprintu (Sprint Goal) - wybrane elementy Product Backlogu oraz plan na Sprint, cel krótkoterminowy.

Log Rozszerzeń

Dodatki:

• Sekcja dotycząca AI
• Sekcje o samozarządzającym się Scrum Teamie, Kadencji, Profesjonalizmie
• Sekcja o emergencji, otwartość na to, że ryzyko i odchylenia od oczekiwań niekoniecznie maleją z czasem
• Złożoność (30-35) - dlaczego Scrum?
• Sekcje o Przywództwie i myśleniu Systemowym
• Sekcje o myśleniu produktowym i Discovery
• Sekcje o Myśleniu od podstaw, Ludziach i Zmianie
• Sekcja o Produktach rozwijanych przez wiele Scrum Teamów (Multi-Scrum-Team)
• Rola Interesariusza (w tym klientów, decydentów i użytkowników), Supporter jako typ Interesariusza
• Sekcje o Refinemencie i Product Backlog Itemach
• Opcjonalnie: Wizja Produktu, Acceptance Criteria, Outcome Criteria
• Definition of Outcome Done, dodatkowy nacisk na adaptację opartą na dowodach pochodzących z outcomes
• Zdefiniowane pojęcia: Interesariusz, wartość, informacja zwrotna z wyników (result feedback), wydanie (release), outcomes, ryzyko, przeszkoda (impediment) oraz lider
• Analityka przepływu (flow analytics), probabilistyczne prognozy Monte Carlo, estymacje na dużym poziomie ogólności, zbiory rozmyte (wszystkie opcjonalnie)
• Scrum w rozszerzonej wersji na jednej stronie
• Potrzeba dostosowania przepływów pracy, projektów, procesów, systemów oraz środowiska pracy do warunków emergencji
• „Product Ownership wymaga silnych umiejętności zarządzania produktem i znajomości domeny… Product Owner, który nie chce, nie jest gotowy lub nie jest w stanie zdobyć umiejętności zarządzania produktem, powinien zrezygnować z roli Product Ownera.”
• Product Developer, który nie chce, nie jest gotowy lub nie jest w stanie być profesjonalistą, powinien zrezygnować z roli.
• Scrum Master, który nie chce, nie jest gotowy lub nie jest w stanie być agentem zmiany, powinien zrezygnować z roli.
• Załączniki: Cynefin® Kind of Explanation - nieoficjalne i nieautoryzowane, Emergent Strategy, Adaptive (80) Enterprise, Adaptive Executive or Board Member.

Sugestie

• Doprecyzowanie i modyfikacja odpowiedzialności (responsibilities) przy jednoczesnym „zaakceptowaniu niejednoznaczności” (73)
• Od podejścia „Scrum jest niezmienny lub prosty” do „Scrum ewoluuje”; w niektórych przypadkach złagodzenie sformułowań z „musi” na „powinien”
• Odpowiedzialność (accountability) Product Ownera jako rola Product Ownera z ponoszeniem odpowiedzialności (accountability); maksymalizowanie długoterminowej wartości
• Odpowiedzialność (accountability) Developerów jako rola Product Developers z ponoszeniem odpowiedzialności (accountability)
• Odpowiedzialność (accountability) Scrum Mastera jako rola Scrum Mastera z ponoszeniem odpowiedzialności (accountability); Scrum Master to jedna osoba, nie AI
• Product Developerzy mogą być ludźmi lub AI, albo wspierani przez AI; co najmniej jeden Product Developer powinien być człowiekiem; większa liczba Product Developerów, którzy są ludźmi, wspiera różnorodność poznawczą i radzenie sobie ze złożonością
• Scrum Team, a nie – jak miało to miejsce wcześniej – jedynie Developerzy, zobowiązuje się do realizacji Celu Sprintu; istotne, by Product Owner zachowywał skupienie.
• Sprint Backlog ukierunkowany na Sprint Goal lub Product Goal, a nie tylko Sprint Goal
• Definicja Produktu, wzmianka o strategii Produktu, roadmapach, modelach Produktu, skalowalności, podejściach zorientowanych na cele
• Podkreślenie znaczenia uczenia się, informacji zwrotnej o rezultatach, efektów ubocznych, outcomes zamiast outputs
• Aby zachować przepływ wartości, nieukończone elementy Product Backlogu nie muszą wracać do Product Backlogu
• Definition of Done przemianowane na Definition of Output Done
• Podkreślenie pełnego cyklu życia Produktu, pełnego cyklu życia funkcjonalności oraz urzeczywistniania wartości
• Tematy Sprint Planningu 1–3 przemianowane na Dlaczego, Co i Jak; Sprint do 4 tygodni zamiast do 1 miesiąca
• Możliwość dodatkowego przeglądu Incrementu oraz outcomes w bezpieczniejszym psychologicznie środowisku podczas Sprint Retrospective
• Większy nacisk na to, że Increment jest zawsze Done, dlatego wyrażenie „Done Increment” jest zbędne
• Wyraźne zaznaczenie podatności Celu Produktu na zmiany (w rozsądnych granicach)
• Od optymistycznego założenia dostarczania wartości do celowego Skupienia się na realizacji wartości
• Etos wbudowanej jakości, przejrzystości, decyzji opartych na danych, intencjonalnych interakcji, emergencji (71), outcomes ponad outputs, zatrzymania się i refleksji, realizacji wartości, rozumienia problemu lub szansy, wspierania klimatu/środowiska dla spójnej adaptacji Scruma oraz ciągłego doskonalenia w określonym kierunku
• Zmniejszenie nacisku na nieokreśloną „organizację”, aby przypisać zmianę do ról
• Większa intencjonalność w przestrzeganiu Wartości Scrumowych, z uwzględnieniem kontekstu

Załącznik

Sekcja 2: Wyciąg “MORE executive SUCCESS”
Tytuł: Wyciąg z “MORE executive SUCCESS”
Autor: John Coleman
Żródło: (6)
Licencja/Prawa autorskie: CC BY-NC-ND 4.0 , © 2017-2025 Orderly Disruption Limited
Uwaga: Niniejsza sekcja została zamieszczona w oryginalnej, niezmodyfikowanej formie, zgodnie z warunkami licencji CC BY-NC-ND 4.0 . Nie dokonano żadnych zmian.

Organizacja adaptacyjna

Trudno być organizacją adaptacyjną (80) bez kultury, w której słowa pokrywają się z czynami. Przeanalizowano ponad osiemdziesiąt modeli zaangażowania. Wśród nich znalazły się zarówno ramy postępowania skalujące, deskalujące, jak i Product Operating Model, które mogą być użyteczne w przypadku Produktów rozwijanych przez wiele Scrum Teamów. Modele te obejmują zarówno podejścia idące za daleko, jak i takie, które nie robią wystarczająco dużo, by pomóc organizacji produktowej stać się bardziej adaptacyjną. Nie istnieje uniwersalna, ponadkontekstowa „Strefa Złotowłosej”.

Spośród przeanalizowanych modeli zaangażowania wyróżnia się kilka godnych uwagi, takich jak Beyond Budgeting, Humanokracja czy Sociokracja, które warto rozważyć w zależności od kontekstu. Warto także rozpatrzyć ich łączenie ze sobą oraz z innymi podejściami.

Beyond Budgeting

Beyond Budgeting (15-28, 90-98, 103) to filozofia zarządzania, która odrzuca tradycyjne, sztywne roczne budżetowanie na rzecz zdecentralizowanego i adaptacyjnego podejścia do kontroli organizacyjnej oraz zarządzania efektywnością. Opiera się na 12 zasadach przewodnich - sześciu dotyczących przywództwa i sześciu procesów zarządzania - które promują zdecentralizowane podejmowanie decyzji, Transparencję, autonomię zespołów oraz silne ukierunkowanie na wartość dla klienta.

Zamiast sztywnych celów i szczegółowych rocznych planów, Beyond Budgeting zachęca do dynamicznego wyznaczania celów, ciągłego planowania oraz alokacji zasobów w oparciu o bieżące potrzeby, co sprzyja adaptacyjności i responsywności w szybko zmieniającym się środowisku biznesowym. Takie podejście ma na celu wzmocnienie zespołów, zwiększenie innowacyjności oraz zapewnienie organizacjom lepszych możliwości radzenia sobie z niepewnością (72) i złożonością (30-35). Beyond Budgeting to nazwa nietrafiona (fałszywe założenie, że chodzi tylko o finanse), a jednocześnie trafiona (bo rzeczywiście wykracza poza budżetowanie).

Humanokracja

Humanokracja (2), zgodnie z definicją Gary’ego Hamela, to model zarządzania, który zastępuje sztywne hierarchie i scentralizowaną kontrolę systemami maksymalizującymi wkład i kreatywność każdej osoby. W humanokracji organizacje istnieją po to, by służyć i wzmacniać ludzi, a nie traktować pracowników wyłącznie jako zasoby do realizacji celów firmy.

Opiera się ona na zasadach takich jak rozproszona odpowiedzialność (ownership), merytokracja, otwartość, eksperymentowanie i wspólnota, wspierając autonomię i innowacyjność. Autorytet wynika z kompetencji, a podejmowanie decyzji jest zdecentralizowane i przekazywane osobom najbliżej pracy. Humanokracja stawia na pierwszym miejscu zaufanie, zaangażowanie i uwalnianie ludzkiego potencjału, a nie zgodność i kontrolę, dążąc do budowy odpornych, innowacyjnych miejsc pracy, w których pracownicy napędzają realne zmiany.

Podczas gdy modele takie jak Rendanheyi firmy Haier (56, 101) podzielają wartości decentralizacji i upodmiotowienia, humanokracja jest szerszą filozofią, skoncentrowaną na zastąpieniu biurokracji zasadami zorientowanymi na ludzi, które odblokowują zbiorowe możliwości i wartość.

Socjokracja

Socjokracja (1, 11-14) to system zarządzania, który organizuje ludzi w samozarządzające kręgi (49) i podejmuje decyzje na zasadzie zgody, a nie większości głosów. Opracowana przez Gerarda Endenburga (81) w Holandii w latach 70., zapewnia, że każda osoba, której dotyczy decyzja, ma głos, a propozycje są wdrażane, o ile nie zostanie zgłoszony uzasadniony sprzeciw. Kierując się zasadą „wystarczająco dobre na teraz, wystarczająco bezpieczne, by spróbować”, socjokracja rozprasza władzę, promuje Transparencję, odpowiedzialność (accountability) i ciągłe doskonalenie, a także wspiera współpracę oraz współwłasność. Jej zasady wpłynęły na modele takie jak Holakracja i samozarządzające zespoły.

Najbardziej ugruntowaną odmianą jest Sociocratic Circle-Organization Method (SCM), czyli oryginalna, sformalizowana metoda. SCM wykorzystuje półautonomiczne kręgi, podwójne powiązania (gdzie dwie osoby uczestniczą w dwóch bezpośrednio powiązanych kręgach, aby je połączyć), podejmowanie decyzji na zasadzie zgody oraz otwarte wybory na role. Taka struktura zapewnia zarówno efektywność organizacyjną, jak i równość członków, a jej skuteczność została dobrze udokumentowana w przedsiębiorstwach, spółdzielniach i szkołach w Holandii.

Chociaż nowsze warianty, takie jak Socjokracja 3.0 (S3), oferują większą elastyczność, Sociocratic Circle-Organization Method (SCM) pozostaje najbardziej historycznie potwierdzoną i najlepiej udokumentowaną formą socjokracji.

Adaptacyjny menedżer lub członek zarządu

MORE Executive SUCCESS identyfikuje szereg możliwości dla menedżerów i członków zarządu:

• Pozyskiwanie wiedzy o interesariuszach (w tym klientach), ich potrzebach i ograniczeniach, pracy, sposobie jej wykonywania, marnotrawstwie, antywzorcach, domenie problemu, szansach, dowodach na możliwość pozyskania wartości, zachowaniach i nawykach
• Kształtowanie środowiska z troską o człowieka, które sprzyja efektywności oraz umożliwia planowanie sukcesji, chroniącej i i rozwijającej to środowisko
• Rozwijanie responsywności i flow (68,69) w sieciach wartości
• Wspieranie emergencji (71) i adaptacyjności (80) w jasno określonym kierunku
• Angażowanie ludzi, w tym klientów i współpracowników
• Wspieranie skutecznego i terminowego planowania sukcesji

Istnieje wiele wskazówek dla osób ze szczebla operacyjnego , średniego oraz bocznego dotyczących zwiększania adaptacyjności (80). Tymczasem najwyższy szczebel zarządzania często pozostaje bez odpowiedniego wsparcia w zakresie ludzkiej skuteczności, kontaktu z klientami oraz zrozumienia „jak działa praca”.. Panuje błędne przekonanie, że zatrudnieni agenci zmiany wypełniają tę lukę samodzielnie, co jest nierealistyczne, ponieważ to organizacja jest właścicielem zmiany.

Terminowa, ludzka skuteczność powinna przenikać całą strukturę korporacyjną, aby organizacja mogła czerpać z niej liczne korzyści. Nawet firmy, które „odniosły sukces we wdrażaniu zmiany”, są narażone na zagrożenia. Ludzie odchodzą, pojawiają się nowe perspektywy, a korporacyjne mody mogą zniweczyć osiągnięte postępy w adaptacyjności. Może pojawić się negatywny chaos.

Wielu graczy i modeli zaangażowania deklaruje wsparcie dla adaptacyjności na poziomie zarządczym, co jest pozytywne, ponieważ różne konteksty organizacyjne wymagają różnych podejść. Jednak pomimo dostępności licznych zasobów, ogólny krajobraz adaptacyjności na poziomie zarządczym nie zmienił się znacząco przez ponad 25 lat.

Niezależnie od tego, czy organizacja korzysta z taktyk, strategii, metod i frameworków, czy też nie, powinna najpierw przyjąć etos będący fundamentem, dwoistości strategii (ambidexterity)⁶ i, ludzkiej efektywności, adaptacyjności i terminowości na najwyższym szczeblu. W przeciwnym razie menedżerowie i członkowie zarządu nadal będą nadzorować „teatr zmiany” oraz niepełną mozaikę punktowych, terminowych, ludzkich i efektywnych praktyk w organizacji.

Eksponowanie zachowań Menedżerów

Postawa lub działania menedżerów i członków zarządu mają większy wpływ na nowe zachowania innych niż jakiekolwiek ich słowa czy polecenia. Niemniej jednak, warto zrewidować zadawane pytania, aby poprawić dwoistość strategii, ludzką efektywność, adaptacyjność i terminowość.

Dwoistość strategii, ludzka efektywność, adaptacyjność i terminowość wymagają ostatecznego wyeliminowania niespójnych zachowań na poziomie zarządczym. Przykładami bardziej pomocnych zachowań są: akceptowanie porażek, poszukiwanie informacji przed oceną, umożliwienie próbowania nowych rzeczy w celu nauki, akceptacja niewiedzy oraz pomaganie ludziom w skupieniu się. Istnieje kilka godnych uwagi sposobów radzenia sobie z zachowaniami kadry zarządzającej.

Immunity To Change®

Lisa Laskow Lahey i Robert Kegan (główni eksperci w The Developmental Edge) stworzyli podejście do zmiany znane jako Immunity to Change® (3,4). Ludzie często wiedzą, co powinni zrobić, ale tego nie robią z powodu wewnętrznych, sprzecznych zobowiązań. W przenośni mają „jedną nogę na gazie, a drugą na hamulcu”.

Immunity to Change® to framework pozwalający zdefiniować te „ukryte zobowiązania” i „ograniczające założenia”, które powstrzymują ludzi przed zmianą i realizacją ich celów. Teoria i mapa Immunity to Change® pomogły niezliczonym profesjonalistom i organizacjom odkryć oraz przekroczyć zobowiązania blokujące ich rozwój zawodowy i organizacyjny.

Intent-Based Leadership®

Intent-Based Leadership® (IBL) (7, 8, 9) to język wykorzystywany przez zespoły do osiągania wysokiej wydajności, który zastępuje zaprogramowany język ery przemysłowej. IBL podkreśla znaczenie intencji zarówno liderów, jak i zespołu. Opiera się na książkach „Turn The Ship Around” oraz „Leadership is Language” autorstwa L. Davida Marqueta.

Jednym z podstawowych przekonań jest to, że przywództwo nie jest zarezerwowane tylko dla wybranych na szczycie. W wysoce efektywnych organizacjach liderzy są obecni na każdym poziomie. L. David Marquet przekształcił model przywództwa, który wypracował na okręcie podwodnym o napędzie jądrowym USS Santa Fe, w system zwany Intent-Based Leadership, który Twoja organizacja może wdrożyć, by zaprosić do myślenia i przywództwa na każdym szczeblu.

Intent-Based Leadership pomaga liderom budować organizacje, w których ludzie osiągają pełnię swoich możliwości, ponieważ mają poczucie autonomii, korzystają z wewnętrznej motywacji, czują się wysłuchani i dążą do doskonałości. Pracownicy odczuwają wysoki poziom odpowiedzialności i kontroli, angażując zarówno serce, jak i umysł. Otrzymują psychologiczne nagrody, widząc efekty swoich decyzji i pracy. W organizacji dominuje skłonność do działania, a zespoły są bardziej zwinne i odporne, ponieważ ograniczone jest powstawanie i rozprzestrzenianie się błędów.

Praktyka komunikowania intencji umożliwia zespołom rozproszone podejmowanie decyzji przy jednoczesnym zachowaniu jedności wysiłku. Intent-Based Leadership International (IBLI) oferuje konsultacje, coaching, kursy online oraz książki dla liderów.

Sekcja 3: Wyjaśnienie frameworka modelu Cynefin nieoficjalne i nieautoryzowane.
Tytuł: Wyjaśnienie frameworka modelu Cynefin nieoficjalne i nieautoryzowane
Źródło: [Link do oryginału Cynefin wiki ], [Link do oryginału]
Licencja: Creative Commons Attribution-ShareAlike 4.0 International ( CC BY-SA 4.0 ). © 2017-2025 Cynefin.io.
Zastrzeżenie: Nie są udzielane żadne gwarancje. Korzystasz na własne ryzyko.
Ta sekcja jest udostępniana na licencji Creative Commons Attribution-ShareAlike 4.0 International.
Korzystając z tego „Wyjaśnienia ram modelu Cynefin nieoficjalnego i nieautoryzowanego”, akceptujesz warunki licencji CC BY-SA 4.0

Cynefin®

Cynefin® (30-35) oferuje kompas do podejmowania decyzji przywódczych. Zyskał popularność dzięki artykułowi HBR „A Leader’s Framework for Decision Making” autorstwa Dave’a Snowdena i Mary Boone z 2007 roku oraz publikacji „Managing complexity (and chaos) in a crisis - a field guide for decision makers inspired by the Cynefin framework”, znanej także jako „EU Field Guide”. Założeniem Cynefin jest to, że należy działać inaczej w zależności od dynamiki danego obszaru. Model ten bywa często nadmiernie upraszczany. Dany problem może jednocześnie istnieć we wszystkich domenach, z których każda posiada inne aspekty.

Przejście fazowe oznacza często nagłe przejście między domenami, szczególnie z uporządkowanej do chaosu, wywołane wtedy, gdy ograniczenia systemu (reguły, nawyki, granice i sprzężenia zwrotne) są niezsynchronizowane lub ulegają załamaniu. Oznacza to fundamentalną zmianę w zachowaniu systemu, w której dotychczasowe metody kontroli lub zrozumienia przestają działać.

Nie wszystkie aspekty rozwoju Produktu są złożone. Scrum Team, w danej sytuacji, może potrzebować rozważyć różne przejścia fazowe pomiędzy:

• Uporządkowany⁷: Kluczowa idea: stabilność, rutyna, najlepsze/dobre praktyki, ekspertyza

  • Ekspertyza jest wystarczająca, a związek przyczynowo-skutkowy jest przewidywalny lub możliwy do poznania
  • Możliwe reakcje obejmują, ale nie ograniczają się do: stosowania najlepszych/dobrych praktyk, przestrzegania zasad, korzystania z analizy eksperckiej, prowadzenia indywidualnych badań
  • Metafory: twarda lub ledwo zamrożona kostka lodu, przyjemna pogoda, szachy/sudoku
  • Przykład z natury: nowoczesna, klimatyzowana szklarnia - przewidywalny, kontrolowany, zaplanowany wzrost
  • Przykład produktowy: rozwiązywanie trudnego problemu technicznego poprzez konsultacje z ekspertami i analizę logów

• Złożony (30-35), gdzie ekspertyza jest cenna, ale niewystarczająca, a zrozumienie, dlaczego coś się wydarzyło, jest możliwe dopiero po fakcie. Kluczowa idea: emergencja, eksperymenty bezpieczne w razie niepowodzenia

  • Możliwe reakcje obejmują, ale nie ograniczają się do:
    • Wspierania uczenia się i adaptacji
    • Próbowania kilku małych, równoległych, eksperymentów o kontrolowanym ryzyku
    • Stymulowania świeżego myślenia poprzez różnorodność poznawczą i współpracę
    • Zapoznawania się z rozwiązaniami z innych obszarów, jeśli mogą pomóc
    • Testowania domysłów lub intuicji, by sprawdzić, co działa
  • Wszystko to odbywa się przy zachowaniu pomocnych wskazówek, które pozwalają na naturalny rozwój dobrych rezultatów
  • Metafory: płynąca woda, deszczowa pogoda, poker
  • Przykład z natury: gęstwina jeżyn – wszystko jest splątane, powiązania są nieprzewidywalne
  • Przykład produktowy: eksperymentowanie z różnymi funkcjami lub rozwiązaniami na podstawie opinii użytkowników, np. testy A/B nowych pomysłów na Produkt

• Chaotyczny:

  • Negatywny: Kluczowa idea: destrukcyjny kryzys, załamanie, pilne działanie
    • Możliwe reakcje (nie ograniczają się do): natychmiastowe działania w celu przywrócenia porządku, priorytetowe traktowanie bezpieczeństwa, szybkie działanie bez pogarszania sytuacji
    • Metafory: roztrzaskująca się tafla lodu lub niekontrolowana eksplozja, toksyczny gaz, tornado, trzęsienie ziemi, pożar lasu, zamieszki na stadionie
    • Przykład z natury: katastrofa naturalna (np. tsunami) - nagła, destrukcyjna, nieprzewidywalna
    • Przykład produktowy: reakcja na krytyczne naruszenie bezpieczeństwa poprzez izolację systemów i wdrożenie awaryjnych poprawek
  • Pozytywny: Kluczowa idea: twórczy przełom, szybka innowacja
    • Możliwe reakcje (nie ograniczają się do): celowe wprowadzenie zakłócenia, zachęcanie do kreatywności, wykorzystanie energii, np. hackathon, inkubator, „Innowacyjny Piątek”
    • Metafory: kontrolowana eksplozja (silnik parowy), fajerwerki, ognisko podczas festiwalu
    • Przykład z natury: pożar lasu usuwający stare rośliny i dający miejsce nowym - odnowa ekosystemu
    • Przykład produktowy: szybkie przestawienie Produktu podczas zakłócenia rynku, by wykorzystać nowe możliwości (np. wdrożenie funkcji w odpowiedzi na ruch konkurencji)

Liminalność (Liminality) to „stan pośredni”, coś na kształt progu. Często mniej gwałtowne przejścia fazowe mają miejsce właśnie w liminalnych obszarach.

• W liminalnym obszarze pomiędzy złożonością a uporządkowaniem znajduje się domyślna „strefa komfortu” Scruma:

  • Uporządkowanie-Złożoność:
    • Od analizy eksperckiej do adaptacyjnej eksploracji
    • Możliwe reakcje (nie ograniczają się do): poluzowanie niektórych zasad, wprowadzenie eksperymentowania, przygotowanie na emergencję
    • Metafory: topniejąca kostka lodu, pochmurna pogoda, przejście z szachów do pokera
    • Przykład z natury: wiosenne roztopy - sztywny lód ustępuje miejsca płynącym strumieniom i nowemu wzrostowi
    • Przykład produktowy: gdy rutynowy proces przestaje działać, zachęć zespół do wypróbowania różnych podejść
  • Złożoność-Uporządkowanie:
    • Możliwe reakcje (nie ograniczają się do): przekształcanie kreatywnych odkryć w eksperckie rutyny; stabilizowanie innowacji, obserwowanie i kodyfikowanie skutecznych wzorców; przejście do standaryzacji
    • Metafory: breja (między lodem a wodą), mgła ustępująca po deszczu, przejście z pokera do szachów
    • Przykład z natury: delta rzeki tworząca kanały - od nieprzewidywalnych do stabilnych przepływów
    • Przykład produktowy: przekształcenie udanej eksperymentalnej funkcji w udokumentowany, powtarzalny proces

• W liminalnym obszarze pomiędzy złożonością a chaosem:

  • Złożoność-Chaos (pozytywny):
    • Sytuacja, w której należy poluzować ograniczenia, aby stworzyć czas i przestrzeń dla innowacji lub wynalazczości. Kluczowa idea: granica kreatywności, ryzyka i innowacji
    • Możliwe reakcje (nie ograniczają się do): rozluźnienie ograniczeń, zachęcanie do eksperymentowania, poszukiwanie przełomowych pomysłów
    • Metafory: wrząca woda (na granicy pary), wybuchająca burza, improwizowany teatr, jazzowa jam session
    • Przykład z natury: wulkan tworzący nowy ląd - twórcza transformacja na granicy chaosu
    • Przykład produktowy: organizacja ryzykownego hackathonu innowacyjnego w celu wygenerowania przełomowych pomysłów
  • Złożoność-Chaos (negatywny):
    • Kluczowa idea: destrukcyjne przejście w kryzys
    • Możliwe reakcje (nie ograniczają się do): szybkie przywrócenie ograniczeń, stabilizacja sytuacji, zapobieganie dalszemu rozpadowi
    • Metafory: wybuchający szybkowar, nagłe tornado lub gwałtowna powódź, rozrzucone w gniewie pionki do gry, przewrócona plansza
    • Przykład z natury: nagłe osuwisko - utrata struktury, destrukcyjne przejście
    • Przykład produktowy: chaos po nieudanym wdrożeniu Produktu i pilna potrzeba odzyskania kontroli
  • Chaos-Złożoność: Wychodzenie z chaosu - ponowne zebranie się
    • Możliwe reakcje (nie ograniczają się do): dostrzeganie wyłaniającego się porządku, rozpoczęcie eksploracji, wspieranie współpracy, rozpoznawanie wzorców
    • Metafory: para skraplająca się w wodę, cisza po huraganie, wznowienie meczu po burzy
    • Przykład z natury: gatunki pionierskie zasiedlające teren po pożarze - nowy wzrost po zakłóceniu
    • Przykład produktowy: po kryzysie ponowne zebranie zespołu, by eksperymentować z nowymi sposobami pracy lub nowymi kierunkami rozwoju Produktu

• Aporia (liminalność paradoksalna): zatrzymanie się przy paradoksie w celu uzyskania nowego wglądu, być może po uświadomieniu sobie, że sytuacja nie była taka, jak się wydawało

  • Możliwe reakcje: utrzymywanie niejednoznaczności, zachęcanie do refleksji, pozwolenie na pojawienie się nowego zrozumienia
  • Metafory: punkt potrójny (współistnienie stanu stałego, ciekłego i gazowego), stanie w oku cyklonu, rozwiązywanie zagadki
  • Przykład z natury: estuarium, gdzie rzeka, morze i ląd się spotykają - współistnieją wszystkie stany i możliwości
  • Przykład produktowy: zespół utknął pomiędzy sprzecznymi strategiami lub wizjami i powinien na chwilę się zatrzymać, by się zastanowić i ponownie wyrównać kierunek działania

• Rzadko rozważane przejście fazowe ze względu na poziom trudności: liminalność chaotyczno-uporządkowana

  • Możliwe reakcje: nałożenie silnych ograniczeń, ponowne ustanowienie reguł i struktury
  • Metafory: szybkie ponowne zamarzanie lodu, nagłe ochłodzenie po burzy, sędzia, który skutecznie przywraca porządek po chaosie
  • Przykład z natury: tama skutecznie zbudowana po powodzi - dzika rzeka nagle ujarzmiona i kontrolowana
  • Przykład produktowy:
    • Po poważnej awarii produkcyjnej lub kryzysie Produktu, przekrojowy zespół kryzysowy szybko stabilizuje sytuację za pomocą jasnych, minimalnych zasad i tymczasowych protokołów
    • Gdy bezpośrednie zagrożenie minie, te zasady są iteracyjnie udoskonalane i formalizowane w trwałe, zrównoważone procesy, unikając nadmiernej korekty lub biurokracji

Jedno z przejść fazowych jest szczególnie nagłe i negatywne - to liminalność uporządkowanie-chaos:

• Możliwe reakcje: rozpoznanie kruchości i nadmiernej pewności siebie, szybkie działanie w celu przywrócenia granic i bezpieczeństwa
• Metafory: lód pękający na odłamki, nagła i gwałtowna burza gradowa, nagłe odrzucenie zasad gry
• Przykład z natury: zamarznięte jezioro rozpadające się wiosną - stabilna powierzchnia nagle się rozpada
• Przykład produktowy: stabilny proces Produktu nagle się załamuje z powodu nieoczekiwanego zdarzenia (np. poważna awaria produkcyjna)

Sekcja 4: Strategia emergentna
Autorzy: Roger L. Martin, Tom Gilb
Źródła: (41-48)
Copyright: Wszelkie prawa zastrzeżone. Dostosowane

Strategia emergentna

Strategia nie jest ograniczona skalą; jeśli istnieje, powinna być jasno określona na poziomie korporacyjnym, jednostki biznesowej lub Produktu i pozostawać spójna oraz zintegrowana na wszystkich tych poziomach. Kluczowe jest, aby strategia rozróżniała cele końcowe (skwantyfikowane, cenione przez Interesariuszy outcomes) od środków (inicjatyw lub działań).

Czerpiąc i adaptując prace Rogera L. Martina (41) oraz Toma Gilba (43-48), strategia polega na podejmowaniu zintegrowanych, jawnych wyborów - decydowaniu, co realizować, a czego nie, na podstawie jasno zdefiniowanej, mierzalnej aspiracji zwycięstwa, a nie tylko szeroko rozumianej misji czy wizji. Skuteczna strategia odpowiada na pytania:

• Gdzie będziemy działać?
• Jak wygramy w sposób etyczny (57) i zrównoważony, równoważąc wiele oczekiwań i ograniczeń?
• Jakie zdolności i systemy muszą być zapewnione?
• Co jeszcze musi być prawdziwe, aby ta strategia mogła się powieść?

Dla sytuacji, w których sama ekspertyza jest wystarczająca (lub niemal wystarczająca), aby zapewnić, że strategia jest iteracyjna, wykonalna i skoncentrowana na wartości:

• Iteracyjnie mierz i zarządzaj wartością dla Interesariuszy, wieloma wpływami lub skutkami ubocznymi, ryzykiem i kompromisami:
  • Zidentyfikuj wszystkich kluczowych Interesariuszy (w tym, ale nie tylko, klientów) i określ ich cele względem wartości w mierzalnych kategoriach (np. „skrócenie czasu wdrożenia nowego użytkownika z 5-10 do 2-4 dni”).
  • Wyraźnie mierz kompromisy i ograniczenia oraz wracaj do nich, gdy pojawią się nowe informacje.
  • Wykorzystuj myślenie integracyjne do kreatywnego rozwiązywania napięć.
• Współtwórz i priorytetyzuj w sposób kolaboracyjny:
  • Twórz strategię, łącząc perspektywy z góry na dół i z dołu do góry oraz współpracę lateralną.
  • Wykorzystuj strukturalne warsztaty i pętle informacji zwrotnej, aby wspierać spójność, adaptacyjność i ciągłą repriorytetyzację niewykonanej pracy.
• Dostarczaj wartość przyrostowo i mierz wyniki:
  • Iteracyjnie rozbijaj strategiczne aspiracje na małe, priorytetyzowane, mierzalne incrementy.
  • Dostarczaj wartość w krótkich cyklach (np. Sprintach lub tygodniach), mierząc rzeczywiste outcomes i skutki uboczne względem pierwotnych, wymiernych celów.
  • Wykorzystuj regularne przeglądy do dostosowywania działań na podstawie rzeczywistej informacji zwrotnej.
• Umożliwiaj emergencję:
  • Pozwól strategii ewoluować w odpowiedzi na nowe dane i informację zwrotną od Interesariuszy (w tym, ale nie tylko, użytkowników), w ramach jasnych, skwantyfikowanych celów, mierzalnych trendów i regularnej oceny ryzyk/korzyści.
  • Wprowadzaj korekty kursu szybko i przejrzyście, gdy rzeczywistość się zmienia.
• Zapewnij, by strategia i jej wdrożenie były zorientowane na outcomes i skupione (decydując, nad czym pracować, a czego nie robić). Rozróżniaj:
  • Strategię, obejmującą intencje, uzasadnienie, cele i anty cele (co i dlaczego),
  • Wdrożenie strategii: operacjonalizację strategii, iteracyjne sekwencjonowanie lub dekompozycję zintegrowanych wyborów dla strategii, zwykle w małych, zorientowanych na outcome fragmentach tego co i dlaczego,
  • Zorientowane na outcome, skupione elementy Product Backlogu (mniejsze fragmenty dla kogo),
  • Listy aktywności lub inicjatyw (“co zrobimy” lub jak).
• Unikaj mylenia zbioru projektów ze spójną, opartą na wartości strategią.

Dla sytuacji, w których ekspertyza jest cenna, ale niewystarczająca, związek przyczynowo-skutkowy jest czytelny dopiero po fakcie, a niepewność trzeba zaakceptować, Scrum Team i Interesariusze powinni:

• Zaakceptować nieuporządkowany charakter pracy zorientowanej na wyniki, opartej na emergencji, w wybranym kierunku działania.
• Przyjąć, że szczegółowe, długoterminowe plany są nieskuteczne. Zamiast tego organizacja powinna tworzyć warunki, w których użyteczne wzorce i innowacje mogą wyłaniać się z interakcji w systemie.
• Zamiast testować po jednej idei i trzymać się tego, co działało wcześniej, Scrum Team powinien równolegle prowadzić kilka małych, eksperymentów o kontrolowanym ryzyku, by obserwować efekty i uczyć się z tego, co się wyłania.
• Budować klimat sprzyjający kreatywnej eksploracji, innowacji i ewolucji od obecnego stanu. Tworzyć procesy i środowiska, w których ludzie mogą łączyć nowe pomysły, wnioski, przemyślane intuicje i uczyć się od siebie nawzajem, zamiast narzucać jednolitość czy sztywne KPI.
• Możliwe reakcje obejmują, ale nie ograniczają się do:
  • Mapowania tego, co już wiadomo, i rozumienia potencjału ewolucyjnego systemu przed podjęciem zmiany
  • Wspierania samoorganizacji
  • Przeprowadzania eksperymentów o kontrolowanym ryzyku (prób) - powinny być małe, równoległe i zaprojektowane tak, by ewentualne niepowodzenie było możliwe do przeżycia i pouczające
  • Poszukiwania świeżego spojrzenia
  • Prób rozwiązań różnych problemów w obecnej sytuacji
  • Testowania przemyślanych intuicji
  • Obserwowania tego, co się wyłania, wzmacniania skutecznych wzorców i wygaszania lub zatrzymywania tych, które nie działają
  • Innowacje są ważne, ale sprawdzone rozwiązania należy wykorzystywać przy powtarzających się problemach
  • Ciągłego nadawania sensu (sense-making)
  • Zbierania i analizowania narracji
• Metafora: Rola liderów polega na aktywnym przygotowaniu i zarządzaniu „glebą”, granicami i warunkami (substratem), by zachęcać do wzrostu zdrowych roślin (rozwiązań emergentnych). Obejmuje to metaforyczne odchwaszczanie, przycinanie i kształtowanie środowiska, a nie tylko bierne oczekiwanie na efekty.

Zasadniczo nagrody oparte na motywacji zewnętrznej powinny być unikane ze względu na efekt kobry (104), chyba że są spójne z podejściem Beyond Budgeting. Również indywidualne lub zespołowe wyniki nie powinny być bezpośrednio powiązane z rezultatami, ponieważ rezultaty mogły zostać osiągnięte, ale istotne jest, w jaki sposób zostały osiągnięte, z jakimi skutkami ubocznymi i jaki wpływ miało to na morale zespołu itd.

Niemniej jednak:

• W recenzowanej literaturze naukowej (105-108) oraz w podstawowym artykule nierecenzowanym (109) istnieją rozbieżności co do tego, czy mierzenie oczekiwań Interesariuszy, ich ograniczeń lub celów jest pomocne czy szkodliwe oraz czy obniża motywację wewnętrzną.
• Należy brać pod uwagę kontekst. Warto także rozważyć, czy mierzenie wspiera autonomię i poczucie sensu, czy raczej narzuca kontrolujące ograniczenia.
• Na ten moment niniejszy dokument skłania się ku ostrożności i preferuje doprecyzowanie oraz wspólne rozumienie idei - poprzez kwantyfikację oczekiwań interesariuszy, ograniczeń interesariuszy oraz kierunku działania - wspartą wysokiej jakości, trafnymi narracjami (więcej historii tego typu, mniej historii tamtego typu).

Strategia emergentna jest wspierana przez emergentną, zorientowaną na outcomes roadmapę, która może obejmować wszystko od Celu Sprintu po Wizję Produktu, a nawet dalej. Wdrażanie strategii emergentnej (120-123) nie powinno być mylone ze strategią emergentną. Modele zmiany wektorowej (30-35, 54), Product Operating Models (113-119), modele skalowania i deskalowania (134-147) oraz emergentne modele zorientowane na cele (120-133) mogą być bardzo pomocne przy wdrażaniu strategii emergentnej. Zaleca się wybierać modele spójne z podejściem zmiany wektorowej, np. kierunek działania zamiast sztywnych celów. Wdrażanie strategii emergentnej polega na umożliwieniu, by plany i działania rozwijały się naturalnie, gdy Scrum Team i Interesariusze reagują na rzeczywiste zmiany. Zamiast podążać ustaloną ścieżką, zwracają uwagę na to, co dzieje się wokół nich i dostosowują się w trakcie. Z czasem podjęte kroki tworzą wzorzec, który staje się faktyczną strategią, nawet jeśli odbiega od pierwotnych założeń.

Przypisanie autorstwa dla zbioru Scrum Guide: Rozszerzenia

Niniejszy zbiór został napisany i zredagowany przez Ralpha Jochama, Johna Colemana i Jeffa Sutherlanda. Każda sekcja ma przypisane indywidualne autorstwo powyżej i zachowuje swoją oryginalną licencję. Cały zbiór służy wyłącznie celom informacyjnym; prosimy o przestrzeganie warunków licencyjnych każdej sekcji.

Nota od tłumaczy

Podziękowania

Dziękujemy recenzentom, którzy wsparli nas w ulepszeniu niniejszego tłumaczenia:

Oraz wszystkim innym, którzy podzieli się z nami informacją zwrotną.

Historia tłumaczenia

Przypisy

Bibliografia

1. Rau, T. (2022) Sociocracy - Basic Concepts and principles, Sociocracy For All. At: https://www.sociocracyforall.org/sociocracy/ (Accessed: April 5, 2023).
2. Hamel, G. and Zanini, M. (2023) Humanocracy. At: https://www.humanocracy.com/ (Accessed: April 5, 2023).
3. Kegan, R. and Laskow Lahey, L. (2019) An everyone culture, The Developmental Edge. At: https://developmentaledge.com/an-everyone-culture/ (Accessed: April 4, 2023).
4. Laskow Lahey, L. and Kegan, R. (2023) News & thinking, The Developmental Edge. At: https://developmentaledge.com/newsthinking/#methodologies (Accessed: April 3, 2023).
5. Moore, G.A., 1991. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. New York: Harper Business.
6. Coleman, J., (2025) MORE executive SUCCESS. Unpublished.
7. Marquet, L. D. (2013) Turn the Ship Around! A True Story of Turning Followers into Leaders. Portfolio.
8. Marquet, L.D. (2021) Leadership is language: The hidden power of what you say and what you don’t. Nakskov, Denmark: Nota.
9. Marquet, L. D. (2021) Based Leadership® International with L. David Marquet - IBLI. At: https://davidmarquet.com/ (Accessed: April 5, 2023).
10. Rau, T.J. and Koch-Gonzalez, J. (2018) Many voices one song: Shared power with sociocracy. Amherst, MA: Sociocracy for All.
11. Buck, J. & Endenburg, G. (2012) The creative forces of self-organization. Sociocratic Center.
12. Buck, J. & Villines, S. (2017) We the people: Consenting to a deeper democracy. 2nd edn. Sociocracy.info Press.
13. Endenburg, G. (1998) Sociocracy: The organization of decision-making. Delft: Eburon Publishers.
14. Priest, J. & Bockelbrink, B. (2018) Sociocracy 3.0 - The practical guide. Available at: https://sociocracy30.org/ (Accessed: 17 May 2025).
15. Bogsnes, B. (2023) This is beyond budgeting: A guide to more adaptive and human organizations. Hoboken, NJ: John Wiley & Sons, Inc.
16. Bogsnes, B. (2023) Beyond budgeting at 25 - bbrt.org , Beyond Budgeting Round Table. At: https://bbrt.org/wp-content/uploads/bb-white-paper_a.pdf (Accessed: April 7, 2023).
17. Olesen, A. (2016) Beyond budgeting: Principle 1 - purpose, YouTube. At: https://youtu.be/_9ZW2NjyFxE (Accessed: April 7, 2023).
18. Larsson, D. (2016) Beyond budgeting: Principle 2 - values, YouTube. At: https://youtu.be/pl1BPrITbm4 (Accessed: April 7, 2023).
19. Player, S. (2016) Beyond budgeting: Principle 3 - transparency, YouTube. At: https://youtu.be/Mb7K8App2vw (Accessed: April 7, 2023).
20. Röösli, F. (2016) Beyond budgeting: Principle 4 - Organization, YouTube. At: https://youtu.be/i8HIgc8OZYM (Accessed: April 7, 2023).
21. Larsson, D. (2016) Beyond budgeting: Principle 5 - autonomy, YouTube. At: https://youtu.be/ipnjHtXYi-g (Accessed: April 7, 2023).
22. Player, S. (2016) Beyond budgeting: Principle 6 - customers, YouTube. At: https://youtu.be/_6fut4R_wVw (Accessed: April 7, 2023).
23. Bogsnes, B. (2016) Beyond budgeting: Principle 7 - rhythm, YouTube. At: https://youtu.be/rb_NsnPNIQQ (Accessed: April 7, 2023).
24. Röösli, F. (2016) Beyond budgeting: Principle 8 - targets, YouTube. At: https://youtu.be/up3mp7jN6XU (Accessed: April 7, 2023).
25. Player, S. (2016) Beyond budgeting: Principle 9 - plans and forecasts, YouTube. At: https://youtu.be/OWM7FUuXejI (Accessed: April 7, 2023).
26. Olesen, A. (2016) Beyond budgeting: Principle 10 - resource allocation, YouTube. At: https://youtu.be/mPCYHmvi_b8 (Accessed: April 7, 2023).
27. Bogsnes, B. (2016) Beyond budgeting: Principle 11 - performance evaluation, YouTube. At: https://youtu.be/RfPVtG2B27E (Accessed: April 7, 2023).
28. Röösli, F. (2016) Beyond budgeting: Principle 12 - rewards, YouTube. At: https://youtu.be/ETU5TzNYiC0 (Accessed: April 7, 2023).
29. Takeuchi, H. and Nonaka, I. (2014) The new new product development game, Harvard Business Review. At: https://hbr.org/1986/01/the-new-new-product-development-game (Accessed: 21 January 2024).
30. Cynefin.io , V. (2022) Cynefin wiki, Cynefin.io . Cynefin.io . At: https://cynefin.io/ (Accessed: April 4, 2023).
31. Rancati, A. and Snowden, D. (2021) Managing complexity (and chaos) in a crisis - a field guide for decision makers inspired by the Cynefin framework. Luxembourg, Belgium: Publications Office of the European Union.
32. Snowden, D. et al. (2022) Cynefin® weaving sense-making into the fabric of our world. 2nd edn. Edited by R. Greenberg and B. Bertsch. Singapore, Singapore: Cognitive Edge - The Cynefin Co.
33. Snowden, D. (2023) Cynefin St David’s 2023 1 of 2, Cynefin Co. https://thecynefin.co/cynefin-st-davids-2023-1-of-2/ (Accessed: April 20, 2023).
34. Snowden, D. (2023) Managing for emergence through abduction, The Cynefin Co. At: https://thecynefin.co/managing-for-emergence/ (Accessed: June 24, 2023).
35. Snowden, D. and Smith, N. (2023) Leadership discussion: Dave and Natalie - the Cynefin co, YouTube. At: https://youtu.be/WcPZ8ybDF0w (Accessed: April 7, 2023).
36. Langton, C.G. (ed.) (1989) Artificial Life: Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems, Los Alamos, New Mexico, September 1987. Santa Fe Institute Studies in the Sciences of Complexity, vol. VI. Redwood City, CA: Addison-Wesley.
37. Langton, C.G. (1989) ‘Life at the edge of chaos’, in Langton, C.G. (ed.) Artificial Life: Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems. Santa Fe In stitute Studies in the Sciences of Complexity, vol. VI. Redwood City, CA: Addison-Wesley, pp. 41-91.
38. Wolfram, S. (2002) A new kind of science. Champaign, IL: Wolfram Media.
39. Alexander, C. (1979) The timeless way of building. New York: Oxford University Press.
40. Schwaber, K. & Sutherland, J. (2020) The Scrum Guide: The definitive guide to Scrum: The rules of the game. Available at: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf (Accessed: 17 May 2025)
41. Martin, R.L. (2022) A new way to think your guide to Superior Management Effectiveness. Boston, MA, MA, USA: Harvard Business Review Press.
42. Gilb, T. & Graham, D. (1993) Software Inspection. Harlow: Addison-Wesley.
43. Gilb, T. (1988) ‘Deeper perspectives on evolutionary delivery, in Principles of Software Engineering Management. Wokingham: Addison-Wesley, pp. [chapter 15]. Also available at: https://bit.ly/TomGilbEvo .
44. Gilb, Tom & Maier, Mark. (2005). Managing Priorities: A Key to Systematic Decision Making. INCOSE International Symposium. 15. 10.1002/j.2334-5837.2005.tb00782.x. Also available at: https://bit.ly/TomGilbPriorities .
45. Gilb, T. (1988) ‘Deeper perspectives on evolutionary delivery’, in Principles of Software Engineering Management. Wokingham: Addison-Wesley, pp. [chapter 15].
46. Gilb, T. (2005) Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Oxford: Elsevier Butterworth-Heinemann. Also available at: https://bit.ly/TomGilbCompEng .
47. Gilb, T. (2009) ‘Agile specification quality control: Shifting emphasis from cleanup to sampling defects’, Testing Experience, March. Available at: https://www.researchgate.net/publication/294196272_Agile_specification_quality_control [Accessed: 17 May 2025].
48. Gilb, T. & Gilb, K. (1989) ‘The McDonnell-Douglas case study of SQC and engineering improvement: Case DAC Inspection 1988-89’. Available at: https://bit.ly/TomGilbMcDonnell-Douglas [Accessed: 17 May 2025].
49. LeSS.works (n.d.) Self-managing teams. Available at: https://less.works/less/management/self-managing-teams (Accessed: 17 May 2025).
50. Gothelf, J. & Seiden, J. (2021) Lean UX: Designing great products with agile teams. 3rd edn. Sebastopol, CA: O’Reilly Media
51. Torres, T. (2021) Continuous discovery habits: Discover products that create customer value and business value. North Charleston, SC: Product Talk
52. Scrum.org (2025) Scrum Hexis. Available at: https://thecynefin.co/product/hexi-scrumorg/?srsltid=AfmBOorcohLYeVy0qBsQFI6mK_bZtJA_uGC6hPL2BdptiTwNmMwpKTQv (Accessed: 17 May 2025).
53. Sutherland, J., Coplien, J.O., Heasman, L., den Hollander, M., Ramos, C. and The Scrum Patterns Group (2019) A Scrum Book: The Spirit of the Game. Raleigh, NC: Pragmatic Press.
    Members of The Scrum Patterns Group: Vervloed, E., Harrison, N., Harada, K., Yoder, J., Kim, J., O’Callaghan, A., Beedle, M., Bjørnvig, G., Friis, D., Reijonen, V., Benefield, G., Østergaard, J., Eloranta, V.-P., Leonard, E. & Aguiar, A.
54. Snowden, D. (2025) ‘Estuarine mapping first edition’, The Cynefin Co, 22 April. Available at: https://thecynefin.co/estuarine-mapping/ (Accessed: 8 June 2025)
55. Ackoff, R.L. (1999) Ackoff’s Best: His Classic Writings on Management. New York: John Wiley & Sons.
56. Fischer, B., Minnaar, J., Moehrle, M., & Cornuel, E. (2020) RenDanHeYi: Pioneering the Quantum Organisation. EFMD Global Focus, Special Supplement. Available at: https://bit.ly/RenDanHeYi [Accessed 27 May 2025]
57. Blackburn, S. (2003) Ethics: A Very Short Introduction. Oxford: Oxford University Press.
58. Mayer, T. (2025) A Simple Guide to Scrum. [Online]. Available at: https://scrum.academy/guide/ (Accessed: 17 May 2025)
59. Ohno, T. (1988) Toyota Production System: Beyond Large-Scale Production. Portland, OR: Productivity Press.
60. Toyota Motor Corporation (2024) Toyota Production System. Available at: https://global.toyota/en/company/vision-and-philosophy/production-system/index.html (Accessed: 17 May 2025).
61. Hounshell, D.A. & Smith, J.K. (1988) Science and Corporate Strategy: DuPont R&D, 1902-1980. Cambridge: Cambridge University Press.
62. Schwaber, K. and Sutherland, J. (1995) ‘SCRUM Development Process’, OOPSLA Business Object Design and Implementation Workshop. Austin, Texas, October 1995. Available at: http://jeffsutherland.org/oopsla/schwapub.pdf (Accessed: 17 May 2025).
63. Womack, J.P. and Jones, D.T. (1996) Lean Thinking: Banish Waste and Create Wealth in Your Corporation. New York: Simon & Schuster.
64. Thurlow, N., Turner, J.R. and Podder, A. (2020) The Flow System: The Evolution of Agile and Lean Thinking in an Age of Complexity. Flow Consortium. Available at: https://flowguides.org/Flow_Guide.pdf (Accessed: 17 May 2025).
65. Felderer, M. and Travassos, G.H. (2020) ‘The Evolution of Empirical Methods in Software Engineering’. Available at: https://arxiv.org/pdf/1912.11512.pdf (Accessed: 17 May 2025).
66. Creative Wisdom (n.d.) ‘Abduction, Deduction and Induction’. Available at: https://www.creative-wisdom.com/teaching/WBI/abduction5.pdf (Accessed: 17 May 2025).
67. Campbell, J. (2025) ‘Empiricism’, EBSCO Research Starters. Available at: https://www.ebsco.com/research-starters/religion-and-philosophy/empiricism (Accessed: 17 May 2025)
68. Kanban Guides (2025) Available at: https://kanbanguides.org (Accessed: 17 May 2025)
69. Scrum.org et al. (2021) The Kanban Guide for Scrum Teams. Available at: https://www.scrum.org/resources/kanban-guide-scrum-teams (Accessed: 17 May 2025)
70. Csíkszentmihályi, M. (1990) Flow: The Psychology of Optimal Experience. New York: Harper & Row
71. Templeton Foundation (2023) ‘What Is Emergence?’ John Templeton Foundation. Available at: https://www.templeton.org/news/what-is-emergence (Accessed: 17 May 2025).
72. van der Bles, A.M., van der Linden, S., Freeman, A.L.J. and Spiegelhalter, D.J. (2019) ‘Communicating uncertainty about facts, numbers and science’, Royal Society Open Science, 6(5), 181870. Available at: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6549952/ (Accessed: 17 May 2025).
73. Morieux, Y. (2015) How too many rules at work keep you from getting things done: Yves Morieux: Ted Talks, YouTube. At: https://youtu.be/t NoFstCmQ (April 3, 2023).
74. Holland, J.H. (1992) Complex Adaptive Systems. Daedalus, 121(1), pp. 17-30. Available at: https://www.jstor.org/stable/20025416 (Accessed: 17 May 2025).
75. Axelrod, R. and Cohen, M.D. (2000) Harnessing Complexity: Organizational Implications of a Scientific Frontier. New York: Free Press.
76. Juarrero, A. (1999) Dynamics in Action: Intentional Behavior as a Complex System. Cambridge, MA: MIT Press.
77. Snowden, D.J. and Boone, M.E. (2007) ‘A leader’s framework for decision making’, Harvard Business Review, 85(11), pp. 68-76. Available at: https://hbr.org/2007/11/a-leaders-framework-for-decision-making (Accessed: 17 May 2025)
78. Dictionary Marketing (2024) ‘B2B2B’. Available at: https://dictionarymarketing.com/definition/b2b2b/ (Accessed: 17 May 2025).
79. NetSuite (2023) ‘What Is Business to Business to Consumer (B2B2C)?’ Available at: https://www.netsuite.com/portal/resource/articles/ecommerce/b2b2c.shtml (Accessed: 17 May 2025).
80. LeSS (n.d.) ‘Why LeSS? Achieving adaptiveness’. Available at: https://less.works/less/framework/why-less (Accessed: 17 May 2025).
81. Sociocracy For All (n.d.) ‘Gerard Endenburg: founder of Sociocratic Circle Method and pioneer of self-management’. Available at: https://www.sociocracyforall.org/gerard-endenburg-founder-of-sociocratic-circle-method-and-pioneer-of-self-management/ (Accessed: 18 May 2025).
82. Patton, J. and Economy, P. (2014) User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol, CA: O’Reilly Media.
83. Kotter, J.P., 1996. Leading Change. Boston: Harvard Business School Press.
84. ‘Genchi Genbutsu’ (2024) Wikipedia. Available at: https://en.wikipedia.org/wiki/Genchi_Genbutsu (Accessed: 18 May 2025).
85. ScrumPlop, n.d. Illigitimus Non Interruptis. The Scrum Book: The Spirit of the Game. Available at: https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/illegitimus-non-interruptus [Accessed: 18 May 2025].
86. Cagan, M., 2018. Inspired: How to Create Tech Products Customers Love. 2nd ed. Hoboken, NJ: Wiley.
87. Cagan, M. & Jones, C., 2020. Empowered: Ordinary People, Extraordinary Products. Hoboken, NJ: Wiley.
88. Cagan, M., 2024. Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley.
89. Schwaber, K. (2023) ‘Scrum Guide’, Ken Schwaber’s Blog, 25 September. Available at: https://kenschwaber.wordpress.com/2023/09/25/scrum-guide/ (Accessed: 20 May 2025).
90. Future Ready: How to Master Business Forecasting
    Morlidge, S. & Player, S., 2010. Future Ready: How to Master Business Forecasting. Chichester: John Wiley & Sons.
91. The Little Book of Beyond Budgeting
    Morlidge, S., 2024. The Little Book of Beyond Budgeting: A New Management Model for Organisations (Second Edition) [Beyond Books Press]
92. The Little (Illustrated) Book of Operational Forecasting
    Morlidge, S., 2019. The Little (Illustrated) Book of Operational Forecasting. [Troubador].
93. Present Sense
    Morlidge, S., 2019. Present Sense. [Troubador].
94. Zen and the Art of Organising Work
    Morlidge, S., 2021. Zen and the Art of Organising Work. [Troubador].
95. Cost Matters
    Morlidge, S., 2023. Cost Matters. [Beyond Books Press].
96. Beyond Budgeting i praktiken Fahlén, K., 2016. Beyond Budgeting i praktiken. Stockholm: Liber.
97. Fahlén, K., 2018. Dynamic Management Strategy: A guide to management innovation and competitive advantage. Gothenburg: BAS
98. Bogsnes, B., 2016. Implementing Beyond Budgeting: Unlocking the Performance Potential. 2nd ed. Chichester: John Wiley & Sons.
99. Boyd, J.R. (1995-1996) The Essence of Winning and Losing. Unpublished briefing slides. Note: Boyd’s OODA was primarily disseminated through military briefings and unpublished manuscripts. His final conceptualization appears in The Essence of Winning and Losing, which emphasizes nonlinear decision-making and adaptation in complex environments.
100. Turner, J.R., Thurlow, N. and Rivera, B. (2019) The Flow System Guide. Available at: https://flowguides.org/Flow_Guide.pdf (Accessed: 24 May 2025). Summary: This guide integrates Boyd’s OODA with complexity theory and agile practices, framing it as a dynamic, non-linear decision-making process for organizational flow.
101. Williamson, P.J. & Yin, E. (2018) ‘Management Innovation Made in China: Haier’s Rendanheyi’, California Management Review, 61(1), pp. 71-93.
102. Richards, C. (2004) Certain to Win: The Strategy of John Boyd, Applied to Business. Bloomington, IN: Xlibris
103. Becker, S et al (co-author) The Viable Map Workbook 2023 [Beyond Books Press]
104. Frey, B.S. and Jegen, R. (2001) ‘Motivation crowding theory’, Journal of Economic Surveys, 15(5), pp. 589-611.
105. Cameron, J., Banko, K.M. and Pierce, W.D. (2001) ‘Pervasive negative effects of rewards on intrinsic motivation: The myth continues’, The Behavior Analyst, 24(1), pp. 1-44.
106. Deci, E.L., Koestner, R. and Ryan, R.M. (1999) ‘A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation’, Psychological Bulletin, 125(6), pp. 627-668.
107. Ryan, R.M. and Deci, E.L. (2000) ‘Intrinsic and extrinsic motivations: Classic definitions and new directions’, Contemporary Educational Psychology, 25(1), pp. 54-67.
108. Sandel, M.J. (2012) What money can’t buy: The moral limits of markets. London: Allen Lane.
109. Kohn, A. (1993) ‘Why incentive plans cannot work’, Harvard Business Review, 71(5), pp. 54-63.
110. Fuzzy Business: How to be roughly right rather than precisely wrong (unpublished).
111. Lewis, R. (2023) An operating model for business agility: Agile for managers of the digital age. Independently published.
112. less.works (n.d.) Technical Excellence. Available at: https://less.works/less/technical-excellence (Accessed: 7 June 2025)
113. Cagan, M. (2024) Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley.
114. Cagan, M. (2025) ‘The Product Operating Model’, Silicon Valley Product Group, 17 March. Available at: https://www.svpg.com/the-product-operating-model/ (Accessed: 8 June 2025).
115. Cagan, M. (n.d.) ‘The Product Operating Model: An Introduction’, Silicon Valley Product Group. Available at: https://www.svpg.com/the-product-operating-model-an-introduction/ (Accessed: 8 June 2025)
116. Scrum.org (2025) ‘The Agile Product Operating Model’, Scrum.org, 1 May. Available at: https://www.scrum.org/resources/agile-product-operating-model (Accessed: 8 June 2025).
117. Scrum.org (2025) ‘Agile Product Operating Model State of Play - Part 1 - Fundamentals’, Scrum.org, 12 May. Available at: https://www.scrum.org/resources/blog/agile-product-operating-model-state-play-part-1-fundamentals (Accessed: 8 June 2025).
118. Scrum.org (2024) ‘Project to Product and the Agile Product Operating Model’, Scrum.org, 7 November. Available at: https://www.scrum.org/resources/blog/project-product-and-agile-product-operating-model (Accessed: 8 June 2025).
119. Scrum.org (2024) Moving to an Agile Product Operating Model [PDF]. Available at: https://www.scrum.org/resources/moving-agile-product-operating-model-evidence-based-approach-delivering-products-digital-age or https://bit.ly/SDOAPOM . (Accessed: 8 June 2025)
120. Scotland, K. (2023) Why strategy deployment? Here are three great reasons, AvailAgility. At: https://availagility.co.uk/2023/02/16/why-strategy-deployment-here-are-three-great-reasons/ (Accessed: April 3, 2023).
121. Scotland, K. (2019) Deploying strategies as choices, AvailAgility. At: https://availagility.co.uk/2019/02/08/deploying-strategies-as-choices/ (Accessed: April 3, 2023).
122. Scotland, K. (2017) Strategy deployment and playing to win, AvailAgility. At: https://availagility.co.uk/2017/07/14/strategy-deployment-and-playing-to-win/ (Accessed: April 3, 2023).
123. Scotland, K. (2017) A strategy deployment cadence, AvailAgility. At: https://availagility.co.uk/2017/09/06/a-strategy-deployment-cadence/ (Accessed: April 3, 2023).
124. Scotland, K. (2022) The ultimate X-matrix for your agile transformation is here, AvailAgility. At: https://availagility.co.uk/2022/11/03/the-ultimate-x-matrix-for-youragile-transformation-is-here/ (Accessed: April 5, 2023).
125. Krebs, J. (2023) Agile kata pro, Agile Kata Pro. At: https://agilekata.pro/ (Accessed: April 4, 2023).
126. Doerr, J. (2023) OKRs 101, What Matters. At: https://www.whatmatters.com/get-started/ (Accessed: April 4, 2023).
127. Wodtke, C. (2021) Radical focus achieving your most important goals with objectives and key results–. Palo Alto, CA: Cucina Media.
128. Gothelf, J. & Seiden, J. (2024) Who Does What By How Much?: A Practical Guide to Customer-Centric OKRs. New York: Sense & Respond Press.
129. Appelo, J. (2023) Sometimes, you *don’t* want focus, unFIX. At: https://unfix.com/blog/sometimes-you-dont-want-focus (Accessed: 14 January 2024).
130. Appelo, J. (2023) Bets and objectives, unFIX. At: https://unfix.com/bets-and-objectives (Accessed: 14 January 2024).
131. McChesney, C. (2023) The 4 disciplines of execution (new), FranklinCovey. At: https://www.franklincovey.com/the-4-disciplines/ (Accessed: April 4, 2023).
132. Scrum.org (2024) Evidence-Based Management (EBM) Framework, Scrum.org. Available at: https://www.scrum.org/resources/evidence-based-management . (Accessed: 8 June 2025).
133. Burrows, M. (2023) Home: Agendashift™, Agendashift. At: https://www.agendashift.com/ (Accessed: April 4, 2023).
134. Kniberg, H. and Ivarsson, A. (2012) Scaling at Spotify, Crisp. At: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf (Accessed: April 5, 2023).
135. Ambler, S.W. and Lines, M. (2023) Disciplined Agile® Toolkit - Project Management Institute, PMI. At: https://www.pmi.org/disciplined-agile/ (Accessed: April 5, 2023).
136. Leffingwell, D. and Knaster, R. (2023) Safe 6.0 framework, Scaled Agile Framework. At: https://www.scaledagileframework.com/ (Accessed: April 5, 2023).
137. Sutherland, J. (2021) Scrum@Scale - the scaling framework created by dr. Jeff Sutherland, Scrum@Scale Framework. At: https://www.scrumatscale.com/ (Accessed: April 5, 2023).
138. Skelton, M. and Pais, M. (2023) Team topologies, Team Topologies. At: https://teamtopologies.com/ (Accessed: April 5, 2023).
139. Appelo, J. (2023) Versatile Organization Design, unFIX. At: https://unfix.com/ (Accessed: April 5, 2023).
140. Merel, P. (2023) Xscale Alliance, XSCALE Alliance. At: https://xscalealliance.org/#manifesto (Accessed: April 5, 2023).
141. Schwaber, K. et al. (2021) Online nexus guide, Scrum.org. At: https://www.scrum.org/resources/online-nexus-guide (Accessed: April 5, 2023).
142. Quartel, R. et al. (2024) FaST guide, Fluid Scaling Technology. At: https://www.fastagile.io/ (Accessed: December 6, 2023).
143. Ramos, C. and Pavlichenko, I. (2023) Creating agile organizations, Creating Agile Organizations. At: https://creatingagileorganizations.com/ (Accessed: April 15, 2023).
144. Larman, C. & Vodde, B. (2025) LeSS (Large-Scale Scrum) Framework. Available at: https://less.works/less/framework (Accessed: 8 June 2025)
145. Flight Levels GmbH (2025) Flight Levels Framework. Available at: https://www.flightlevels.io/what-is-flight-levels/ (Accessed: 8 June 2025).
146. Krivitsky, A. and Flemm, R. (2022) Org topologies, Org Topologies. At: https://www.orgtopologies.com/ (Accessed: April 4, 2023).
147. Singh, P. (2023) Scaling Simplified: A Practitioner’s Guide to Scaling Flow. Florida: Self-published. Available at: https://leanpub.com/scalingsimplified (Accessed: 8 June 2025)
148. Davies, Dan. (2025) The Unaccountability Machine: Why Big Systems Make Terrible Decisions-and How the World Lost Its Mind. London: Profile Books Ltd. (Paperback edition).
149. Stripe (2025) ‘Sir Jony Ive and Patrick Collison Fireside Chat | Stripe Sessions 2025’, YouTube video, 8 May. Available at: https://youtu.be/wLb9g_8r-mE?si=1rEJxU0sxixvblQ3&t=1390 (Accessed: 8 June 2025)