Skalowanie Scruma

If a problem cannot be solved, enlarge it.
–Dwight D. Eisenhower
”
“

Scrum w dużej skali
enterprise agility
© 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał
udostępniany na licencji Creative Commons (by-nc-nd).
1.02.12 bnd
Tomek Włodarek

scrum/skrʌm/
Scrum is just a simple framework that will
identify everything in an organization that gets
in the way of optimally building software.
–K. Schwaber, J. Sutherland
Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers,
And Leave Competitors In the Dust
”
“

scrum/skrʌm/
”
“Scrum will only help you to fail in 30 days or less.
It’s a framework within which people can address
complex problems.
–K. Schwaber

1–4tygodnie
Scrumw wytwarzaniu oprogramowania
Scrum Guide, Ken Schwaber, Jeff Sutherland
(http://www.scrum.org/Scrum-Guides)
Role (Scrum Team)
Product Owner
Zespół Deweloperski
Scrum Master
Artefakty
Przyrost
Product Backlog
Sprint Backlog
Wydarzenia
Sprint
Sprint Planning (1) i (2)
Codzienny Scrum (Daily Scrum)
Sprint Review
Retrospektywa (Retrospective)
Przygotowanie (opcjonalne)
(1) Product Owner uczestniczy w przygotowaniu wizji
produktu, roadmappingu, wstępnym budżetowaniu
(2) Product Owner przygotowuje założenia wydania i
tworzy zręby Product Backlogu.
Sprint Planning (4h + 4h)
(1) Product Backlog jest omawiany zgodnie z porzadkiem
nadanym przez Product Ownera
(2) Zespół Deweloperski przygotowuje Sprint Backlog,
czyli określa zakres i plan prac na bieżący Sprint.
Przebieg Sprintu
Zespół Deweloperski realizuje Przyrost, zgodnie z
ustalonymi standardami (DoD), poddając plan prac
codziennej kontroli i adaptacji (Daily Scrum).
Sprint Review (4h)
Produkt poddawany jest wspólnej (angażującej Zespół
Scrumowy i interesariuszy) inspekcji. Na jej podstawie
dokonuje się adaptacji Product Backloga a Product Owner
omawia plan kolejne Sprinty (projekcja).
Scrum Master stoi na straży przejrzystości, przestrzegania
reguł i efektywności wykorzystania Scruma.
Sprint Retrospective (3h)
Zespół Scrumowy dokonuje inspekcji i adaptacji procesu
wytwórczego (narzędzi i technik) oraz relacji w zespole.

Czy w skład Zespołu Scrumowego
wchodzą:
... Product Owner odpowiedzialny za Product
Backlog? (jedna osoba)
... Scrum Master odpowiedzialny za poprawne
rozumienie i wykorzystanie Scruma?
... interdyscyplinarny, samoorganizujący się Zespół
Deweloperski?
Czy istnieją:
... przejrzysty i uporządkowany Product Backlog?
... Sprint Backlog pokazujący w każdym dniu Sprintu
ile pracy pozostało do wykonania?
... Sprinty o ustalonym i nieprzekraczalnym czasie
trwania, maksymalnie 1 miesiąc? (otwierane
planowaniem i zamykane retrospektywą)
... użyteczne, gotowe do potencjalnego wdrożenia
oprogramowanie po każdym Sprincie (Przyrost)?
Czy Zespół Scrumowy:
… podczas Planowania Sprintu tworzy Sprint
Backlog zawierający przewidywany zakres prac wraz
planem na ich wykonanie?
Czy Zespół Deweloperski:
... podczas Codziennego Scruma analizuje postęp i
plan prac i wprowadza niezbędne korekty do Sprint
Backlogu?
Czy w każdym Sprincie:
... odbywa się Przegląd Sprintu podczas którego
interesariusze dokonują inspekcji Przyrostu?
... odbywa się Retrospektywa Sprintu angażująca
cały Zespół Scrumowy?

W zmaganiach między tobą a rzeczywistością,
rzeczywistość zdaje się mieć przewagę.
–Ja
”
“

There is a tendency in enterprises to overplan
and to overthink. This is not the Scrum way.
Scrum requires action, evaluation, learning,
elimination of impediments, and more action
in order to create things of value.
empiryzm(kontrola–adaptacja–przejrzystość)
”© 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał
“

Scrum exposes every cultural dysfunction that
impedes developing software […]
It is not an approach or process that can be
modified to fit the existing organizational culture;
the culture must change to enable Scrum.
”
“
empiryzm(kontrola–adaptacja–przejrzystość)

przejrzystość
The great thing about fact–based decisions is
that they can overrule the hierarchy.
–Jeff Bezos
Amazon.com
”© 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał
“

samoorganizacja
[...] study by Nonaka has shown that Japanese
companies with a self–organizing characteristic
tend to have higher performance records [...]
–K. Imai, I. Nonaka, H. Takeuchi
Managing the New Product Development Process: How Japanese Companies Learn and Unlearn
”
“

In a relay someone says: my job is done, now
you take it from here. But that’s not right.
Everyone has to run the entire distance. Like in
rugby, every member of the team runs together
[…] and dashes toward the goal.
”
“
współodpowiedzialność

Scrum is a disruptive technology, that
if you implement it well, your competition
can’t compete. You will put your
competitors out of business.
–Jeff Sutherland
”
“

Dlaczego warto rozważać zwinne podejście
Stan bieżący
•  Opóźnienia w realizacji projektów, długie cykle produkcyjne,
późna kapitalizacja. Innowacja staje się imitacją
•  Planowanie i utrzymanie planu wydaje się zabierać zbyt dużo
czasu
•  Odstępstwo od planu jest kosztowne, wprowadzanie zmian w
trakcie realizacji projektu jest trudne
•  Jakość tworzonego oprogramowania się pogarsza, faza
stabilizacji przed wydaniem się wydłuża
•  Produkty stają się coraz droższe w utrzymaniu i rozwijaniu
•  Energia tracona jest na walkę wewnątrz firmy (pomiędzy
działami, pionami, sektorami) a nie z rynkiem
•  Niezadowoleni, zrażeni współpracą klienci/odbiorcy
•  Marsze śmierci* obniżają morale, rośnie frustracja, występuje
przerzucanie się odpowiedzialnością i szukanie kozłów
ofiarnych
*Edward Yourdon, Marsz ku klęsce, WNT 2007
Agile
•  Umiejętność dokonywania szybkiej zmiany, łatwość jej
realizowania
•  Zwiększona produktywność i jakość
•  Wczesna eliminacja ryzyka
•  Wczesne uzyskiwanie wartości
•  Zwiększona świadomość odnośnie aktualnego stanu prac
(umiejscowienie w cyklu produkcyjnym)
•  Ograniczone marnotrawstwo
•  Odchudzone (lean) produkty, szybciej i precyzyjniej
zdobywające rynek
•  Poprawa relacji z klientami/odbiorcami
•  Zaangażowani i zmotywowani pracownicy
•  Obniżone całkowite koszty realizacji (produkcji, wdrożenia
i utrzymania oprogramowania)

jaka jest twoja motywacja?
•  przeterminowane pomysły i zawiedzione oczekiwania
•  zagrożenie pozycji rynkowej
•  biurokratyczny kolaps*
•  wysokie koszty utrzymania i rozwoju oprogramowania
•  wysokie koszty towarzyszące (koordynacja, komunikacja)
•  niskie morale, zmęczenie i wypalenie pracowników
•  pseudo–agile/scrum–fall (zawiedzione nadzieje)**
*http://blog.zacharyvoase.com/2009/06/20/bureaucratic-breakdown/
**http://www.halfarsedagilemanifesto.org/

poscrumianie organizacji
Scrum stymuluje zmianę w
sposobie pracy w zespołach,
pracy z klientem, praktykach
inżynierskich, procesach
wytwórczych, technologii,
metodach zar ządzania
produktem, projektem, portfolio
projektów. Słowem – wszędzie.
Wyzwanie rzucane jest
o b e c n e j k u l t u r z e
organizacyjnej i zasadom
ładu korporacyjnego.

modele wdrażania
§  działania oddolne, partyzanckie (ograniczony zasięg i korzyści, zwykle
okupione dużym wysiłkiem i stresem)
§  doraźne zastosowanie w odpowiedzi na palącą potrzebę
(zasięg i korzyści ograniczone do konkretnego projektu/obszaru)
§  pilotażowe wdrożenie (wydzielona część organizacji)
§  pełne wdrożenie, pełne wsparcie
kontekst jest ważny
§  od chaosu do Scruma
§  od waterfalla do Scruma
§  od water-Scrum-falla do Scruma

nie da się
marchewkowo–pomarańczowy proszę...
It is quite difficult for a highly structured and
seniority–based organization to mobilize itself
for change, especially under noncrisis
conditions. The effort collapses somewhere in
the hierarchy.
”
“

brak czasu
pożar, wszędzie pożar…
Many workplaces are unsafe. Political agendas
and hidden purposes pervert transparency.
Furthermore, many managers
are skilled in managing the status quo but not
in managing change.
”
“

powód wyjaśnienie potencjalny rezultat
chwilowa moda wszyscy wokół to robią, trzeba się
dostosować
mało z tego zwinności, dużo zamieszania
krytyczna
sytuacja/problem
kluczowy projekt ma kłopoty,
trzeba znaleźć sposób na jego
uzdrowienie
sytuacja/problem rozwiązany (nie bez trudności), korzyści
doraźne, ulotne
dogłębna ocena
sytuacji firmy
stan aktualny (status–quo) nie jest
akceptowalny, zwinność wydaje się
niezbędna do utrzymania pozycji
firmy
znaczące, długotrwałe korzyści, poprawa zdolności
konkurencyjnej; wiele wariantów wdrożeniowych, każdy o
swojej specyfice

© 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał
Scrum Scrum+ Scrum++ Scrum+++ Scrum++++ Scrum+++++
4–6 m-cy 8–12 m-cy 12–18 m-cy 18–24 m-cy …–30 m-cy …–36 m-cy
Process
(Scrum OOTB*)
Productivity Quality Enterprise Value Stała przewaga
konkurencyjna
Wprowadzenie i
stosowanie
podstawowych
reguł: role, artefakty,
wydarzenia
Scrum oraz:
ujednolicenie i
konsekwencja
stosowania reguł,
zespoły
międzyfunkcjonalne,
samoorganizacja,
zastosowanie definicji
ukończenia,
przejrzyste
raportowanie
postępów, kolejno
wprowadzane zmiany
w sferze narzędziowej
i procesowej
produkcji
oprogramowania
Scrum+1 oraz:
dług techniczny
zidentyfikowany
i powstrzymany,
zdefiniowanie i
stosowanie dobrych
praktyk inżynierskich
(clean code,
emergent
architecture), spójne
podejście do testów,
ukończone = gotowe
do wydania,
kolokowane
prawdziwie
międzyfunkcjonalne
zespoły, retrospektywy
napędzające zmianę,
skupienie i uważność
(np. praca w
sprintach nie jest
przerywana)
Scrum+2 oraz:
zgodność ze strategią
organizacji, coraz
pełniejsza
komunikacja i
przejrzystość, decyzje
podejmowane w
odpowiedzi na fakty,
samoorganizacja
rozciągająca się
ponad i poza zespoły
(społeczności),
oddolnie inicjowane
zmiany składów
zespołów w
odpowiedzi na
konkretną potrzebę,
wytyczone nowe
ścieżki rozwoju
kariery, sprzedaż
angażowana w
proces rozwoju
produktu
Scrum+3 oraz:
zarządzanie
sterowane wartością,
zastosowanie
wskaźników
opisujących wartość,
świadomość
całkowitych kosztów
posiadania (TCO),
wydania punktowe
(funkcjonalne) bez
konieczności
przeprowadzania
stabilizacji, bliska
współpraca i zaufanie
między Product
Ownerem, zespołem
deweloperskim a
interesariuszami,
usunięte przeszkody
zewnętrzne
Scrum+4 oraz:
przedefiniowana rola
lub brak
managementu, nowe
wartości stają u
podstaw działania
firmy, pełna
samoorganizacja i
partycypacja (np.
wolny rynek/giełda
pracowników,
zespołów i projektów),
premie zależne od
rzeczywistej
wydajności zespołów,
zmiany w strukturach
organizacji i
departamentów także
dotychczas
niezaangażowanych
*out–of–the–box

8 kroków
procesu
wprowadzania
zmiany
1.  Wzbudzenie poczucia pilności – co nam grozi jeśli nic się nie
zmieni?
2.  Ustanowienie i utrzymanie koalicji liderów
przewodzących procesowi zmian – grupa osób z
odpowiednią pozycją, doświadczeniem, autorytetem, zaufaniem i
umiejętnościami przywódczymi
3.  Stworzenie wizji stanu docelowego i strategii – jeśli
zmianę uda się wprowadzić, jak będzie to wyglądać?
4.  Komunikacja – wykorzystanie wszelkich możliwych środków i
kanałów informacyjnych w celu rozpropagowania wizji
5.  Angażowanie i usuwanie barier – uprawnienie i zachęcanie
pracowników do podejmowania ryzyka związanego ze stosowaniem
nowego podejścia, zbieranie informacji zwrotnej, eliminowanie
napotkanych przeszkód
6.  Krótkookresowe sukcesy – natychmiastowe, widoczne
sukcesy wynikające z nowego sposobu działania są celebrowane
7.  Konsolidacja uzyskanych korzyści i zwiększenie
zakresu zmiany – promowanie liderów i zwolenników zmian
8.  Zakotwiczanie nowego podejścia w kulturze
organizacyjnej – zmiana zaniknie jeśli nie będzie
podtrzymywana
Jak przeprowadzić transformację firmy,
John P. Kotter, Onepress 2007
Gdy góra lodowa topnieje. Wprowadzanie
zmian w każdych okolicznościach, John P.
Kotter, Onepress, 2008
§  Nie opuszczaj żadnego kroku
§  Nie zatrzymuj się w pół kroku, nie
ignoruj potrzeby solidnego
zakotwiczenia zmiany
§  Wykorzystuj osiągnięte już rezultaty do
wzmocnienia kierunku zmian
§  Zakotwiczenie zmiany w kulturze
zabiera lata

8 kroków staje
się procesami
XLR8. Accelerate: Building strategic
agility for faster-moving world, John P.
Kotter, HBR Press 2014
CREATE A SENSE
OF URGENCY
AROUND A
SINGLE BIG
OPPORTUNITY.
Build and maintain a
guiding coalition.
Celebrate visible,
signiﬁcant short-
term wins.
GC may be uncom
learns how to ope
love being part of
3. Formulate
changeinitiativ
big opportunity
gic true north for
formulated vision
a big make-or-bre
tunity exists, bec
competitive stabi
quite yet. But ke
won’t last.) The r
communicate. It
as strategically sm
of success and en
make consequen
having to seek pe
In creating on
guiding coalition
ment, a consultan
outtheorganizati
what the sales gr
ket losses, could
toward a big op
goals but framed
using words such
mired.” As a resu
with partners, do
Formulate a strategic
vision and develop
change initiatives
designed to capitalize
on the big opportunity.
Communicate the
vision and the strategy
to create buy-in and
attract a growing
“volunteer army.”“volunteer army.”
Accelerate
movement toward
the vision and the
opportunity by
ensuring that the
network removes
barriers.
Never let up.
Keep learning
from experience.
Don’t declare victory
too soon.
Institutionalize
strategic changes
in the culture.
The Eight Accelerators
The processes that enable the strategy network to function
52 Harvard Business Review November 2012

8 błędów
popełnianych
podczas
wprowadzania
zmiany
1.  Niedostateczne uświadomienie
pracownikom konieczności dokonania
zmian
2.  Stworzenie niedostatecznie silnej koalicji
liderów
3.  Brak wizji
4.  Nieadekwatna komunikacja wizji
5.  Nieusunięcie przeszkód utrudniających
realizację wizji
6.  Brak systematycznego planowania i
kreowania krótkookresowych sukcesów
7.  Zbyt wczesne świętowanie zwycięstwa
8.  Brak zakotwiczenia zamian w kulturze
organizacyjnej
Jak przeprowadzić transformację firmy,
John P. Kotter, Onepress 2007
Przewodzenie procesowi zmian: przyczyny
niepowodzeń, John P. Kotter, HBRP nr 17,
lipiec 2004
XLR8. Accelerate: Building strategic
agility for faster-moving world, John P.
Kotter, HBR Press 2014

organizacja, podobnie jak wytwarzany
przez nią software to złożony problem
The degree of success you have with empirical
software development largely depends on the
leadership in your organization and how they
lead everyone in the […] changes.
–K. Schwaber, J. SutherlandSoftware in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers,
”
“

4tygodnie
Agility Guide, Ken Schwaber, Scrum.org
(http://ebmgt.org/Agility-Guide)
Role
Zespół tranzycyjny (Enterprise Agility Team)
Zespoły domenowe (Domain Agility Teams)
Zespoły robocze (Development Scrum Teams)
Artefakty
Agility Product Backlog – zawiera propozycję
zmian, zasilany przez przeszkody odkrywane
przez zespoły domenowe i robocze –
nieefektywności, konflikty, dysfunkcje a także
inspirowany przez osiągane stopniowo możliwości
Zdarzenia
Zespół tranzycyjny oraz zespoły domenowe
wykorzystują Scruma (Daily Scrum → Weekly
Scrum)
Inicjacja procesu zmian
Enterprise Product Owner przygotowuje wizję i strategię
wprowadzania zmian.
Formowany jest zespół 3-6 osób umocowanych
odpowiednio do przeprowadzenia transformacji organizacji.
Pod przewodnictwem Enterprise Product Ownera
konstruowane są wstępne założenia backlogu
tranzycyjnego.
Sprint Planning
Z Agility Product Backlogu dobierany jest realistyczny
zakres aktywności na najbliższy okres; uruchamiane są
Sprinty zespołów domenowych (wdrażających zmianę).
Sprint Review
Uzyskane w zespołach domenowych i zespole
tranzycyjnym rezultaty poddawane są inspekcji,
Agility Product Backlog jest przeglądany, uzupełniany, a
Enterprise Product Owner ustala kolejność
Scrum Masterzy stoją na straży przejrzystości,
przestrzegania reguł i efektywności wykorzystania Scruma.
Realizacja Sprintu
Zespoły domenowe implementują zmiany w organizacji
Przedstawiciele zespołów domenowych biorą udział w
cotygodniowych Scrumach zespołu tranzycyjnego.
Backlog tranzycyjny jest ciągle uzupełniany o nowe wpisy.
Scrumowanie
Scruma,
poscrumianie
organizacji
Sprint Retrospective
Zespół tranzycyjny i zespoły domenowe poddają analizie
efektywność swojego sposobu pracy.

decydując się na zmianę należy być
przygotowanym na:
§  Pierwszych 3–9 miesięcy będzie szczególnie trudne dla wszystkich, całość zajmie od 2 do 6 lat
§  Fluktuację kadr (chęć zmiany zespołu, odejścia z firmy spowodowane trudnościami w odnalezieniu
się w nowym modelu lub brakiem akceptacji zachodzących zmian)
§  Cała organizacja zostanie poddana stresowi i wytrącona ze stanu równowagi – pojawią się animozje,
kolizja światopoglądów, tarcia i konflikty prowadzące do zmiany
§  Dewelopment stanie się odpowiedzialny za utrzymanie jakości, co może spowodować ograniczenie
tempa i zakresu prac; prawdopodobna jest reewaluacja prowadzonych projektów
§  Zmieni się praca menedżerów – środek ciężkości przesunie się z wyznaczania i rozliczania na
przywództwo i wspieranie – będzie inaczej i trudniej
§  Polityka oceny i wynagradzania pracowników może ulec zmianie
§  Przejrzystość redukuje możliwości realizowania osobistych, egoistycznych celów – niektórym może się
to nie podobać
§  Zidentyfikowane zostaną słabe i wstydliwe strony organizacji – braki kompetencji, zbędna biurokracja,
nieefektywności struktury organizacyjnej
§  W sytuacjach kryzysowych wracać będą stare zachowania
§  Scrum jest piekielnie trudny, reguły będą naciągane/łamane, zacznie się poszukiwanie
„lepszych” (czyt. mniej wymagających) metod

backlog tranzycyjny – przykładowe elementy
§  Określić potrzeby i oczekiwania, obszary, zdefiniować zestaw miar i sposób pomiaru procesu zmiany
§  Przygotować i przeprowadzić program komunikacji zmian w organizacji
§  Zaprojektować i dostarczyć programy szkoleniowe
§  Zaprojektować sposób zbierania informacji zwrotnej, zadawania pytań i rozwiązywania kwestii związanych z
wdrożeniem Scruma i wpływem tej zmiany na pracowników
§  Zidentyfikować potencjalnych Scrum Masterów, Product Ownerów i stworzyć mechanizmy wsparcia
pracowników w nowych rolach (dodatkowe szkolenia, coaching, mentoring)
§  Ustalić warunki wstępne (wymagane) do wdrożenia Scruma w grupie, zespole, projekcie (np. ujednolicone
Definition of Done, harmonogram Sprintów, liczebność i skład zespołów)
§  Zdefiniować oczekiwania odnośnie sposobów raportowania kondycji zespołów i projektów realizowanych przy
użyciu Scruma
§  Przeprowadzić ewaluację narzędzi do zarządzania backlogami
§  Identyfikacja pierwszych grup, zespołów, projektów w których zastosowany zostanie Scrum
§  Zaprojektować zestaw miar, sposobów ich gromadzenia oraz wykorzystywania – odnośnie poszczególnych
projektów realizowanych Scrumem
§  Przeprowadzić ewaluację portfolio projektów/produktów, utworzyć organizacyjny backlog inicjatyw,
zaprojektować sposób jego utrzymywania
§  Przeprowadzić rewizję struktury organizacyjnej i schematu wynagradzania pracowników w celu promowania
pracy zespołowej, wspierania samoorganizacji i podejmowania odpowiedzialności
§  Przeprowadzić analizę procesu produkcji i wydawania oprogramowania (development pipeline)

skalowanie ról i zespołów
Don’t build teams, let teams emerge.
–Tobias Mayer
http://agileanarchy.tumblr.com/post/18364399411/dont-build-teams
”
“

skalowanie narzędzi

skalowanie wydarzeń

nie czekaj, po prostu zacznij*
http://scrum.jeffsutherland.com/2012/07/dont-wait-just-begin.html
You cannot identify all impediments up front as
they are embedded in the organization and
therefore too familiar to be identified easily.
”
“

wyzwanie Scrum Mastera
Szukając zbiorowej inteligencji, możesz
natknąć się na zbiorową ignorancję.
–Ja
”
“

…natychmiast pojawiają się wykręty – ScrumButs.
ScrumButs to „powody”, dla których nie można w
pełni wykorzystać Scruma, by rozwiązywać problemy,
usprawniać działanie organizacji i realizować
spodziewanych korzyści.
ScreamMaster
podczas wdrażania Scruma…

(Wykręt)(Powód)(Alternatywa)
Scrumujemy, ale (nasz Product Owner nie ma czasu)(bo jest bardzo zajęty
swoimi sprawami)(więc Product Backlog jest zarządzany przez sekretarkę/
Project Managera/Scrum Mastera/nie ma backlogu)
Scrumujemy, ale (Product Backlog jest zamrożony)(bo nasz Project
Manager wymaga od nas deklaracji co do zakresu i czasu)(więc jak zwykle
ścinamy zakręty i nie robimy testów, żeby wyrobić się na koniec Sprintu/
wydania/projektu)
Scrumujemy, ale (granice sprintów są umowne)(bo i tak ciągle wchodzi coś
pilniejszego)(więc po prostu lecimy z robotą; i nazywamy to kanbanem)

(Wykręt)(Powód)(Alternatywa)
Scrumujemy, ale (nie oddajemy gotowego software’u co Sprint)(bo nie mamy
testera w zespole, a zresztą i tak żeby testować trzeba by się integrować z
innymi zespołami)(więc tester – jak zdąży – robi testy wszystkiego na
koniec projektu)
Scrumujemy, ale (nie robimy Sprint Review)(bo i tak nikt nie rozumie jak
dłubiemy coś w backendzie/frameworku/protokołach)(więc pokazujemy
użyteczny software raz na pół roku)
Scrumujemy, ale (retrospektywy to strata czasu)(bo i tak się
nic nie zmienia)(więc po prostu ich nie robimy)

Scrum, ale... Water–scrum–fall. WAGILE*. Pseudo–Scrum. Prawie–Scrum.
“Elementy Scruma”. Quasi–agile. Flaccid Scrum. Kanban?
*waterfall agile (sic!)
ScrumButs to przejawy
wypracowanych przez lata
postaw, tradycyjnie stosowanych
praktyk i przyzwyczajeń. U nas
wygląda to tak… Kultura
organizacyjna.

dość pieszczot. terapia szokowa*
http://scrum.jeffsutherland.com/2012/01/scrum-shock-therapy-how-to-change-teams.html
When I join a team as their Scrum Master, I
issue a few non–negotiable rules. Gently if
possible, firmly if necessary.
–Scott Downey
http://rapidscrum.com/Agile2009-ShockTherapy.pdf
”
“

KEEP OUT. SPRINT
IN PROGRESS

test na prawdziwość założeń
One of Scrum's best features is the information
it provides. Even in the worst case, where the
team doesn't deliver anything, they have
delivered valuable information about what is and
isn't possible. Management can use this
information to maximize value and control risk.
”
“

sztuka dostrzegania możliwości
Transparency is neither good or bad. Things
and increments just are. They may not be what
you want, but that means hard decisions are
required. You have to have a firm grasp of the
real facts to make solid decision.
”
“

Scrum exposes every cultural dysfunction that
impedes developing software […]
It is not an approach or process that can be
modified to fit the existing organizational culture;
the culture must change to enable Scrum.
–K. Schwaber, J. SutherlandSoftware in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers,
”
“
test na inteligencję i siłę charakteru

Scrum pomaga nam ciągle podnosić
poprzeczkę. Przedtem nie wiedzieliśmy, że w
ogóle jest jakaś poprzeczka, nie wspominając
nawet o jej podnoszeniu.
–Prezes zarządu
”
“

Cenię Scruma za porządek i rytm jaki
wprowadza w organizacji. Zamiast drętwych
raportów, polityki i pustych obietnic, mam
pewność, że co dwa tygodnie każdy zespół
przygotuje nowe wydanie.
–Prezes zarządu
”
“

Używając poprzednich procesów kuśtykaliśmy.
Po wprowadzeniu niektórych elementów Scruma
zaczęliśmy kuśtykać nieco szybciej.
A teraz musimy zacząć biegać.
–Dyrektor dewelopmentu
”
“

dziękuję!
Tomek Włodarek
tomek@poddrzewem.pl
@poddrzewem
http://www.linkedin.com/in/wlodarek
http://www.poddrzewem.pl
http://www.scrum.org
Scrum Guide. Ken Schwaber, Jeff Sutherland, 2011
The New New Product Development Game. Hirotaka Takeuchi, Ikujiro Nonaka, Harvard
Business Review, Jan-Feb 1986
Software In 30 Days. Software in 30 Days: How Agile Managers Beat the Odds,
Delight Their Customers, And Leave Competitors In the Dust. Ken Schwaber, Jeff
Sutherland, Wiley 2012
Succeeding with Agile: Software Development Using Scrum. Mike Cohn, Addison–Wesley
2009
Allegro's Journey Into Agility. Jakub Szczepanik, Jacek Wieczorek (http://vimeo.com/album/
1977617/video/44331906)

Pytania?

Skalowanie Scruma

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Viewers also liked

Viewers also liked (20)

Similar to Skalowanie Scruma

Similar to Skalowanie Scruma (20)

Skalowanie Scruma