Prezentacja z gościnnego wystąpienia na spotkaniu Project Management Institute (PMI) w Krakowie. Prezentacje punktuje najczęstsze problemy występujące podczas wdrożeń metodyki Scrum w środowisku średniej i dużej organizacji, powodów tych problemów upatrując w przyzwyczajeniach, kulturze organizacyjnej i obawie przed zmianą.

1. Agile Software Development with
Sacrum. Ken Schwaber, Mike Beedle
Agile Project Management with Scum.
Ken Schwaber
The Enterprise and Scam. Ken Schwaber
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

2. Sacrum.
Ile jest Scruma w Scrumie?
Scum.
Tomasz Włodarek
Scam.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
1.00.00 Materiał udostępniany na licencji Creative Commons (by-nc-nd). bnd

3. Scrum jest obecny w Polsce. Firmy różnej skali, branż, pochodzeniu
kapitału. Offshoring, nearshoring, rodzime. Od kilku lat. Wszędzie.
Najbardziej popularna ze wszystkich zwinnych metod: 58% Scrum,
17% hybryda Scruma z programowaniem ekstremalnym (XP), pozostałe
łącznie 25% (w tym własne odmiany 5%).
State of Agile Survey. 5th annual State of Agile Software Development Survey.
VersionOne Inc., 2010
Skąd się wziął? Jest głównie promowany oddolnie przez zespoły
projektowe 70%, coraz częściej postrzegany jest jako wymóg branży 33%,
rzadziej wdrażany decyzją kierownictwa 26% czy jako wymóg klienta 15%.
To interesujący fakt. Warto o tym pamiętać.
Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki
UEK, 2009
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

4. agile
(Agile Software Development)
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

5. Zwinność (ang. agility) oznacza potencjał – w sferze
umiejętności i możliwości – do szybkiego i sprawnego
dostosowywania się do zachodzących zmian.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

6. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

7. podczas wdrażania Scruma…
ScreamMaster
…natychmiast pojawiają się wykręty – ScrumButs.
ScrumButs to „powody”, dla których nie można w
pełni wykorzystać Scruma, by rozwiązać problemy i
uzyskać spodziewanych korzyści.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

8. (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 przygotowywany przez
Scrum Mastera)
Scrumujemy, ale (Product Backlog jest zamrożony)(bo nasz PM wymaga
od nas deklaracji co do zakresu i czasu)(więc nie robimy testów, żeby
wyrobić się na koniec Sprintów)
Scrumujemy, ale (właściwie granice sprintów są umowne)(bo i tak ciągle
wchodzi coś nowego)(więc po prostu lecimy z robotą)
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

9. (Wykręt)(Powód)(Alternatywa)
Scrumujemy, ale (nie oddajemy Product Ownerowi pracy co sprint)(bo nie
mamy testerów w zespole, a zresztą i tak trzeba by się integrować z
innymi)(więc zespół QA robi dla nas testy na koniec projektu)
Scrumujemy, ale (nie robimy Sprint Review)(bo i tak nikt tego nie
rozumie)(więc pokazujemy coś Product Ownerowi średnio raz na pół
roku)
Scrumujemy, ale (retrospektywy to strata czasu)(bo i tak się nic nie
zmienia)(więc po prostu ich nie robimy)
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

10. Fasada. Scrum but. WAGILE*. Quasi–agile. Flaccid Scrum. Kanban?
*waterfall agile (sic!)
ScrumButs to przejaw
postaw kulturowych,
tradycyjnie stosowanych praktyk
i przyzwyczajeń.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

11. Pierwotny strach przed nieznanym
– Ale przecież działamy, jakoś to idzie. Oczywiście mamy problemy, ale kto ich
nie ma!? Po co to zmieniać?
§ Scrum wymaga zmiany kultury organizacyjnej. Wprowadza rytm i przyspiesza realizację
projektów. Organizacja „wyszczupla się” i staje się bardziej efektywna.
§ Otwartość i przejrzystość wymagane przez Scruma to nowy sposób robienia biznesu.
Ceniona jest aktywność, kreatywność i innowacyjność, punktuje się marnotrawstwo,
politykierstwo i arogancję. Decyzyjność przesuwana jest w dół hierarchii. Czasem
wymagana jest zmiana struktury organizacyjnej. Czasem wymagane jest nabycie nowych
kompetencji. Zdarza się, że ktoś odchodzi z tego powodu.
§ Taka zmiana wywołuje strach i opór (od pasywnego do aktywnego) i wymaga
odpowiedniego podejścia (otwartości i konsekwencji). Jest ceną, którą płaci się za
zwiększoną efektywność organizacji.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

12. Strach przed rozmyciem terminów
(zupełnie jakbyśmy teraz je kontrolowali)
– W Scrumie nie mogę wyznaczać kamieni milowych. Nie da się wyznaczyć i
monitorować ścieżki krytycznej. Nie wiem jaki jest status projektu. To nie
dopuszczalne!
§ Nieporozumienie. W Scrumie nie planuje się sekwencji czynności, nie tworzy się diagramu
Gantta (finish-or-perish!), nie wyznacza się ścieżki krytycznej. Plan zorientowany jest na produkt
(wykonane zakresy funkcjonalności, podnoszące wartość produktu), a nie czynności (zadania)
prowadzące do ich wytworzenia.
§ Kamienie milowe wynikają z ograniczeń czasowych (time–boxes) i obowiązują zarówno na
poziomie Sprintu i spotkań w jego trakcie, jak i na poziomie wydań.
§ Można je określić mianem nieprzekraczalnych są bowiem stałym elementem procesu. Pozwala
to lepiej kontrolować ryzyko, zwiększa dyscyplinę i motywację.
§ Dodatkowo na podstawie danych historycznych (empirycznych) można wyznaczyć kiedy zostanie
osiągnięty określony zakres funkcjonalny, jaki zakres prac zostanie wykonany w określonym
czasie etc.
§ Ocena kondycji projektu dokonywana jest na podstawie „twardego” dowodu – działającego (lub
nie) oprogramowania o określonej wartości, a nie mętnych miar.
§ Szybko widać, że są problemy. Scrum to narzędzie zarządzania ryzykiem.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

13. Strach przed pełzającym zakresem
– Jak możemy się zdeklarować do czegokolwiek bez spisania kontraktu na zakres / bez książki
wymagań / bez solidnej dokumentacji analitycznej / bez kompleksowego projektu architekury
systemu?
§ Pełzanie zakresu jest podstawowym problemem w klasycznych projektach, kontraktowanych na zakres i czas,
realizowanych kaskadowo.
§ Ocenia się, że mimo ogromnych nakładów na etap wstępnego planowania średnio 35% wymagań ulega
zmianie w trakcie prac, a około 60% dostarczonej funkcjonalności jest używane rzadko lub wcale. Sprawę
pogarsza dyskusyjna kwestia zgłaszanych w ramach gwarancji „usterek” („w dokumentacji po uzgodnieniach
nie było co prawda mowy, że ma być, ale nie było też mowy, że ma nie być”)
§ Scrum rozwiązuje tę kwestię poprzez ideę etapowego osiągania celów biznesowych, dynamicznego
planowania i zaprzęgnięcie zachodzących zmian do wytworzenia przełomowego produktu.
§ Scrum dopuszcza zmianę zakresu (wyjątkiem jest okres realizacji Sprintu), przy czym ograniczenie czasowe
na wydanie (zakontraktowana liczba Sprintów) lub Sprint (stała liczba dni) wymusza dokonywanie
racjonalnych wyborów odnośnie realizacji poszczególnych funkcjonalności. Dotyczy to zarówno ich liczby jak i
„bogactwa”.
§ Dobór zakresu pracy do kolejnego Sprintu (czy wydania) jest dokonywany przez zestawienie potrzeb
biznesowych Product Ownera z realnymi możliwościami produkcyjnymi Zespołu.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

14. Strach przed utratą kontroli nad budżetem
– Ile to będzie kosztować? – Ale co dokładnie mamy zrobić? – Nie wiem, to wy jesteście
specjalistami, powinniście to wiedzieć!
§ Klasyczne metody przyzwyczaiły nas do planowania budżetu na podstawie ustalonego zakresu prac.
Tyle, że zwykle nie bardzo wiadomo czego dokładnie oczekujemy, jakie niespodzianki czekają nas po
drodze i jak nasze wymagania będą się zmieniać w czasie.
§ Większość klasycznie realizowanych projektów IT przekracza budżet o 150% do 1000%, przechodząc
przez czasochłonny i stresujący dla obu stron proces zarządzania zmianą.
§ W Scrumie ryzyko pozornie jest większe ze względu na możliwość zmiany zakresu, ale:
§ koszty są namacalne i policzalne (każdy Sprint kosztuje w przybliżeniu tyle samo i daje efekt w
postaci gotowego oprogramowania)
§ co Sprint uzyskujemy informację zwrotną
§ na tej podstawie zarządzamy ryzykiem np. dostosowując zakres prac do realiów i rzeczywistych
potrzeb
§ Jest spora szansa, że osiągniemy oprogramowanie spełniające nasze potrzeby (faktyczne, nie
wydumane) zanim wydamy cały przeznaczony na projekt budżet.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

15. Strach przed spowolnieniem tempa prac
– Mamy 42 projekty w toku, do każdego z nich przypisane są zasoby. Nie możemy tych ludzi nagle
przekonfigurować w zespoły scrumowe i pozwolić im skupić się na pojedynczych funkcjonalnościach.
Cała organizacja zwolni.
§ Klasyczne projekty realizowane są przez wyznaczone do tego osoby i zarządzane przez kierowników projektów. Po
zakończeniu prac osoby te przypisywane są do nowych projektów, niekonieczne w tym samym składzie, niekoniecznie
w tym samym obszarze systemu. Ogranicza to ich poczucie odpowiedzialności za jakość wykonanej pracy. Cierpi na
tym także współpraca zespołowa. Te grupy pracownicze w istocie nie są zespołami i muszą być zarządzane.
§ Ponieważ projekty się spóźniają i zawierają błędy pojawiają się trudności w zarządzaniu zasobami, często te same
osoby jednocześnie uczestniczą w realizacji wielu projektów, co pozornie zwiększa ilość pracy wykonywanej. W
rzeczywistości zostaje wykonana mniejsza ilość pracy, a wykonanie każdej części pracy jest wielokrotnie droższe.
Zaczyna się polityka, pojawiają się naciski i rywalizacja o (kluczowe) zasoby. Praca wykonywana jest gorzej i mniej
kreatywnie. To kula śniegowa.
§ Podstawą wysokiej (hiper) produktywności zespołów scrumowych jest stabilność ich składu i samoorganizacja wokół
celów wyznaczanych przez jednego Product Ownera.
§ Zespół z czasem wypracowuje stabilne tempo pracy, właściwe dla składu danej grupy i środowiska projektowego. Nie
wszystkim to tempo będzie odpowiadać. Niektórzy żyją w świecie marzeń. Zamiast frustrować się, że rzeczywistość nie
spełnia naszych oczekiwań, lepiej jest poznać co mamy do dyspozycji i przemyśleć jak najlepiej to wykorzystać.
§ Zapewne mniej pracy będzie wykonywane jednocześnie, ale dzięki temu będzie ona kończona szybciej. Poprawiona
zostanie przewidywalność i jakość.
§ Scrum dopuszcza możliwość realizowania przez jeden zespół scrumowy wielu projektów jednocześnie (np. dla różnych
klientów) w obrębie jednego produktu (wspólnej bazy).
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

16. paralelioza
Niebezpieczna choroba
wywołująca błędne przekonanie,
że więcej pracy zostanie zrobione
jeśli więcej będzie wykonywane
jednocześnie.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

17. Strach przed utratą kontroli
(oddaniem odpowiedzialności)
– Oni mają decydować?! Przecież będą tak robić żeby się nie narobić! Na ludziach można
cokolwiek wymóc tylko z pozycji siły!
§ Klasyczny kierownik ponosi pełną odpowiedzialność (za projekt, za produkt, za zespół). Podejmuje decyzje i
wydaje dyspozycje – często pod presją czasu, w oparciu o nikłą znajomość tematu i opinie osób trzecich. W
razie kłopotów staje się kozłem ofiarnym i sprawa jest jasna. Czyżby?
§ Ponieważ (zwykle) mamy do czynienia ze złożonymi przedsięwzięciami, nikt nie jest w stanie podejmować
racjonalnych decyzji jednoosobowo.
§ Mimo to oddając decyzyjność w dół hierarchii obawiamy się rozmycia odpowiedzialności i nieracjonalnego
zachowania ludzi, którym powierzamy obowiązki. Brak zaufania?
§ Scrum w klarowny sposób rozdziela odpowiedzialność pomiędzy Product Ownera (biznes), Zespół (propozycje
rozwiązań technicznych) i Scrum Mastera (proces i wsparcie organizacyjne).
§ Kontrola jest częsta (co dzień, co Sprint, co wydanie), jest przeprowadzana na różnych poziomach przez
kwalifikowane do tego osoby i jest elementem procesu (jest nieuchronna). Wszystko to zwiększa
zaangażowanie i motywację do przejawiania odpowiedzialnych zachowań.
§ Decyzje podejmowane są periodycznie (co Sprint) na podstawie empirycznie stwierdzonych faktów (przyrost
lub jego brak) w sposób przejrzysty (jawny). Z faktami nie da się dyskutować. Przejrzystość usuwa politykę.
Nie wszystkim to odpowiada.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

18. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

19. samoorganizacja
Szybka reakcja na dynamikę otoczenia. Skrócenie
czasu podejmowania decyzji. Lepsze rozpoznanie
potrzeb, lepsze dopasowanie nakładów do potrzeb.
Wzrost motywacji. Odpowiedzialność.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

20. samoorganizacja?
Osłabienie zewnętrznej kontroli, ograniczenie
ingerencji kierownictwa. Większa swoboda działania w
zamian za obietnicę zwiększonego zaangażowania.
Autonomia. Czy może anarchia?
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

21. fundamentalna potrzeba pewności i gwarancji
brak czasu a zatem
i przyzwolenia na
popełnianie błędów
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

22. kontrola, kontrola, kontrola
Phone Driven Development (PDD)
Ograniczanie dostępu do informacji. Brak bezpośredniego
kontaktu z klientem lub osobami, które go reprezentują. Brak wglądu
w długofalowe plany. (wkrada się kaskadowość)
Ograniczanie decyzyjności. Długa i zawiła ścieżka decyzyjna.
(wkrada się kaskadowość)
Ograniczanie interdyscyplinarności. Osoby o różnych
kompetencjach zaangażowane w przedsięwzięcie pracują w izolacji od
siebie. Potrzebni pośrednicy i koordynatorzy. Planowanie zasobów.
(wkrada się kaskadowość)
Ograniczanie autonomii. Rozdzielanie zadań. Wymuszanie
zobowiązania. (wkrada się kaskadowość)
Ograniczenie zaufania. Zwiększone nakłady na zewnętrzną
kontrolę. Zmniejszone poczucie odpowiedzialności.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

23. § Odwołanie do procesu/planu. Zabijamy kreatywność. W najlepszym
przypadku otrzymujemy perfekcyjnie wykonaną przeciętność.
§ Przyzwyczajenie. Zawsze tak robiliśmy. Postępuję tak jak moi
przełożeni. Taką mamy kulturę pracy.
§ Pułapka odpowiedzialności. Jestem za to odpowiedzialny,
powierzono mi te obowiązki. Muszę się upewnić, że wszystko będzie
wykonane prawidłowo.
§ Po prostu powiem im kto/kiedy/jak ma to zrobić. Mikro-
zarządzanie (być może zarządzanie w ogólności) wydaje się być
łatwiejsze niż przywództwo. W istocie jest bardziej angażujące i daje
znacznie gorsze rezultaty długofalowe.
§ Powiem im też, że mają to zrobić bezbłędnie, bo jak nie…
Tak, to bez wątpienia pomaga. Podobnie jak komenda “pracuj szybciej”.
§ Arogancja i/lub ignorancja. Kiedy brakuje zaufania i wzajemnego
szacunku pozostają jedynie rozwiązania siłowe. Tymi przypadkami nie
chcę się nawet zajmować.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

24. będzie pan zadowolony
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

25. § Założeniem Scruma jest fakt, że przedmiotem
podlegającym częstej kontroli jest coś
zrozumiałego dla wszystkich zainteresowanych, coś
podlegającego wszechstronnej ocenie.
§ Nie abstrakt (dokument, formularz, projekt,
prezentacja, kolor raportu, procent
zaawansowania). Konkret. Dowód.
§ Zintegrowany, przetestowany, działający
software.
§ Na całe szczęście to potrafimy robić, prawda?
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

26. Prawie, właściwie, praktycznie,
teoretycznie, zasadniczo, jakby,
generalnie, ogólnie rzecz biorąc, z
grubsza… w 90% skończone.

27. Strach przed przejęciem kontroli
(podjęciem odpowiedzialności)
– Scrum jest kolejną sztuczką managementu, żeby nas jeszcze bardziej przycisnąć.
To teraz mamy jeszcze robić ich robotę?!
§ Nieporozumienie. W Scrumie odpowiedzialność jest przesuwana w dół hierarchii wraz z
decyzyjnością. To Zespół proponuje rozwiązania, Zespół z Product Ownerem ustala realny
poziom oczekiwań i Zespół deklaruje ile pracy może zostać wykonane w Sprincie.
§ Scrum bazuje na wysokiej motywacji do wykonania dobrej pracy. Motywacja wynika z
głębokiego poczucia sensu wykonywanej pracy i poczucia wpływu na bieg wydarzeń. Potrzebna
jest przejrzysta i bogata informacja kontekstowa.
§ Niewiele osób jest przyzwyczajonych do takiego stylu pracy. Niektóre osoby w ogóle się do tego
nie nadają. Niektórzy po prostu potrzebują kierownika. Takie osoby nie zagrzeją miejsca w
zespole scrumowym.
§ Jeśli produktywność Zespołu nie jest zgodna z oczekiwaną, Zespół poszukuje sposobów jej
zwiększenia. Proponuje rozwiązania i oczekuje wsparcia kierownictwa w tym zakresie.
§ Wypracowanie takiego podejścia wymaga czasu. Najmniejszy przejaw braku przejrzystości,
łamania ustaleń czy braku konsekwencji będzie powodować szybki i gwałtowny regres. To jedno
z najczęstszych miejsc załamania.
§ Niemniej – jeśli mimo tych wszystkich wysiłków – przedsięwzięcie nie spełnia podstawowych
założeń biznesowych, zamyka się je a Zespół jest rozwiązywany lub zmienia się jego skład. Nikt
nie powinien być zaskoczony takim obrotem spraw.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

28. Strach przed zaangażowaniem
(lub obnażeniem braku kompetencji)
– Mam teraz co dwa tygodnie pokazywać jak to działa komuś z biznesu, szkoda czasu, to
techniczne sprawy i tak nie skapują! –Przecież dewelopment nie operuje podstawowymi
pojęciami i nie zna założeń biznesowych! Nie mam czasu na takie pierdoły.
§ Końcowi odbiorcy i reprezentujący ich przedstawiciele biznesu (marketing, Product Management, etc.) nie są
przyzwyczajeni do współuczestniczenia w procesie produkcji oprogramowania. Rezultaty są opłakane
(przepaść komunikacyjna, produkty nie spełniające oczekiwań, przerzucanie się winą).
§ Ponieważ software jest zazwyczaj częścią większej całości, Scrum angażuje obie strony w proces wytwórczy.
Obie strony muszą pokonać opór przed wejściem na obszar leżący poza ich podstawowymi kompetencjami.
Dialog prowadzony z równorzędnych pozycji – obie strony są od siebie wzajemnie zależne – jest kluczem.
§ Jest to możliwe tylko przy założeniu, że proces planowania będzie przejrzysty (informacja kontekstowa – nie
tylko co, ale również po co), a swoboda realizacyjna będzie prowadzić do wytworzenia zrozumiałego dla
wszystkich i kompletnego (ukończonego) przyrostu. Przejrzystość usuwa politykę. Nie wszystkim to
odpowiada. Niektórzy zrobią wszystko by zapobiec przejrzystości.
§ Użycie Scruma często prowadzi do odkrycia, że niechęć do współpracy ma swoje źródło w fakcie, że
dewelopment ma poważne braki na poziomie inżynierii oprogramowania i/lub biznes niedomaga pod
względem wizji produktu, planowania strategicznego czy komunikacji.
§ Scrum szybko daje namacalne wyniki w postaci konkretnych obserwacji. To fakty na których można budować.
Jeśli będą one prowadzić do zmian, stopniowo zwiększy się zaangażowanie po obu stronach.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

29. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

30. “ Framework within which people
can address complex problems
and productively and creatively
develop products of the highest
possible value.
–Ken Schwaber
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).
”

31. “ Process which
can address complex problems
and
develop products for the lowest
possible cost.
–?!
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).
”

32. Scrum umożliwia tranzycję
Scrum: (1) narzędzie wykorzystywane do osiągnięcia zwinności (2) ramy
metodyczne (framework), w obrębie których ludzie mogą rozwiązywać złożone
problemy, tworząc w ten sposób, kreatywnie i produktywnie, produkty o
najwyższej możliwej wartości.
§ proste reguły i ograniczenia czasowe (time-boxed containers) pozwalają
zapanować nad chaosem
§ oparcie dla szeregu lekkich (lean) praktyk
Scrum jest modelem koncepcyjnym, narzędziem, które pomaga
ustalić co jest przeszkodą w produkowaniu oprogramowania o
wyższej jakości, lepiej, szybciej.
Redukuje zlożoność i pozwala lepiej kontrolować ryzyko.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

33. wybita szyba
Członkowie zespołu samoorganizującego się asymilują się z otoczeniem
poprzez obserwację, naśladownictwo i wzmocnienie. W ten sposób (powoli)
tworzy się kodeks zachowań, którym posługuje się grupa.
Daj przykład, a efekt przyjdzie sam. Cierpliwości. Niepożądane
zachowania (zwykle wygodniejsze) są zazwyczaj przejmowane szybciej niż
poprawne.
Brak jednoznacznej, stanowczej i konsekwentnej korekty niepożądanych
zjawisk (czy zachowań) zawsze prowadzi do ich eskalacji.
Jeśli komuś na czymś nie zależy jest spora szansa, że za chwilę
nikomu na niczym nie będzie zależało.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

34. Wszyscy docenią Scruma, bowiem opisuje on
ScreamMaster
dokładnie to, co robimy, gdy zostaniemy przyparci
do muru.
–Jim Coplien
(The Scrum Guide, Ken Schwaber, Jeff Sutherland)
Paradoksalnie, dopiero kiedy jest naprawdę
tragicznie zaczynamy postępować właściwie –
zbieramy zespół i odwołując się do
nadrzędnego celu, prosimy o pomoc i
zaangażowanie, deklarując pełne wsparcie i
dając wolną rękę.
Byle nie było za późno.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

35. to musi wejść w krew
Nie da się robić agile’a –
trzeba być agile. Poszczególne
elementy, techniki i sztuczki nie
wystarczą. Liczy się koncept
(przesłanie) i umiejętność
wykorzystania całego modelu w
praktyce.
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

36. Nawet kulawy Scrum pomaga. Krótszy czas
wprowadzenia produktu na rynek 63%*, lepsza zdolność
do absorbowania zmian 86%*, wzrost produktywności
86%*, wzrost jakości produktu 71%*, poprawa
komunikacji 93%*, wzrost morale 78%*, spadek ryzyka
niepowodzenia projektu 63%*, neutralny wpływ na
koszty realizacji projektu. 41%* wskazuje na pełny
sukces realizowanych projektów. Jakby to wyglądało
gdybyśmy wykorzystali go w pełni?
Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki
UEK, 2009
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).

37. Tomasz Włodarek
dziękuję!
Projekty szkoleniowo-doradcze realizowane m.in. dla:
ABG S.A., Anixe Polska, Apriso Polska, Asseco Business Solutions S.A., ATSI S.A., BLStream, CCA
Europe, CD Projekt RED, Copi S.A., GE Money Bank S.A., Getin Bank S.A., Hurra Communications,
Logintrans, Nokaut.pl, Quantum Software S.A., Grupa Allegro, RST, Sterkom, Spot.pl, Travelplanet.pl,
TRW Polska, TVN, Volantis Systems, VSoft S.A., Young Digital Planet S.A.
tomek@poddrzewem.pl
http://www.poddrzewem.pl
http://www.linkedin.com/in/wlodarek
On our loss of wisdom, Barry Schwartz, TED talk
http://www.ted.com/talks/barry_schwartz_on_our_loss_of_wisdom.html
The child–driven education, Sugata Mitra, TED talk
http://www.ted.com/talks/sugata_mitra_the_child_driven_education.html
Scrum Guide. K.Schwaber, J.Sutherland
Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki, UEK, 2009
Metodyka Scrum w Polsce w świetle badań. M.Ćwiklicki, T.Włodarek, kwartalnik Nauka i
gospodarka, 2010
State of Agile Survey. 5th annual State of Agile Software Development Survey, VersionOne Inc.,
2010
Agile Software Development with Scrum. K.Schwaber, M.Beedle
Agile Project Management with Scrum. K.Schwaber
The Enterprise and Scrum. K.Schwaber
© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.
Materiał udostępniany na licencji Creative Commons (by-nc-nd).