Skalowanie Scruma

1,531 views
1,338 views

Published on

Prezentacja ze spotkania poznańskiej grupy agile'owej. Dość wysoki poziom abstrakcji (idea) - cel: zainicjować dyskusję o konkretnych problemach i praktykach. Więcej informacji: http://www.poddrzewem.pl.

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,531
On SlideShare
0
From Embeds
0
Number of Embeds
35
Actions
Shares
0
Downloads
35
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Skalowanie Scruma

  1. 1. If a problem cannot be solved, enlarge it. –Dwight D. Eisenhower ” “
  2. 2. 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
  3. 3. scrum/skrʌm/ © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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 ” “
  4. 4. 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 © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  5. 5. 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. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). Sprint Retrospective (3h) Zespół Scrumowy dokonuje inspekcji i adaptacji procesu wytwórczego (narzędzi i technik) oraz relacji w zespole.
  6. 6. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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?
  7. 7. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). W zmaganiach między tobą a rzeczywistością, rzeczywistość zdaje się mieć przewagę. –Ja ” “
  8. 8. 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. –K. Schwaber, J. Sutherland Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust empiryzm(kontrola–adaptacja–przejrzystość) ”© 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). “
  9. 9. 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. Sutherland Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust ” “ © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). empiryzm(kontrola–adaptacja–przejrzystość)
  10. 10. 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ł udostępniany na licencji Creative Commons (by-nc-nd). “
  11. 11. 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 ” “ © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  12. 12. 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. –K. Imai, I. Nonaka, H. Takeuchi Managing the New Product Development Process: How Japanese Companies Learn and Unlearn ” “ © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). współodpowiedzialność
  13. 13. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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 ” “
  14. 14. 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) © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  15. 15. 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/ © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  16. 16. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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.
  17. 17. poscrumianie organizacji © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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
  18. 18. nie da się marchewkowo–pomarańczowy proszę... © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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. –K. Imai, I. Nonaka, H. Takeuchi Managing the New Product Development Process: How Japanese Companies Learn and Unlearn ” “
  19. 19. brak czasu pożar, wszędzie pożar… © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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. –K. Schwaber, J. Sutherland Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust ” “
  20. 20. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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
  21. 21. © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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
  22. 22. 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 © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  23. 23. © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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, significant 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
  24. 24. 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 © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  25. 25. organizacja, podobnie jak wytwarzany przez nią software to złożony problem © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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, And Leave Competitors In the Dust ” “
  26. 26. 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 © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). Sprint Retrospective Zespół tranzycyjny i zespoły domenowe poddają analizie efektywność swojego sposobu pracy.
  27. 27. © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  28. 28. © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  29. 29. 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 © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  30. 30. 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) © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  31. 31. © 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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
  32. 32. skalowanie ról i zespołów Don’t build teams, let teams emerge. –Tobias Mayer http://agileanarchy.tumblr.com/post/18364399411/dont-build-teams ” “ © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  33. 33. skalowanie narzędzi © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  34. 34. skalowanie wydarzeń © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  35. 35. nie czekaj, po prostu zacznij* http://scrum.jeffsutherland.com/2012/07/dont-wait-just-begin.html © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). You cannot identify all impediments up front as they are embedded in the organization and therefore too familiar to be identified easily. –K. Schwaber, J. Sutherland Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust ” “
  36. 36. wyzwanie Scrum Mastera Szukając zbiorowej inteligencji, możesz natknąć się na zbiorową ignorancję. –Ja ” “ © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  37. 37. …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… © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  38. 38. (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) © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  39. 39. (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) © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  40. 40. 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. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  41. 41. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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 ” “
  42. 42. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). KEEP OUT. SPRINT IN PROGRESS
  43. 43. test na prawdziwość założeń © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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. –K. Schwaber, J. Sutherland Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust ” “
  44. 44. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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. –K. Schwaber, J. Sutherland Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust ” “
  45. 45. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). 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, And Leave Competitors In the Dust ” “ test na inteligencję i siłę charakteru
  46. 46. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). poscrumianie organizacji 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 ” “
  47. 47. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). poscrumianie organizacji 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 ” “
  48. 48. © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). poscrumianie organizacji 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 ” “
  49. 49. 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) © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  50. 50. Pytania? © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

×