Wchodząc w paszczę lwu... /Ile jest Scruma w Scrumie odsłona druga. Seminarium PMI Kraków

W zeszłym tygodniu, na zaproszenie krakowskiego oddziału PMI, wygłosiłem około dwugodzinny wykład o praktycznych aspektach wdrażania Scruma. Licząc na obecność osób silnie zmotywowanych do osiągania wysokiej skuteczności w realizacji projektów, a jednocześnie osób od których w dużej mierze zależy sposób w jaki te projekty są realizowane postanowiłem (po raz kolejny, ale w odświeżonej formie) zarysować problem fasadowości Scruma w warunkach dużej organizacji. Omówiłem potencjalne przyczyny tego stanu rzeczy, zostawiając sporo przestrzeni na pytania i przemyślenia własne słuchaczy.

Co było?

  • Pełna sala (no dobra, były jeszcze wolne miejsca na schodach...), większość osób z praktycznym doświadczeniem w wykorzystaniu Scruma (!)
  • Sporo znajomych twarzy (!)
  • Brawa (!) - jak usłyszałem od kilku uczestników było ciekawie i inspirująco (podobno nawet pojawił się w sali duch agile'a ;)
Zwinność (ang. agility) to (1) potencjał – w sferze umiejętności i możliwości – do sprawnego dostosowywania się do zachodzących zmian; (2) zdolność do wykorzystywania nadarzających się okazji połączona ze świadomym zarządzaniem ryzykiem; (3) odwaga do przyznania, że produkcja software'u to złożone przedsięwzięcie, które ze względu na zmiany zachodzące w wymaganiach i oczekiwaniach nie może zostać perfekcyjnie zaplanowane.

Mówiem o tym, że:

  • Scrum jest narzędziem prowadzącym do zwinności - osiągnięcie tego stanu wymaga dyscypliny, wytrwałości i myślenia,
  • Scrum bardzo różni się od obecnie stosowanych metod, jego wdrażanie nieodmiennie przeprowadza organizację przez szereg stresujących zmian,
  • Każda zmiana rodzi niepokój (w prezentacji używam silniejszego terminu - "strach") i wywołuje opór (od pasywnego do aktywnego) prowadzący do zatrzymania procesu przemian, czasem do regresu. Niepokój ten dotyczyć może wielu sfer, w prezentacji wymieniam "7 strachów" dotyczących różnych obszarów realizacji projektu i działania organizacji,
  • Przejrzystość i samoorganizacja to podstawy Scruma. Oba aspekty są delikatne i wrażliwe. Oba wymagają cierpliwości i konsekwencji,
  • Oberwało się menedżerom za zbyt pochopne przejmowanie kontroli ("masz to zrobić!") a co za tym idzie odpowiedzialności, oraz deweloperom za zbyt rezolutne, niebudujące zaufania, podejmowanie nierealistycznych zobowiązań, co prowadzi w prostej linii do obniżania jakości ("zasadniczo gotowe"),
  • Konkluzja - nie da się robić agile'a mechanicznie, poprzez wprowadzenie nowej terminologii, uczestnictwo w serii spotkań czy zastosowanie kilku technik czy sztuczek. Trzeba zrozumieć i uznać koncept leżący u podstaw tych praktyk. Słowem - trzeba być agile.

Pytania i odpowiedzi

Po prezentacji padły pytania - trudne i ciekawe, dlatego postaram się kilka z nich przytoczyć (odtwarzam z pamięci, siłą rzeczy parafrazuję). Ponieważ Scrum nie daje odpowiedzi a jedynie pretekst do zadawania pytań i do poszukiwania odpowiedzi, na wiele z poniższych pytań odpowiadam pytaniami :)

Q: Dla jakiego rodzaju projektów Scrum się nie nadaje?
A: Twierdzi się, że dla projektów serwisowo-utrzymaniowych czyli wszędzie tam gdzie sytuacja jest tak szybko zmienna, że nie pozwala na skuteczne zaplanowanie sprintu. W praktyce mniej niż 5% żądań pojawiających się w trakcie sprintu wymaga jakiejkolwiek reakcji, pozostałe mogą poczekać w backlogu do kolejnego sprintu. Jeszcze mniej wymaga podejmowania działań deweloperskich, w większości przypadków wystarcza jedynie wstępne rozpoznanie. Czasem wystarczy zadać pytanie czy podjęcie tej nowej pracy warte jest ryzyka niezakończenia bieżących prac (czyli zawalenia wszystkiego). Jeśli nawet dla krótkich sprintów zakres nie może zostać ustabilizowany pozostaje już tylko pytanie - jak doprowadzono do sytuacji, że produkt jest w tak kiepskiej kondycji i jak przerwać tę mękę. Dopiero potem zabrać się za Scruma.

Q: Czy ma sens i co daje zastosowanie Scruma w projektach typu fixed-everything?
A: Wewnętrznie - podejście interacyjno-inkrementalne da lepsze rozeznanie co do realnych możliwości i w związku z tym lepsze zarządzanie ryzykiem. Może się okazać, że nie jesteśmy aż tak dobrzy jak nam się wydaje i warto się o tym dowiedzieć jak najwcześniej. Zewnętrznie - jeśli tylko uda się zaangażować klienta, pokazując mu działający software co Sprint - Scrum może być narzędziem budowania zaufania, po to by kolejne kontrakty nie musiały już być podpisywane w takiej (paskudnej) formie. Swoją drogą - do przemyślenia - dlaczego podpisujemy takie właśnie kontrakty? Jak to się stało? Kiedy i gdzie straciliśmy zaufanie klientów?

Q: Czy da się zastosować Scruma w środowisku wieloprojektowym (wiele małych 1-2 tygodniowych projektów)?
A: Jak najbardziej tak (jeśli rozumiemy projekt jako byt którego celem jest wprowadzenie zmian w produkcie). Najczęstszy problem w takiej sytuacji to rywalizacja osób reprezentujących poszczególne projekty, mających sprzeczne (wzajemnie) priorytety. Scrum szybko spowoduje, że ta rywalizacja stanie się widoczna i domagać się będzie jej rozwiązania.

Q: Czy jest taka sytuacja, która spowodowałaby, że nie podjąłbym się wdrażania Scruma (brak wsparcia zarządu na przykład)?
A: Chyba nie ma takiej sytuacji (ech, naiwność...). Wsparcie zarządu to ważna rzecz, ale brak energii w ludziach (nie da się, nie ma sensu, nie uda się...) jest zdecydowanie większą przeszkodą (przynajmniej na początku procesu przekształcania organizacji). I przy tej okazji pytanie - jak i kiedy to się stało, że straciliśmy energię do działania? Kto odpowiada za stworzenie warunków, które zdusiły motywację?

Q: Czy traktuję przejrzystość jako nadrzędną wartość i dążę do niej nawet jeśli przemilczano coś z pozytywnych pobudek?
A: (tu chwila wahania...) Tak. Motywacja bierze się z faktu posiadania dostępu do informacji i możliwości działania. Utracone zaufanie bardzo trudno jest odbudować. Przemilczenie czegoś to zawsze kwestia podjęcia odpowiedzialności za ten fakt. Czy naprawdę jestem właściwą osobą by tę odpowiedzialność podejmować? Czy jestem w stanie tą odpowiedzialność udźwignąć czy może przy pierwszej okazji komuś ją podrzucę? W odpowiedzi przytoczyłem historię kiedy sam, działając z pozycji konsultanta, nie widząc po stronie zespołów żadnych działań, narzuciłem proces releasowy. Natychmiast zarzucono mi dwulicowość - mówisz nam tu o samoorganizacji a jednocześnie coś narzucasz? Sytuacja skwasiła się tak mocno, że wymagała objaśnienia mojej motywacji (zrobiłem to po o by przymusić zespół do działania i zgłaszania usprawnień). Być może warto było inaczej to zorganizować? Być może zbyt mało zrobiłem w kwestii zaangażowania zespołu?

Q: Co z rolą kierownika projektu w Scrumie?
A: Odpowiem tak - w idealnej sytuacji zarządzaniem rozwojem produktu zajmuje się Product Owner, zarządzaniem sposobem w jaki wykonywana jest praca zajmuje się Zespół, a zarządzaniem Zespołem zajmuje się... Zespół. Pomaga w tym wszystkim Scrum Master dbając o podstawy Scruma i jego nadrzędne wartości. W praktyce, pozycja kierownika projektu wynika często z potrzeby przeniesienia (eufemizm) na kogoś (z imienia i nazwiska) odpowiedzialności za sukces/porażkę projektu, nadzorowania i/lub spinania (komunikacyjnie) osób realizujących pracę (pomiędzy nimi samymi oraz z szerokorozumianymi mocodawcami). Warto zadać sobie pytanie czy to jest efektywne? Czy może jest inny sposób?

Padło także sporo pytań o motywację zespołów scrumowych oraz mechanizmy premiowania. Ponieważ temat jest złożony zasługuje na osobny wpis.

Czego nie było (a czego się spodziewałem)?

Uniknęliśmy pytań o programy ceryfikacyjne. Scrum Alliance vs Scrum.org vs PMI Agile Certfication. A ponieważ temat jest gorący i będzie wracał pozwolę sobie na krótki komentarz.

Znam wartość programu Professional Scrum (Scrum.org) - uczestniczę w nim aktywnie jako instruktor. Wiem jakie spustoszenie poczynił program szkoleniowy Scrum Alliance. Niefortunna nazwa (Certified...) i brak egzaminów weryfikujących faktyczną wiedzę uczestników w dużej mierze doprowadziły do sytuacji trafnie określanej przez Martina Fowlera "flaccid Scrum". Jaki jest powstający właśnie program PMI? Nie wiem. Podobnie jak w Joshua Kerievskim silny sprzeciw budzi we mnie twierdzenie, że agile'a można dorzucić, jako jedną z wielu technik, do "project management toolboxa". Obawiam się wysypu obrońców pseudo-agile'owego status-quo którzy, z nowymi certyfikatami w garści, będą odmalowywać fasady starych nawyków używając nowej terminologii i pustych sztuczek w rodzaju stand-up meetingu i planning pokera. Utożsamiam się ze stanowiskiem Kena Schwabera i cenię determinację z jaką Tobias Mayer broni samoorganizacji. Zdecydowanie opowiadam się po stronie prawdziwej zwinności a przeciw jej rozmiękłym odmianom. Co z tego wyjdzie - czas pokaże.

Ku mojemy zaskoczeniu nie padło także - a przynajmniej nie zostało zadane wprost - pytanie o to jak przekonać wyższe kierownictwo do Scruma. Szkoda, bo mam wypracowaną zgrabną odpowiedź :) Nie da się nikogo do niczego przekonać gadaniem (można co najwyżej zbałamucić i zyskać na czasie). Tylko konkurencja może sprawić, że zwinność stanie się palącą, rzeczywistą potrzebą. Wyjście od faktycznej potrzeby będzie znacznie skuteczniejsze niż uleganie chwilowej modzie. Mam nadzieję, że nastąpi to szybciej niż przypuszczamy. Czego sobie i Wam przed długim majowym weekendem życzę.

Prezentacja dostępna jest w serwisie SlideShare, a także do pobrania. Zapraszam do dzielenia się swoimi uwagami i spostrzeżeniami w komentarzach.

Komentarze (0)

Zapraszam do komentowania.

Komentujesz jako Gość. Opcjonalny login poniżej.