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.

Właśnie wrzuciłem na SlideShare prezentację z wczorajszego wystąpienia w ramach krakowskiego Ignite pt. Slicing a Cake. Materiał traktuje o zaobserwowanych przeze mnie sposobach podziału dużych historyjek użytkownika (epics) na mniejsze, mieszczące się w pojedynczej iteracji. Zidentyfikowałem w sumie pięć sposobów. Nie wszystkie są jednakowo dobre, kilka wyklucza współpracę z końcowym klientem (odbiorcą oprogramowania) i z tego powodu uważam je za chybione. Zdecydowanie promuję strategię dekompozycji, którą kierowano się dobrych kilkanaście lat temu, przygotowując prototypy oprogramowania (tak zwane lo-fi, hi-fi prototypes opisane na przykład tutaj: ISO/IEC TR 14759:1999 Software engineering - Mock up and prototype - A categorization of software mock up and prototype models and their use). Mimo, iż ubiegłowieczna, technika ta i dziś przynosi wymierne korzyści, umożliwiając użytkownikowi wejrzenie w software wcześnie w cyklu produkcyjnym.

Ponieważ prezentacja jest przygotowana pod 5-minutowe wystąpienie postaram się w przyszłości rozszerzyć wpis na tym blogu omawiając kolejne sposoby nieco szerzej.

Ogólnie rzecz ujmując nie upieram się, że elementami backlogu powinny być user stories. Prezentację dedykuję osobom które, podobnie jak ja sam, zmagają się z nimi, nie znajdując innych, efektywniejszych sposobów. Odkryciem wieczoru było to, że na obecnych 60-70 osób, na pytanie kto używa user stories ręce podniosło 5-6 osób. Na pytanie kto używa stories ręki nie podniósł nikt. A czy Ty, Drogi Czytelniku, używasz historyjek użytkownika? Jeśli tak, jak dokonujesz ich dekompozycji? A może wykorzystujesz zupełnie inne techniki zarządzania wymaganiami?

Jak zwykle udostępniam prezentację w wersji pdf i jak zwykle 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.

Niezmiernie miło mi poinformować, że program konferencji Zimowy Agile Tuning, organizowanej 20 marca 2010 w Krakowie został właśnie ogłoszony. Ustaliliśmy też miejsce imprezy - klimatyczny ośrodek konferencyjny Uniwersytetu Jagiellońskiego w krakowskich Przegorzałach, mieszczący się przy ulicy Jodłowej 13. Miejsce o tyle dla mnie osobiście ważne, że tam właśnie mieściła się siedziba krakowskiej Motoroli, kiedy w październiku 1999 rozpoczynałem pracę. Takich widoków z biura nie miałem nigdy przedtem, ani nigdy potem. Konferencja odbędzie się kilkadziesiąt metrów powyżej "zamku", w domu gościnnym UJ, miejscu nie mniej klimatycznym. Jednocześnie z ogłoszeniem programu rozpoczęła się rejestracja uczestników.

Spieszcie się! Mimo, że do dyspozycji będziemy mieli odnowioną aulę i parę dodatkowych pomieszczeń, liczba miejsc jest ograniczona!

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.

Ruszyły przygotowania do kolejnej edycji konferencji Agile Tuning tym razem organizowanej na pożegnanie zimy 20 marca 2010 w Krakowie. Miejsce jak zwykle będzie klimatyczne, a undergroundowy charakter imprezy zostanie zachowany, mimo zwiększonej liczby uczestników i prelegentów z zagranicy (tak!) :) Call for papers jest już otwarty (spieszcie się!), a rejestracja uczestników rozpocznie się 20-go lutego.

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.

Wszystkich zainteresowanych lekkimi metodami produkcji oprogramowania zachęcam do udziału w mikrokonferencji Letni Tuning, która odbędzie się 25-go czerwca 2009, u stóp Wawelu, na barce Aquarius. Program konferencji przewiduje trzy ścieżki tematyczne - Rzemiosło, Ludzie i Ograniczenia. Więcej informacji na temat konferencji, zasady rejestracji i szczegółowy program, umieszczone są na stronie letni.agiletuning.pl.

Wszyscy uczestnicy konferencji otrzymują 5% upustu na szkolenia Certified ScrumMaster™ i Certified Scrum ProductOwner™ organizowane w ramach Inicjatywy Pod Drzewem we wrześniu 2009!

Start konferencji o godz. 19:00, liczba miejsc ograniczona. Zapraszam!