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.

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.

Coraz częściej otrzymuję zapytania dotyczące problemów związanych z wdrożeniami metodyki Scrum na szerszą skalę. Przez "szerszą" mam na myśli transformację organizacji (firm, departamentów) 50-250 osobowych, często rozproszonych, czy to pomiędzy piętrami, budynkami, miastami, czy po świecie. Zwykle zespoły te zajmują się zarówno rozwijaniem oprogramowania (wytwarzaniem nowych funkcjonalności) jak i utrzymaniem tego co już opracowano i wydano klientowi (klientom) wcześniej (w ekstremalnych przypadkach kilkanaście lat temu). Można zatem założyć, że mamy do czynienia z organizacjami o ustabilizowanych metodach działania (nawet jeśli to "ustabilizowanie" oznacza chaos), ustalonej strukturze organizacyjnej, nazewnictwie stanowisk służbowych oraz wypracowanych na przestrzeni lat procesach wytwórczych, technologii, relacjach, polityce wewnętrznej itd.

Przede wszystkim bardzo mnie cieszy ten stan rzeczy, gdyż oznacza, że w Polsce, podobnie jak na świecie, nurt agile rozwija się dynamicznie i z partyzanckiego, "piwnicznego" ruchu, przeradza się w dostrzegany przez kadry zarządcze pełnoprawny model realizacji projektów. Martwi mnie jednak fakt, iż w starciu z twardym biznesem, istniejącymi strukturami i wypracowanymi przez lata sposobami działania (polityką), idee ruchu agile są nader często marginalizowane. Wyławiane i wykorzystywane są pojedyncze elementy konkretnych metodyk (Scruma, XP, DSDM-a), natomiast pomijane są wartości stojące u podstaw tego ruchu - jednym słowem skupiamy się na "jak?", a nie na "dlaczego? po co?". Ken Schwaber nazywa taki sposób działania "Scrum, but", Martin Fowler "flaccid Scrum", ja nazywam tak powstałe procesy produkcyjne "protezami", "pseudoagile'm" albo "prawiescrumem".

Na marginesie dodam, że nie tak dawno poznałem określenie "wagile" (waterfall agile), opisujące proces w swojej istocie bardzo kaskadowy - ustalenie zakresu na początku cyklu, testowanie i wdrożenie na jego końcu, a jednak podzielony na iteracje, z całą ceremonią z nimi związaną.

Planowanie iteracji, w rozumieniu osób stosujących pseudoagile'a to odkrojenie z kompleksowego harmonogramu kolejnych kilku tygodni, realizacja kolejnych faz produkcyjnych następuje bowiem (po staremu) stopniowo. Przygotowanie wymagań w kilku krokach, kodowanie w kilku kolejnych i testowanie w kolejnych. Codzienne spotkania i sesje demo to narzędzie precyzyjnego, chirurgicznego wręcz, zarządzania zasobami - co, kto, kiedy i na kiedy. I wszechobecne "mendejsy" jako jedyna miara wartości wytwarzanego oprogramowania - "mendejsy" wypracowane muszą równać się "mendejsom" zaplanowanym. Jednym tchem można tu jeszcze dorzucić doskonalenie multitaskingu jako sztuki zawalania kilku projektów na raz i właściwie grunt pod klęskę mamy przygotowany. Jak bardzo wykrzywiony jest to model okazuje się zwykle końcu takiego procesu, kiedy klient (znowu) nie dostaje czego oczekiwał (czasem nie dostaje zupełnie nic), zespół (znowu) jest zdemotywowany, a kierownicy - liniowi i projektów - (znowu) dostają po łbach za to, że (kolejny) projekt zaliczył klapę, albo ciągnie się w nieskończoność. Miało być pięknie (bo teraz będziemy edżajl), a wyszło jak zwykle. A coach jest be, bo pokazuje nam to wszystko palcem. Gdzieś zapomniano, że siłą napędową modelu ewolucyjnego jest zmiana. Przenosimy się z domeny planowania czynności (zadań) na planowanie funkcjonalności (cech) produktu, bez motoru napędowego w postaci zmian ani rusz. Tam zmiana była naszym wrogiem, tu jest sprzymierzeńcem. Ta zupełnie podstawowa zasada ruchu agile znika przykryta przygotowanym na początku projektu harmonogramem, pociągając za sobą zawalenie się kolejnego filara zwinności - samoorganizacji zespołu.

Przy każdej możliwej okazji - szkoleń, wykładów, konsultacji - uczulam moich słuchaczy na fakt, iż "myślenie kaskadowe" jest silniejsze niż nam się wydaje. Może się ono przejawiać w fazowości procesu (zauważenie tego aspektu jest akurat trywialne, chyba, że proces został odświeżony farbą marki "wagile" i trzeba trochę zdrapać żeby się przekonać), może również być ukryte w strukturze organizacyjnej (piony funkcjonalne, struktura macierzowa ze spinającymi komunikację kierownikami projektów), procedurach kontraktowania i budżetowania projektów oraz, co chyba najtrudniejsze do wychwycenia, w mentalności osób biorących udział w przedsięwzięciu. Niechęć do współpracy i konfrontacji rezultatów pracy z klientem i jego oczekiwaniami, niechęć do podnoszenia poprzeczki inżynierskiej, niechęć do doskonalenia procesu produkcyjnego i wyciągania nauki z popełnionych błędów, ba... niechęć do przyznania głośno, że niektóre procedury po prostu nie działają i miliony wymówek z tym wszystkim związanych. "Jesteśmy agile, bo refaktorujemy już drugi sprint", "Świetnie, a jakie jest pokrycie tego kodu testami? Ile automatycznych testów w czasie tych dwóch sprintów powstało?", "...Mmmm... żadnego. A pokrycie na razie wynosi zero, bo testy PM zaplanował na 8. sprint." - brzmi (dumna) odpowiedź. Uff... Tego typu anegdoty mógłbym przytaczać (niestety) w nieskończoność.

Ale po co o tym wszystkim piszę? Ano dlatego, że czas już chyba pójść o krok dalej - nie tylko agile dla zespołów, ale też agile dla organizacji, departamentów, pionów i całych firm. Nie wystarczy poszatkować harmonogram na "sprinty" i zagonić programistów do planning pokera (w "mendejsach", a w najlepszym razie w punktach przeliczanych przez PM-a na "mendejsy"). Agile warto wdrażać na serio, agile może stanowić podstawę działania. Owszem, potrzebna będzie szeroka i głęboka zmiana, sięgająca fundamentu, na którym opiera się organizacja. Taką zmianę można zainicjować i można z sukcesem przeprowadzić. Warto jednak najpierw przemyśleć zbiór swoich wartości i przekonań, odpowiadając na pytanie po co nam agile. Odpowiedź będzie stanowić fundament, na którym tranzycja, często długa i żmudna, zostanie oparta.

Odbyły się już dwa z trzech planowanych na pierwszy kwartał 2010 szkoleń otwartych. Podczas szkolenia Kanban w inżynierii oprogramowania, które odbyło się 25 i 26 stycznia 2010 w Krakowie, David J. Anderson opowiedział o idei odchudzonych (lean) procesów i roli techniki kanban w projektach informatycznych. Uczestnicy dowiedzieli się jak konstruować tablicę kanban, czym jest rytm i w jaki sposób regulować pracę zespołu aby uzyskać płynny przepływ produktu przez proces wytwórczy.

Drugie ze szkoleń, regularnie organizowany kurs Certified ScrumMaster, tym razem prowadzone przez Dana Rawsthorne'a, wprowadziło uczestników w podstawy metodyki Scrum. Zgodnie z obowiązującymi obecnie regułami certyfikacji wszyscy uczestnicy otrzymali certyfikaty CSM. Kolejna edycja tego szkolenia odbędzie się już 30-31 marca 2010, tym razem w Warszawie. Na to szkolenie są jeszcze wolne miejsca, zapraszam serdecznie do udziału!

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!

Oba zaplanowane na wrzesień certyfikacyjne szkolenia scrumowe już za nami. W trakcie pierwszego z nich, szkolenia Certified ScrumMaster, które odbyło się 21 i 22 września 2009, Angela Druckman wprowadziła grupę siedemnastu osób w podstawy Scruma i rolę Scrum Mastera. Drugie ze szkoleń prowadzone przez Dana Rawsthorne'a bardziej zaawansowane i zapewne tego powodu kameralne szkolenie Certified Scrum ProductOwner, które odbyło się 29 i 30 września 2009, pozwoliło sześciu uczestnikom wzbogacić warsztat właściciela produktu i pokazało, że występując w tej roli nie należy unikać sprawdzonych, tradycyjnych, technik zarządzania projektami. Zdecydowanie bardziej niż dobór narzędzi liczy się bowiem styl myślenia i cel, czyli uzyskanie szybkiego przyrostu wartości wytwarzanego oprogramowania.

W imieniu obojga instruktorów i swoim dziękuję wszystkim za udział!

Najpopularniejszą rolą scrumową jest bez wątpienia ScrumMaster. Większość osób szukając szkolenia "scrumowego" pyta właśnie o szkolenia dedykowane ScrumMasterom. Tymczasem rolą tak samo istotną, a w moich oczach nawet istotniejszą, bo bezpośrednio reprezentującą biznes i będącą w gruncie rzeczy rzecznikiem interesów klienta jest ProductOwner.

Sukces projektu zależy od umiejętności ProductOwnera w zakresie planowania przedsięwzięcia, umiejętności podejmowania decyzji podejmowanych na podstawie wypracowanych przez zespół postępów, efektywnej współpracy z zespołem i komunikacji z końcowym odbiorcą czy użytkownikami oprogramowania. Ponadto w roli ProductOwnera skupiają się perspektywy wszystkich osób zainteresowanych danym przedsięwzięciem osób - ich interesy ProductOwner także musi reprezentować.

Szkolenie Certified Scrum ProductOwner ma na celu zmianę sposobu postrzegania osoby i roli ProductOwnera w projektach scrumowych. Celem szkolenia jest uświadomienie aktualnym i przyszłym właścicielom produktu, jak istotna jest ich rola, umiejętności i warsztat, którym się posługują.

Pierwszy dzień szkolenia poświęcony jest definiowaniu roli i zakresu obowiązków ProductOwnera, różnicom i podobieństwom tej roli w stosunku do tradycyjnych ról kierownika projektu czy kierownika produktu.

Dzień drugi szkolenia poświęcony jest ćwiczeniu warsztatu i jego przebieg jest mocno uzależniony od kompetencji i doświadczenia trenera. Zwykle szkolenie skupia się na technikach gromadzenia wymagań w metodach lekkich, ćwiczeniu umiejętności analitycznych, umiejętności planowania procesu produkcji oprogramowania oraz wykorzystaniu miar projektowych. Na szkoleniach CSPO uczestnicy zwykle zostają zapoznani ze specyfiką projektów dużej skali, realizowanych wielozespołowo, w środowisku dużych organizacji.

W szkoleniach prowadzonych przez dra Dana Rawsthorne-a, z którym współpracuję, poruszane są także zaawansowane (i często kontrowersyjne) zagadnienia wykorzystania tradycyjnych narzędzi takich jak Earned Value Management w projektach dużej skali realizowanych metodą Scrum. Dan jest prekursorem stosowania lekkiej odmiany tych miar - Earned Business Value.

Więcej na temat szkolenia...

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!

Pierwsze szkolenie Certified ScrumMaster organizowane "pod drzewem" we współpracy z firmą Danube zakończone. Po intensywnym, burzliwym w swoim przebiegu kursie, który odbył się w Krakowie, 22 i 23 kwietnia 2009, 17 osób uzyskało certyfikaty Certified ScrumMaster.

W imieniu swoim i trenera - Michaela Jamesa - serdecznie dziękuję wszystkim uczestnikom za udział, gratuluję i życzę powodzenia w roli ScrumMasterów!

Z dużą przyjemnością ogłaszam najbliższe plany dotyczące szkoleń certyfikacyjnych w metodzie Scrum. We współpracy z firmą Danube na wrzesień planowane są dwie sesje szkoleniowe - szkolenie Certified ScrumMaster™ oraz, odbywające się po raz pierwszy w Polsce, zaawansowane szkolenie Certified Scrum ProductOwner™. Na wrzesień planowane są następujące sesje szkoleniowe...

• 21-22 września 2009, szkolenie Certified ScrumMaster™
• 29-30 września 2009, szkolenie Certified Scrum ProductOwner™

Dla osób, które wzięły udział w badaniu zapotrzebowania na szkolenie Certified Scrum ProductOwner dodatkowy rabat w wysokości 5% (w najbliższych dniach zostaną wysłane indywidualne maile z kodem rabatowym). Dziękuję, tym bardziej, że niektórym z Was przyszło czekać bardzo długo!

Zapraszam serdecznie do udziału!