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 ;)

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 w repozytorium. Zapraszam do dzielenia się swoimi uwagami i spostrzeżeniami w komentarzach.

Wczoraj miałem przyjemność wystąpić w webinarze Polskiej Grupy Użytkowników Scrum prezentując materiał Scrum, Scum, Sacrum. Moim celem było wskazanie miejsc w których najczęściej dochodzi do osłabienia metodyki. W tym celu wykorzystałem, raczej jako luźny pretekst niż umocowanie mojej argumentacji, wyniki wspominanej wielokrotnie na tym blogu ankiety przeprowadzonej dokładnie rok temu. Stawiam tezę, że samoorganizacja jako koncepcja zarządzania zespołami projektowymi jest szalenie trudna do osiągnięcia w warunkach średniej i dużej organizacji, przede wszystkim ze względu na czas konieczny do przyswojenia tej idei. Zespoły potrzebują czasu aby nauczyć korzystać się z autonomii, kierownictwo wymaga czasu aby nauczyć się nowej, przywódczej, wspierającej roli.

Podstawowym narzędziem doskonalenia w zespole samoorganizującym jest nauka na (własnych) błędach. Dość powszechna w świecie biznesu kultura braku marginesu (przyzwolenia) na popełnianie błędów sprawia, iż w dążeniu do perfekcji, popadamy w pułapkę planowania. Przygotowujemy harmonogramy i procedury, znacznie zawężając w ten sposób pole możliwości, przez co, szczególnie w przypadku tak złożonych przedsięwzięć jak prace programistyczne, osiągane rezultaty są gorsze niż mogłyby być. Teoretycznie wszyscy zdają sobie sprawę, że "plan jest niczym, planowanie jest wszystkim", jednak w praktyce ogromny nacisk kładziony jest na utrzymanie zgodności z planem. Fantastycznie ujął problem Barry Schwartz w swoim odczycie On our loss of wisdom na konferencji TED - procedury powodują, że wyłączamy rozum, a zabezpieczeni w ten sposób przed katastrofalnymi omyłkami, osiągamy perfekcyjnie wykonaną przeciętność. Idąc o krok dalej tym tropem można postawić tezę, że tradycyjne planowanie skoncentrowane jest na ograniczaniu kosztów i ryzyka, pomija natomiast aspekt osiąganej systematycznie wartości. Obie te myśli będę chciał rozwijać w przyszłości.

Problem jest szeroki i nie ma prostych odpowiedzi na stawiane w prezentacji pytania. Faktem jest iż Scrum bywa mylnie postrzegany jako proces, który ma dać szybką poprawę sytuacji. Jeśli tak się nie dzieje (a tak jest zazwyczaj) jego założenia są zmieniane, często w sposób mechaniczny, bez zachowania reguł empirycznej kontroli procesu i samoorganizacji. Tym samym utracony zostaje sens jego wprowadzenia, a z nim możliwość uzyskania trwałej zmiany przynoszącej korzyści w dłuższym horyzoncie.

Prezentacja dostępna jest w serwisie SlideShare, a najbardziej aktualna wersja dostępna jest w repozytorium. Zapraszam do dzielenia się swoimi uwagami i spostrzeżeniami w komentarzach.

Na stronach tego bloga już kilkukrotnie zapowiadałem odniesienie się do wyników ankiety badającej wykorzystanie Scruma w polskich firmach. Biję się w pierś - niestety brak czasu skutecznie mi to uniemożliwia, jak zresztą jakąkolwiek inną formę aktywności na blogu także. Byłoby bardzo szkoda gdyby wyniki tego badania pozostały do wglądu jedynie organizatorów i respondentów bowiem, mimo nikłej liczby uczestniczących w nim osób, badanie to pozwala na formułowanie wniosków, które można potraktować jako wskazówki podczas przyszłych wdrożeń metodyki. Na szczęście krótkie opracowanie omawiające garść najważniejszych akspektów, przygotowane na podstawie raportu z badań przez dr Marka Ćwiklickiego, zostało właśnie opublikowane w periodyku Nauka i Gospodarka - do pobrania tutaj lub w lokalnym repozytorium tutaj. Zapraszam do lektury.

Kolejna partia materiałów wykładowych załadowana do repozytorium. Tym razem myślą przewodnią wykładu jest skalowanie metod lekkich. Niestety, ze względu na przedłużające się odbiory projektów, wykład trwał niecały kwadrans... zdążyłem jedynie podkreślić najistotniejsze kwestie zastosowania Scruma do wdrażania Scruma. Przytaczam je poniżej raz jeszcze. Materiały dostępne są też w formie pdf i mmap.

Planując wdrożenie lekkich metodyk:

• miej cel, ustal jakie problemy stają na drodze do osiągnięcia tego celu i jakimi środkami można ten cel osiągnąć (stwórz backlog wdrożeniowy)
• ustal na jakie wsparcie możesz liczyć i na tej podstawie zdecyduj jak szerokie i głębokie cięcie chcesz przeprowadzić - od partyzanckiego Scruma (o którym nikt oprócz zaangażowanego zespołu nie wie), poprzez pilotażowy projekt, aż po pełną reogranizację
• zaplanuj jak praca projektowa zostanie zdekomponowana na zespoły - w miarę możliwości likwiduj zespoły funkcyjne i komponentowe, na rzecz tworzenia zespołów aspektowych (feature teams), działających wskroś całego systemu
• zaplanuj jak będzie nadzorowane i wspierane wdrożenie - pomocne może być utworzenie zespołu realizującego backlog wdrożeniowy (zespół wirtualny) i wykorzystanie jawnego backlogu problemów związanych z wdrożeniem (impediments backlog) jako narzędzia komunikacji
• przemyśl i zaplanuj rytm (puls): planowania iteracji, przeglądu iteracji, integracji między zespołami, wydań, retrospekcji, synchronizacji zespołów i przepływu informacji - wszystkie te wydarzenia powinny przebiegać w stałym, zsynchronzowanym dla całej organizacji, rytmie
• promuj solidne podstawy inżynierskie (higienę inżynierską) - przejrzystą architekturę systemu, wysoką jakość wytwarzanego kodu (standardy kodowania, koleżeńskie przeglądy, proste, przejrzyste reguły wersjonowania, częstą (ciągłą) integrację, (automatyczne) testy jednostkowe, (automatyczne) testy akceptacyjne) - promuj wiedzę o programowaniu ekstremalnym (Extreme Programming)
• przygotuj się na głęboką zmianę (nawet jeśli cięcie nie wydaje się głębokie) i spowodowany nią opór - konsekwentnie dąż do wypełniania kolejnych elementów backlogu wdrożeniowego, obserwując uważnie; nie łam oporu za wszelką cenę, bądź przygotowany na zmianę planów
• postaw na podnoszenie poziomu wiedzy w zespole (zespołach): o celu zmiany, stosowanych środkach (metodach, technikach, procedurach); dbaj o rzetelne informowanie o bieżącym stanie i kondycji zespołów i realizowanych projektów (retrospekcje na poziomie całej organizacji) - rozważ szkolenia, zaangażowanie zewnętrznych lub wewnętrznych coachów, a także lokalne społeczności, pozwalające na wymianę wiedzy (zespoły wirtualne, scrumy-scrumów, społeczności)

Pokrótce tyle. Problem zarysowany. Zapraszam do dyskusji w komentarzach.

Tuż przed świętami zespołowi opracowującemu badanie ankietowe "Scrum w polskich organizacjach IT", do udziału w którym zachęcałem w sierpniu, udało się zamknąć raport z badania. Przypominam, że było to pierwsze w Polsce badanie poświęcone metodyce Scrum, a jego celem było ustalenie, jak praktyki scrumowe realizowane są w polskiej, biznesowej rzeczywistości, oraz w jakim stopniu samoorganizacja zespołów, będąca trzonem tej metodyki, wygląda w polskich firmach.

W wersji finalnej raport ma ponad 50 stron i zawiera opracowanie wyników ankiety przygotowane przez zespół specjalistów z Katedry Metod Organizacji i Zarządzania Uniwersytetu Ekonomicznego w Krakowie, działający pod kierunkiem dra Marka Ćwiklickiego, oraz moje komentarze zorientowane na praktyczne aspekty wdrożenia Scruma w organizacji. Raport ten, w ramach podziękowania za udział w badaniu, został rozesłany do osób, które wzięły w nim udział.

Ponieważ raport nie będzie publicznie dostępny, w najbliższych tygodniach, na tym blogu, będę prezentować i omawiać najistotniejsze moim zdaniem znaleziska.

Jakiś czasu temu chodziło mi po głowie uruchomienie społecznej inicjatywy stworzenia szablonu kontraktu, który promowałby wartości agile'owe, przede wszystkim iteracyjność i współpracę klienta z producentem oprogramowania. Pomysł ten wrócił kiedy na forum scrumowym Goldenline pojawiła się prośba o udostępnienie takiego kontraktu. Ponieważ na konkretne potrzeby współpracujących ze mną firm, przygotowałem kiedyś "scrumową" umowę (bazującą na modelu "time & material", a wzbogaconą o elementy "money for nothing, changes for free"), postanowiłem ją udostępnić wszystkim, którzy zadeklarują swój czas i doświadczenie w jej doszlifowanie i przerobienie w ogólny szablon.

Na pewno temat kontraktów wróci na tego bloga, tymczasem jeśli ktoś jest tematem zainteresowany - proszę o komentarz poniżej/maila.

Z przyjemnością informuję, że zakończyłem pracę nad polskim opracowaniem tekstu „Scrum Guide” autorstwa Kena Schwabera i Jeffa Sutherlanda. „Przewodnik po metodyce Scrum” bazuje na listopadowej (11/2009) wersji dokumentu. Oryginał oraz tłumaczenia na inne języki dostępne są tutaj. Jednocześnie pragnę podziękować osobom, które pomogły mi z tego dość niewdzięcznego do tłumaczenia tekstu, przygotować przejrzyste i spójne (tak sądzę!) opracowanie - dzięki! :)

Z dużą satysfakcją publikuję terminy szkoleń otwartych na pierwszy kwartał 2010 roku. Oprócz szkoleń certyfikacyjnych w metodzie Scrum odbędzie się bowiem, po raz pierwszy w Polsce (to już druga premiera Pod Drzewem), otwarte szkolenie Kanban w inżynierii oprogramowania. Szkolenie to będzie prowadzone przez pioniera stosowania techniki kanban w projektach software-owych - Davida J. Andersona.

W pierwszym kwartale 2010 planowana jest także druga edycja zaawansowanego szkolenia Certified Scrum ProductOwner™, którego termin nie został jeszcze ustalony. Osoby zainteresowane tym szkoleniem proszę o kontakt.

Harmonogram szkoleń otwartych przedstawia się następująco:

• 25-26 stycznia 2010, Kraków, szkolenie Kanban System for Software Engineering
• 3-4 luty 2010, Kraków, szkolenie Certified ScrumMaster™
• 30-31 marzec 2010, Warszawa, szkolenie Certified ScrumMaster™

Szkolenia certyfikacyjne w metodzie Scrum organizowane są jak zwykle we współpracy z firmą consultingową Danube ze Stanów Zjednoczonych.

Zapraszam serdecznie do udziału!

We współpracy z Katedrą Metod Organizacji i Zarządzania Uniwersytetu Ekonomicznego w Krakowie prowadzimy badanie dotyczące stopnia zaawansowania wykorzystania lekkich metod zarządzania projektami w krajowych przedsiębiorstwach branży IT, w szczególności metody Scrum. To pierwsze tego typu badanie przeprowadzane w naszym kraju.

Wypełnienie ankiety, do udziału w której wszystkich korzystających w jakimś stopniu ze Scruma gorąco zachęcam, nie powinno zająć więcej niż 35 minut. Zdajemy sobie sprawę, że to spora inwestycja, w związku z czym, w podziękowaniu, wszystkim osobom biorącym udział w badaniu prześlemy końcowy raport wraz z materiałami dodatkowymi zawierającymi opis metody w kontekście innych metod opartych na modelu samozarządzania się zespołu oraz wskazówki w jaki sposób z tych metod najpełniej korzystać.

Dane gromadzone będą począwszy od 31 sierpnia do 30 września 2009.

Zapraszamy do udziału!

Osoby poszukujące podstawowych informacji na temat Scrum-a zapraszam do zapoznania się z materiałami szkolenia Scrum Podstawy udostępnionymi w serwisie SlideShare. Prezentacja dostępna jest również w wersji pdf w sekcji Materiały dla uczestników szkoleń.

W środę, 28 stycznia 2009, odbyło się w Krakowie trzecie spotkanie Polish Scrum User Group którego tematem były mechanizmy motywowania osób i zespołów pracujących w modelu Scrum i zbliżonych. Podsumowanie tego spotkania zamieszczone jest na stronie grupy. Zapraszam do wyrażania swoich spostrzeżeń i opinii na ten temat.

Zainteresowanych tą tematyką zachęcam do pobrania ściągi z której korzystałem do otwarcia spotkania i wprowadzenia do dyskusji, i na którą naniosłem pojawiające się w trakcie spostrzeżenia. Znajdują się w niej również odnośniki do materiałów źródłowych i literatury. Plik w formacie MindManager (mmap), do jego wyświetlenia będzie potrzebny viewer lub inne narzędzie obsługujące ten format.

 Motywowanie zespołu scrumowego - mapa myśli w formacie MindManager