blog.testowka.pl

Scrum

ALE na ACE, ACE z ALE w tle – czyli event, którego nie możecie przegapić

opublikowany przez 25, Mar, 2016, w kategoriach Agile, ALE, Scrum

Jak niektórzy z Was zapewne wiedzą, od kilku już lat udzielam się w ruchu Agile Lean Europe oraz w jego Krakowskim odziale ALEKraków. W ramach ALEKraków organizujemy różne lokalne, ale też globalne wydarzenia jak np. ALE Unchonference 2014 w Krakowie. Oprócz tego wspieramy konferencje, czy to jako patroni społecznościowi czy zaangażowani wolontariusze. A wszystko po to, by szerzyć wiedzę na temat współczesnych – zwinnych i szczupłych metod wytwarzania oprogramowania.

W zeszłym roku w ramach naszej grupy pojawił się pomys,ł by zorganizować konferencję w Krakowie na wzór ALE Unconference. Pomysł świetny, tylko że nauczeni doświadczeniami z organizacji un-conferencji z 2014 roku zdawaliśmy sobie sprawę jak duże jest to wyzwanie. Ponadto pojawiło się pytanie czy w ogóle jest potrzeba organizacji w Krakowie kolejnej konferencji. Mniej więcej w tym samym czasie zostaliśmy zaproszeni przez organizatorów Agile Central Europe do objęcia patronatu nad tą konferencją. Wtedy to przyszedł nam do głowy szalony pomysł – a co gdyby tak, zamiast zwykłego patronatu spróbować w ramach ACE zaopiekować się ścieżką tematyczną dotyczącą Agile i Lean. Pomysł spodobał się organizatorom i tak oto wspólnie z ekipą ACE pod wodzą Paul’a Klipp’a objeliśmy opieką „procesową” ścieżkę tematyczną na Agile Central Europe 2016.

Osobiście miałem przyjemność wziąć udział między innymi wyborze prelegentów i tematów do „naszej” ścieżki. I właśnie tym kogo i dlaczego zaprosiliśmy chciałbym się z Wami podzielić. Pamiętam jak kilka lat temu rozmwiałem z Paulem na temat organizacji konferencji i eventów. Wtedy Paul podzielił się swoimi doświadczeniami i przemyśleniami – jednym z nich było stwierdzenie: „Organizuj wydarzenia, w których sam chciałbyś wziąć udział” – i własnie chyba tym głównie kierowaliśmy się podczas układania programu ACE 2016.

Poniżej tylko kilkoro z prelegentów. Pozwalam sobie pominąć Kenynote Speakerów których zapewne dobrze znacie i nie trzeba ich nikomu przedstawiać. A jeśli ktoś nie wie kim jest Mary Poppendieck czy David Hussman to niech szybko googluje.

W ramach scieżki procesowej pierwszy dzień otworzą Ewa Koprowska z PZU oraz Marc Löffler. Zaprosiliśmy Ewę, gdyż istotne dla nas są nie tylko doświadczenia z całego świata, ale też osiągnięcia na naszym lokalnym gruncie, a to co się dzieje w PZU ostatnio warte jest pokazania szerszej publiczności. Marc to konferencyjny wyjadacz. Widząc jego zgłoszenie nie zastanawialiśmy się długo – zawsze gdy mieliśmy przyjemność go oglądać i słuchać na żywo dowiadywaliśmy się czegoś nowego i zaskakującego. Tym razem z pewnością też nas nie zawiedzie. Poza tym Marc to świetny gość – warto zaczepić go w przerwie na kawę i porozmawiać!

Pierwszego dnia równolegle do sesji Open Space (moja ulubiona część każdej konferencji) Claudio Perrone będzie prowadził warsztat z Poppcorn Flow – czyli o tym jak w sposób ciągły, bezboleśnie wdrażać zmiany w organizacji. Oprócz tego, że Claudio jest świetnym mówcą to jest on też jednym z najznamienitszych praktyków Lean i A3 Thinking w Europie. Do Claudio będzie również należała scena drugiego dnia, gdzie wystąpi jako jeden z Keynote Speakerów.

Popołudnie to miedzy innymi wykład Kuby Nabrdalika o tym jak poradzić sobie z tematem tabu – pieniędzmi/pensjami. To chyba dosyć nietypowy temat dla Kuby, którego znam głównie z mocno technicznych prezentacji, ale z pewnością warto będzie uczestniczyć w tym wykładzie. Jego bogate doświadczenia z pewnością zostaną w odpowiedni sposób zaprezentowane na scenie.

Drugi dzień to między innymi  Luis Gonclaves, który podzieli się swoimi doświadczeniami z wielu transformacji Agile i wdrożeń Scrum. Luis poprowadzi też warsztaty z retrospekcji, w których warto wziać udział jeśli pracujecie używając Scrum.

Na ACE zdecydowanie warto zostać do samego końca, gdyż tutaj miejsce będą miały dwie prezentacje, których ja osobiście nie chciałbym opuścić. Popołudnie będzie należało do Pawła Wrzeszcza i Mariusza Sieraszczkiewicza, którzy opowiedzą o swoich doświadczeniach w pracy z różnymi zespołami. Obydwaj panowie to doświadczeni programiści i o ile Mariusz chyba nadal trochę bardziej skupia się na bardziej technicznych aspektach pracy to Paweł ostatnio rozwija się głównie w kierunku coachingu. Ten duet i to połączenie różnych perspektyw i umiejętności to moim zdaniem jedno z najbardziej efektywnych ustawień pozwalających na efektywne wdrażanie zmian w organizacjach. Sam często w takim układzie pracuję z moimi kolegami i koleżankami, tymbardziej chętnie posłucham o tym jak robią to inni.

Ostatnia prezentacja w ścieżce procesowej to prezentacja Miny Boström Nakićenović, która w przejrzysty sposób pokaże jak wiele możemy się nauczyć na temat wytwarzania oprogramowania czerpiąc z innych dziedzin – chociażby takich jak biologia. Osobiście widziałem już tą prezentację w 20 minutowej wersji – w stylu Pecha-Kucha, niemniej jednak z pewnością obejrzę dłuższą wersję jeszcze raz – bo warto!

Oprócz tematów procesowych z zakresu Lean i Agile jest jeszcze cała ścieżka produktowa, gdzie można będzie dowiedzieć się ciekawostek z zakresu rozwoju produktu, UX, Lean Startup itp.

W imieniu swoim i pozostałych organizatorów serdecznie zapraszam Was na ACE 2016.

A gdybyście w przyszłości chcieli zaangażować sie w działania ALE Kraków – to również zachęcam do dołączenia do naszej otwartej grupy!

3 komentarze więcej...

Jak radzić sobie z Timeboxami?

opublikowany przez 28, Kwi, 2015, w kategoriach Agile, Scrum

clock-248718_640
Podczas jednego z realizowanych przeze mnie projektów coachingowych (Agile Coaching) pojawił się problem z timeboxami. Poniżej kilka fragmentów maila jaki przysłała Scrum Master zespołu.
Z jednej strony fajnie, że się (developerzy) angażują i widzą pewne problemy w zespole (…) Nie chcę przerywać komuś kto odważył się włączyć do dyskusji w połowie zdania, bo wiem, że każdy tak naprawdę dojdzie do sedna tego co chciał powiedzieć. Ale z drugiej strony fakt, że nie jestem w stanie przewidzieć kto w kwestii danego problemu się odezwie i ile zajmie mu wypowiedź sprawia, że Retrospekcje strasznie się przeciągają – czasem nawet o półtorej godziny!
Tak, przedłużanie spotkania o półtorej godziny to faktycznie problem. Twórcy Scrum tworząc ten framework zadbali o to, by każdy artefakt i spotkanie miały określony cel, który jest ważniejszy od samego sposobu  przeprowadzania tego spotkania czy implementacji danego artefaktu. Wprowadzenie ram czasowych jest też nie bez znaczenia – w ten sposób jesteśmy w stanie w efektywnie zarządzać naszym czasem. Mając jasno określony cel – to co chcemy mieć po wyjściu ze spotkania i ramy czasowe pozostaje nam jedynie wymyślenie efektywnego sposobu osiągnięcia celu w zadanym czasie.
Jak sobie zatem radzić z problemem przedłużających się spotkań – oto co było w dalszej części maila:
Nie mamy pomysłu co można by jeszcze zmienić. Do tej pory staraliśmy się zoptymalizować:
– przygotowanie planu spotkania (w miarę możliwości)
– wybieranie najważniejszych problemów (które mają odpowiednią ilość głosów innych członków zespołów)
– moje przypominanie ile jeszcze zostało do końca spotkania (ile mamy czasu)
I o ile dochodzimy do postanowień i wszystkie cele tego spotkania są spełnione, to jednak nie jesteśmy w stanie zmieścić się w czasie.
Powyższe próby to z pewnością dobra droga. Jak widać w powyższej wypowiedzi cel spotkania jest osiągany a głównym problemem jest próba zamknięcia tematu w ramach czasowych.
Najważniejsze jest to, by z retrospekcji były jakieś postanowienia (konkretnie: zaplanowane akcje, które można wykonać a nie obietnice) i by te postanowienia były realizowane.
Zanim zasugeruję jakieś rozwiązanie tego typu problemu kilka pytań pomocniczych:
  • Czy czujecie/widzicie, że robicie postępy dzięki takim retrospekcjom? Czy wnoszą one wartość? Czy wartość retrospekcji przewyższa koszt czasu spędzonego na tym spotkaniu?
  • Czy oprócz tego, że „łamiecie reguły” Scrum przedłużając retrospekcje są jakieś negatywne efekty takich przedłużonych spotkań? Jakie?
  • Czy zespół widzi to jako problem?
  • Czy ktoś poza zespołem widzi to jako problem? (BTW: Jeśli tak to co mu do tego?)
  • Nieśmiertelne pytanie do Scrum Mastera – czy pytałaś zespół o to jak rozwiązać ten problem?
    • Czy według Was gdyby spotkanie było krótsze to mogło by być równie efektywne? Co musiało by się stać żeby tak było?

Moim zdaniem (wynika to z mojego doświadczenia) w pierwszej kolejności wdrażając tą czy inną praktykę powinniśmy nastawić się na osiągnięcie oczekiwanego efektu stosowania danej praktyki (w tym przypadku na osiągnięcie celu w postaci zaplanowanych konkretnych usprawnień). Jeśli mamy z tym problem to nie skupiajmy się na detalach takich jak przestrzeganie timeboxów – na to przyjdzie czas później. Byćmoże w Waszych zespołach nie ma takich problemów i wszystko udaje się zrobić przed czasem (a może jednak nie do końca i nie wszystko?) – w każdym razie, timebox nie zawsze jest Waszym największym problemem.

A jeśli faktycznie przedłużające się spotkania są (już) Waszym głównym problemem (prędzej czy później zapewne będą, ale może jeszcze nie teraz) to proponuję próbę wdrożenia poniższego eksperymentu.
To co teraz napiszę może wydać się Wam brutalne – niemniej jednak postarajcie się potraktować to jak eksperyment: Jednym z najlepszych sposobów na przestrzeganie timeboxów (czy to na retrospekcji, czy na planowaniu, czy na Daily Scrum) jest przestrzeganie timeboxów. Tutaj Scrum Master musi się wcielić w rolę managera (o rolach i wcieleniach Agile Coacha pisałem tutaj) a nawet managera-tyrana i w momencie, gdy skończy się czas przewidziany na dane spotkanie brutalnie je zakończyć nawet jeśli cel nie został osiągnięty i efekty nie są zadowalające.
By coś osiągnąć w ramach określonego timeboxu warto podczas spotkania przypominać o tym, że czas się kończy, niemniej jednak, takie groźby muszą mieć pokrycie i gdy czas się skończy to spotkanie faktycznie musi się skończyć.
Z mojego doświadczenia przeważnie wystarczało jedno-dwa takie ucięte spotkania by za trzecim razem udało się osiągnąć cel. Warto zastosować tą zasadę nie tylko do retrospekcji, ale także do każdego innego wydarzenia w Scrum i nie tylko. To jest dobra praktyka, której stosowanie warto wypracować w zespole.
Oczywiście nie jest to rozwiązanie uniwersalne i może nie być wręcz wskazane dla zespołów, które dopiero zaczynają swoją przygodę z retrospekcjami i którym jeszcze nigdy nie udało się wnieść realnej wartości podczas takich spotkań. Także tak jak w opisanym przypadku radził bym najpierw nauczyć się osiągać cel takich spotkań a później pracować nad (istotnymi) szczegółami typu ramy czasowe.
Z pewnością takie rozwiązanie jest też raczej ostatecznością – warto wcześniej spróbować omówić ten problem w zespole i wspólnie znaleźć jego rozwiązanie (takie czy inne). Czasem wystarczy dobra moderacja spotkania – na przykład jeden z zespołów z którym pracowałem szybko przejął ode mnie powiedzonko: „no dobrze – ale do brzegu…”, które humorystycznie wykorzystywałem zawsze, gdy miałem poczucie, że rozmowa nie idzie w kierunku rozwiązania problemu tylko raczej jest na bardzo ogólnym poziomie i „pływamy” – a raczej dryfujemy bez celu zamiast skupić się na rozwiązaniu. „Do brzegu…” stało się zwrotem-wytrychem we wzajemnych relacjach zespołu.
Nie bez powodu użyłem słowa eksperyment powyżej. To nie jest tak, że macie od razu  wprowadzać powyższe zasady – sprawdźcie czy to u Was zadziała. A jeśli nie, to przeprowadźcie kolejny eksperyment – zmieńcie coś. Żeby eksperyment z brutalnym odmierzaniem czasu (czy jakikolwiek inny eksperyment) mógł się udać potrzebna jest przede wszystkim zgoda na jego przeprowadzenie wszystkich biorących w nim udział dlatego warto wytłumaczyć na czym ten eksperyment polega i jaki jest jego cel.
Jest jeszcze idea spotkań
Więcej na temat timeboxów pisałem w „Mity i Problemy w Agile„. Znajdziecie tam obszerniejszy opis tego dlaczego poszczególne spotkania w Scrum nie powinny być ani za długie ani za krótkie.
Dodaj komentarz więcej...

Światełko w tunelu dla Skalowania Agile

opublikowany przez 17, Gru, 2014, w kategoriach Agile, Scrum, Zarządzanie

Ci z Was, którzy znają mnie nie od wczoraj dobrze wiedzą, że nie jestem zwolennikiem żadnej z coraz popularniejszych „metod” skalowania Agile. Często wypowiadam się na ten temat i przeważnie negatywnie.

„Jeśli skalujesz Agile to robisz to źle.”

Wszystkie znane mi do tej pory metody i frameworki z SAFe (Scaled Agile Framework), Scrum of Scrums  i Agility Path na czele próbują narzucić rożne zasady i reguły, które maja być mniej lub bardziej uniwersalne dla każdej organizacji. To po prostu nie ma prawa działać.

Miałem okazję przez ostatnich kilka lat pracować z wieloma organizacjami, niektóre z nich były całkiem duże. Na tyle duże, że musiały zmierzyć się z problemem skalowania. Najczęstszym błędem który podczas takich prób zmierzenia się ze skalowaniem widziałem była próba zastosowania danej metody skalowania bez uprzedniego zastanowienia się nad problemami, które chce się rozwiązać.

Większość promowanych „metod” ze znajomości, których można sobie zrobić (kupić) różne certyfikaty których ładnie brzmiące nazwy możemy sobie później wpisać na linkedin według mnie nie rozwiązuje podstawowych problemów, lecz wręcz przeciwnie poprzez swoją pozorną prostotę i obietnicę naprawienia wszechświata generują więcej problemów niż rozwiązują. Nie – nie neguję wartości tych metod (nie wszystkich i nie całkowicie – tylko trochę) – niektóre z nich świetnie działają w pewnym kontekście. Niektóre pojedyncze elementy tych metod bazują przecież na prawdziwych wartości Agile i Lean jedyne co jest z nimi nie tak to próba zbudowania z nich zamkniętego narzędzia o uniwersalnym zastosowaniu.

Ktoś zarzucił mi nawet że jestem egoistą który twierdzi, że ludzie pracujący w dużych organizacjach nie zasługują na Agile. Hmm, niektórzy ludzie, w niektórych organizacjach – tacy, którzy nie chcą niczego zmienić, albo boją się zmian być może nie tyle nie zasługują na Agile  co Agile mógłby im zaszkodzić więc to raczej nie jest dla nich.

Powyższe nie oznacza, że nigdy z problemem skalowania się nie mierzyłem i nie mam w tym żadnego doświadczenia. Osobiście do tematu skalowania zawsze podchodziłem na kilku płaszczyznach i za każdym razem, w każdej organizacji wygląda to zupełnie inaczej, niemniej jednak często powtarzają się pewne tematy.

Pierwsze zadawane przeze mnie pytanie tyczy się tego dlaczego dana organizacja jest na tyle duża, że potrzebuje jakiejś metody skalowania?

To pytanie może wydawać się proste, ale w większości przypadków próba zastanowienia się nad odpowiedzią prowadzi do źródeł wielu innych problemów, których rozwiązanie pozwala uniknąć potrzeby zastosowania metod skalowania. Czasem okazuje się, że wystarczy organizację podzielić na mniejsze, bardziej niezależne komórki skupione wokół poszczególnych produktów lub komponentów i okazuje się, że niczego nie trzeba skalować. Czasem dochodzimy do wniosku, że problemy, które chcemy rozwiązać są gdzieś indziej niż adresują to różne metody skalowania i wystarczy właśnie tam skupić swoją energię. To co niewątpliwie jest potrzebne w każdej organizacji bez względu na wielkość to określona metoda wspomagająca proces Continuous Improvements.

Drugie pytanie dotyczy tego co rozumiemy przez skalowanie?

Skalować możemy organizację zapewniając odpowiedni framework wymiany wiedzy oraz zapewniania transparentności i możliwości ciągłej inspekcji i adaptacji na wielu (wszystkich?) poziomach organizacji. Każda organizacja jest inna i narzucanie tutaj odgórnie struktury (tak jak próbuje to zrobić SAFe) jest raczej wątpliwie skuteczne. Czasem oczywiście (zwłaszcza gdy mamy do czynienia z chaotyczną organizacją o wątpliwej strukturze) narzucenie struktury jest świetnym posunięciem – tutaj SAFE z pewnością się sprawdza (przyznam, że jako konsultant poleciłem kilka razy SAFe właśnie w takich przypadkach).

Skalowanie to również skalowanie produktu. Jeśli mamy do czynienia z monolitycznym produktem, z dużym legacy i długiem technicznym to wartość wdrożenia jakiejkolwiek metody skalowania będzie raczej znikoma. Często do tego problemu docieramy zadając pierwsze pytanie powyżej – to taka architektura często jest przyczyną nadmiernego wzrostu organizacji.

Trzecie pytanie to w zasadzie obserwacja tego jak w tej chwili wygląda organizacja i w jaki sposób podejmowane są decyzje?

Wizualizacja tego procesu często jest już wystarczającym krokiem w kierunku poprawy i usprawnień. Value Stream Mapping i zaangażowanie odpowiednich osób w dyskusję może bardzo pomóc.

Następnie jest czas na pytania o to czy istnieje coś takiego jak wizja organizacji i wizja produktu? Jak ta wizja, misja i deklarowane wartości są reprezentowane przez realne, codzienne działania? Czy wizja jest klarowana i transparentna? Czy wszyscy w organizacji są jej świadomi? Czy mają na nią wpływ? Czy ludzie w organizacji utożsamiają się z wartościami deklarowanymi przez organizację.

Mając jasną wizję produktu możemy ją dekomponować na pracę dla poszczególnych zespołów produktowych. Mając jasną wizję organizacji możemy ją dekomponować i uskuteczniać w pętli Inspect & Adapt na poziomie każdego zespołu i całej organizacji.

 

W powyższy (opis mocno uproszczony) sposób staram się pracować z organizacjami już od dłuższego czasu dlatego też wczorajszego wieczoru zainteresowała mnie prezentacja mówiąca o „nowym” podejściu do skalowania: Scrum at Scale proponowana przez Scrum Inc. Tak jak w tytule jest to niewątpliwie światełko w tunelu dla osób poszukujących odpowiedzi na pytanie jak skalować organizację. Czy to światełko okaże się oczekiwanym rozwiązaniem wielu problemów czy może raczej nadjeżdżającym pociągiem? Myślę, że wszystko zależy od tego jak to dalej się potoczy i w którym kierunku popchną tą „metodę*” jej „twórcy**”. Na szczęście nie  ma (jeszcze) zmyślnej ścieżki certyfikacji co moim zdaniem daje nadzieję, na to, że ktoś faktycznie chce pomagać organizacjom a nie tylko i wyłącznie trzepać kasę kopiując model szkoleń i certyfikacji CSM i PSM z przed lat (za pierwszym razem to miało sens i wnosiło wartość – teraz certyfikatów na rynku zdaje się być kilkadziesiąt razy więcej niż możliwych do zastosowania w praktyce metod).

Z pewnością w najbliższym czasie będę chciał się bliżej przyjrzeć tej metodzie. Być może za jakiś czas przeczytacie o tym jak bardzo się myliłem i to tylko kolejny marketingowy BS, który ktoś próbuje wcisnąć ludziom z problemami zamiast pomóc im naprawdę te problemy zdiagnozować i rozwiązać…

 

*Scum at Scale cieżko jest mi nazwać metodą – to raczej zbiór kilku celów czy problemów które każda organizacja powinna zastosować. Ciekawą ideą jest wspomniana modułowość  proponowanego rozwiązania.

**Nie jest to też nic nowego bo podstawy są zbliżone chociażby do tego co można było znaleźć w początkowych wersjach SAFe, na pierwszy rzut oka widać też, że twórcy dużo inspiracji czerpią od takich autorów i myślicieli ze świata Lean i Agile jak chociażby Mary i Tom Poppendieck (Lean Software Development) czy Tom Gilb (Evo Method)

1 komentarz więcej...

Ilu Agile Coachów potrzeba by wymienić żarówkę? – Agile Coach Camp PL 2014

opublikowany przez 20, Paź, 2014, w kategoriach Agile, ALE, Coaching, Kanban, Scrum

20141017_171017

W ten weekend miało miejsce niezwykłe jak naszą krajową społeczność wydarzenie – Agile Coach Camp. Blisko 60 mniej lub bardziej doświadczonych Agile Coachów, Scrum Masterów, Product Ownerów i Developerów przyjechało do Srebrnej Góry by przez 2 dni wymieniać się swoją wiedzą i doświadczeniami.

Nie było agendy, nie było prelegentów, nie było nawet ŻADNYCH slajdów! 60 osób z potężnym bagażem doświadczeń i wiedzy pracujących razem nad rozwiązaniem wielu problemów i uspójnieniem wiedzy. Duch ALE  był tam razem z nami, nowe znajomości, nowi przyjaciele, nowe perspektywy.

Pierwszy Agile Coach Camp odbył się pod hasłem „Prepare to be suprised”. Co zatem zaskoczyło mnie najbardziej?

Przede wszystkim zaskoczyłem się tym, jak wielu świetnych, doświadczonych Agile Coachów z Polski nie miałem okazji wcześniej poznać. Zaskoczył mnie niezwykle wysoki poziom wiedzy uczestników. Przyznam szczerze, że nie miałem oczekiwań przed tym wydarzeniem a mimo to bardzo wiele z niego wyciągnąłem.

To niesamowite jak nasza Agileowa społeczność wyewoluowała i dorosła na przestrzeni ostatnich kilku lat. Podczas podsumowania ACCPL nawiązałem do tego, że jeszcze 6-7 lat temu, kiedy dopiero zaczynała się moja przygoda z Agila nikt nie przypuszczał, że dojdziemy tak daleko. Wtedy ze świecą szukać można było tych którzy o Agile w ogóle słyszeli, a źródeł wiedzy na ten temat było bardzo niewiele. Dzisiaj nie tylko możemy wymieniać się wiedzą ogólnie dostępną ale nasze doświadczenia pozwalają nam na wspólne opracowywanie coraz to lepszych metod pracy. Równie ważne było to, że pomimo obecności wielu trenerów i konsultantów (ja też się w to wpisuje) udało się nam chyba uniknąć wszelkich prób indoktrynacji nowymi „modnymi” metodykami i frameworkami. Chyba nawet Scrum przestał już być „ideologią” i stał się (całkiem niezłym) narzędziem – jednym z wielu, które w dzisiejszych czasach wręcz wypada poznać i spróbować. 20141017_204216

Agile nie jest już niszowym, mało znanym i niesprawdzonym podejście do wytwarzania produktów. Dzisiaj coraz więcej osób wierzy (w oparciu o swoje doświadczenia), że Agile jest w tej chwili w większości przypadków najlepszą z dostępnych opcji.

Super było usłyszeć historie wielu udanych transformacji Agile prosto z naszego podwórka! Tak! W Polsce jest wiele firm, małych i dużych, które dzięki wielkim wysiłkom i pasji wielu ludzi udało się zmienić.

Poza wiedzą było też dużo zabawy – wieczorne dyskusje przy piwie, śpiewy z gitarą, karaoke z laptopa, nocne włóczenie się po lochach w twierdzy, coachowanie pejczem (ci co nie byli niech nawet nie próbują się domyślać ;-)), gry i zabawy typu jakiej wymówki używa zespół gdy nie dowiezie? („Bo pies pożarł mi backlog” okazuje się być niezwykle częste)… Nie mogę doczekać się kolejnej edycji oraz z chęcią pomogę przy organizacji!

Tych co byli serdecznie pozdrawiam, a tych co nie byli serdecznie zapraszam na kolejne edycje. Miejmy nadzieję, że częściej niż raz do roku – bo Agile to w końcu krótkie iteracje i szybki feedback, nie?

To ilu Agile Coachów potrzeba by wymienić żarówkę???

5 komentarzy więcej...

Perfection Game – czyli prosty, wartościowy feedback

opublikowany przez 09, Wrz, 2014, w kategoriach Agile, Coaching, Scrum, Zarządzanie

„Perfection Game” to prosta metoda pomocna w sytuacjach gdy potrzebujemy zebrać feedback od innych osób, lub gdy sami chcemy komuś dać feedback. Jak sama nazwa wskazuje metoda ta może być użyteczna zwłaszcza gdy w jakimś obszarze chcemy dojść do perfekcji.

Formuła

Formuła Perfection Game jest stosunkowo prosta – polega na odpowiedzi na trzy pytania:

  • Oceniam <ten produkt, usługę, wydarzenie, spotkanie> na … w skali od 1-10
  • To co mi się podobało to …
  • Aby ocenić <ten produkt, usługę, wydarzenie, spotkanie, etc> na 10 zmieniłbym …

(W miejscu … wstawiamy swoje odpowiedzi).

Istotne jest to aby zwłaszcza w przypadku trzeciego pytania formułować wypowiedź z perspektywy pierwszej osoby – co JA bym zmienił. Nawet w formie: Gdybym to ja prowadził to spotkanie to aby dostać lepszą ocenę zrobił bym…

Żadne pytanie nie może pozostać bez odpowiedzi.

Jak to działa?

Odpowiadając na pierwsze pytanie dajemy informację jak w naszej subiektywnej ocenie wypadł przedmiot oceny. Skala od 1-10 gdzie 1o oznacza, że to co ocenialiśmy jest w naszej subiektywnej ocenie niemal perfekcyjne i nie wymaga większych zmian – a przynajmniej spełniło nasze oczekiwania i nie chcemy żeby cokolwiek ulepszać.

Drugie pytanie wymusza na oceniającym/dającym feedback wskazanie pozytywnych obszarów. Dzięki temu zarówno z perspektywy dającego feedback jak i otrzymującego feedback całościowa ocena nie ma tylko i wyłącznie wydźwięku negatywnego. Nawet oceniający niejako zmuszając się do znalezienia pozytywnych aspektów w przedmiocie oceny delikatnie zmienia swoje nastawienie i pozwala spojrzeć na problem z innych perspektyw. Dodatkowo takie podejście może mieć też pozytywny wpływ na kreatywne poszukiwanie punktów do poprawy/ulepszeń.

Trzecie pytanie zwłaszcza, gdy odpowiadamy na nie z perspektywy pierwszej osoby – co ja bym zmienił/ulepszył daje to co w feedbacku jest najważniejsze – konstruktywną krytykę. Nie oceniamy negatywnie tego co jest ale konstruktywnie zastanawiamy się nad tym co można by ulepszyć. Dzięki temu nawet gdy oceniamy coś co jest „beznadziejne” w naszej ocenie osoba, która będzie czytała nasz feedback będzie w stanie wyciągnąć konstruktywne wnioski i zastanowić się nad tym co konkretnie poprawić.

Zastosowanie

„Perfection Game” można zastosować w wielu różnych sytuacjach.

Retrospekcja

Możemy skorzystać z „Perfection Game” na przykład do oceny tego w jaki sposób pracowało nam się w ostatnim Sprincie. Dzięki takiemu feedbackowi od razu mamy wygenerowanych sporo ciekawych pomysłów na temat tego, co można by ulepszyć i zrobić lepiej.

Rozmowa rekrutacyjna

Z powodzeniem stosujemy ten format podczas rozmów rekrutacyjnych z naszymi pracownikami. Bez względu na to czy kogoś zatrudnimy czy nie staramy się dać konstruktywny feedback by dana osoba mogła popracować nad swoimi umiejętnościami i wiedzą. Można też korzystać z tej formy w ramach regularnych rozmów z pracownikami/kolegami z zespołu na temat ich postępów w pracy.

Ocena produktu/Inkrementu po Sprincie

Możemy użyć tej formuły do oceny produktu naszej pracy. Możemy też  w ten sposób dać komuś feedback na temat pomysłów dotyczących dalszej pracy nad produktami.

Moja historia z Perfection Game w tle

Ten sposób dawania feedbacku znałem już od dłuższego czasu niemniej jednak prawdziwą moc „Perfection Game” poczułem w momencie gdy sam zacząłem dawać taki feedback podczas oceny zgłoszeń prezentacji na ALE2014. Początkowo nie wychodziło mi to zbyt dobrze i odpowiedzi były raczej koślawe, ale z czasem, gdy położyłem większy nacisk na format i na to by feedback był pisany z perspektywy pierwszej osoby myślę, że moje oceny były wartościowe. Prawdę mówiąc chyba wszyscy prezenterzy, którzy otrzymali nasz feedback w tej formule i na jego podstawie ulepszyli swoje prezentacje zostali zaakceptowani w drugiej rundzie ocen prezentacji (nawet, gdy za drugim razem prezentacje oceniał ktoś inny niż poprzednio) – to chyba faktycznie pokazuje wartość tej metody. Przyznam, że w kilku przypadkach musiałem spędzić naprawdę sporo czasu nad przemyślenie konstruktywnego feedbacku Znacznie łatwiej jest po prostu krytykować i mówić o tym co się nie podoba niż wymyślić co konkretnie powinno zostać poprawione i jak tak by przestało się mi to nie podobać.

Perfection Game staram się używać też często podczas szkoleń i agile coachingu aby ocenić to jak wartościowy dla uczestników był czas spędzony razem ze mną. Wielokrotnie dzięki temu podejściu udało mi się zebrać bardzo wartościowy feedback i konstruktywne uwagi, które pozwoliły znacznie ulepszyć moje usługi (czasem bardzo ogólnie, a czasem w kontekście danego klienta/zespołu).

 

2 komentarze więcej...

5 poziomów wymagań i specyfikacji

opublikowany przez 16, Lip, 2014, w kategoriach Agile, BDD, Scrum, Specyfication By Example, User Stories

Ten wpis jest (powiedzmy, że) kontynuacją wpisu „Wymagania != Specyfikacja

Piramida wymagań

Jeśli mówimy o wymaganiach i specyfikacji i wprowadziliśmy już rozróżnienie tego czym są wymagania i czym jest specyfikacja, oraz że istnieje specyfikacja funkcjonalna oraz specyfikacja techniczna to teraz możemy swobodnie przemyśleć to jak zkategoryzować poszczególne poziomy wymagań i specyfikacji.

Jak w tytule pozwoliłem sobie na wyróżnienie pięciu poziomów wymagań i specyfikacji, które można by przedstawić w postaci na przykład piramidy (Wygląda na to, że ludzie w IT lubią piramidy, nie wiem dlaczego…).

Na szczycie piramidy mamy pierwszy poziom: Jaki jest cel naszego przedsięwzięcia? 

Odpowiadając na pytanie po co nasza organizacja istnieje i po co tworzy produkty najprawdopodobniej dojdziemy do odpowiedzi, że oczywiście robi to dla pieniędzy. Tak, pieniądze i ich zarabianie są celem niemalże każdego biznesu (bezpośrednio lub pośrednio – np. zyski wizerunkowe, które później się monetaryzują). Warto o tym pamiętać bez względu na to gdzie w strukturach organizacji się znajdujemy bez względu na to czy tworzymy produkty dla naszej własnej organizacji czy jesteśmy jedynie dostawcami usług dla klientów/organizacji zewnętrznych. Aby osiągnąć cel (zarabianie pieniędzy) organizacja wytwarza pewne produkty – w IT mamy obecnie do czynienia raczej nie tyle z produktami w sensie wytwarzaniem pewnych dóbr materialnych co tworzeniem produktów będących narzędziami do świadczenia usług. Tworzymy produkty, które świadczą pewne usługi dla użytkowników końcowych za które są oni gotowi zapłacić.

Drugim poziomem jest odpowiedź na pytania: Kto jest interesariuszem naszego produktu i jakie problemy próbuje rozwiazać? 

Kto jest naszym odbiorcą i jest gotów zapłacić za „rozwiązanie” swoich problemów, spełnienie potrzeb? Jakich problemów i potrzeb? Warto pamiętać, że dla interesariuszy celem nadrzędnym też są raczej pieniądze więc myśląc nad produktami powinniśmy brać pod uwagę to w jaki sposób my możemy zarobić na tym, że zarabiają (oszczędzają) nasi klienci?

Mając problemy do rozwiązania i grupę odbiorców docelowych naszych rozwiązań mamy właściwie wysoko-poziomową definicję produktu.

Trzecie poziom to zdefiniowanie tego co będzie robił, czy też jakie funkcjonalności będzie zawierał nasz produkt by rozwiązać powyższe problemy interesariuszy?

Powyższe trzy poziomy to wymagania – co nasz produkt będzie robił by rozwiązać konkretne problemy, konkretnych interesariuszy. Na tym poziomie mamy zdefiniowane na pewnym poziomie abstrakcji ficzery naszego produktu. Możemy przystąpić do badania rynku i sprawdzania naszej hipotezy, że odbiorcy faktycznie potrzebują rozwiązać te problemy i są gotowi za nie zapłacić.

Czwarty poziom to  Specyfikacja Funkcjonalna – czyli odpowiedź na pytania w jaki sposób nasz produkt rozwiązuje problemy interesariuszy, jakie konkretne funkcjonalności dostarcza? 

Tutaj specyfikujemy jakie konkretnie funkcje naszego produktu użytkownicy będą mieli do dyspozycji. Możemy zbadać czy dane funkcjonalności są faktycznie przez użytkowników używane – czy są im potrzebne?

Piąty poziom to Specyfikacja Techniczna – w jaki sposób działają poszczególne funkcjonalności oraz jak są zaimplementowane?

Czwarty i piąty poziom to obszary w których możemy (a nawet powinniśmy) pokusić się o wykonywanie testów A/B i ciągłe usprawnianie dostarczanych przez nas funkcjonalności, tak by jeszcze lepiej spełniały oczekiwania użytkowników.

Na zakończenie jedna ważna uwaga: Nawet jeśli świetnie zdefiniujemy założenia co do wymagań i specyfikacji w naszym produkcie oraz poprawnie to zaimplementujemy to wcale nie znaczy, że nie mogą się one zmienić – to rynek zwaliduje czy mieliśmy rację. Dlatego też tak istotne jest testowanie naszych hipotez oraz wydawanie nowych wersji produktów – eksperymentowanie jak najczęściej, wprowadzając minimalne inkrementalne zmiany.

-==C.D.N==-

5 komentarzy więcej...

Wymagania != Specyfikacja

opublikowany przez 07, Maj, 2014, w kategoriach Agile, Scrum

„Wymagania” to nie to samo co „specyfikacja funkcjonalna/techniczna”! Wiem, że to nie wydaje się być oczywiste, ale gdyby wszyscy zdawali sobie z tego sprawę to mogli byśmy uniknąć wielu, tak często powtarzających się w IT problemów. Spróbujmy więc to jakoś zdefiniować.

Wymagania (ang. Requirements) – wymagania wobec tworzonej aplikacji to jest to, co ktoś od niej wymaga. Pisząc ktoś mam na myśli kogoś, kto ma jakiś interes w tym, by dane wymaganie zostało zrealizowane – ten ktoś jest więc Interesariuszem (ang. Stakeholder). Interesariusz wymaga od aplikacji, by realizowała ona lub pomagała w realizacji jakichś konkretnych celów. Przeważnie chodzi o cele biznesowe, ale mogą to też być też kwestie związane na przykład z wymogami prawnymi czy zależnościami od innych systemów. Ponad Interesariuszami (przeważnie jest ich wielu) jest jeszcze ogólny cel biznesowy naszej organizacji jakim przeważnie jest generowanie zysków – tak, chodzi oczywiście o pieniądze (choć nie zawsze wprost). Interesariusze wyrażają swoje potrzeby właśnie w postaci wymagań, a więc wymagania opisują to jaki cel ma zostać osiągnięty – czyli to CO aplikacja ma dostarczać. To czego wymagania nie powinny dotyczyć to sposób, w jaki ten cel musi zostać osiągnięty (można podać oczywiście w ramach wymagań jakieś przykłady różnych rozwiązań niemniej jednak nie jest to konieczne).

Większość problemów w wytwarzaniu współczesnych produktów IT bierze się właśnie stąd, że za definiowanie tego jak powinny wyglądać rozwiązania IT biorą się ludzie, którzy nie potrafią tych rozwiązań zaimplementować. Oczywiście robią to nie pytając o zdanie tych, którzy to potrafią. W ten sposób bardzo często powstaje właśnie specyfikacja funkcjonalna – czyli dokumentacja opisująca to JAK system ma spełniać wymagania Interesariuszy. Dokumentacja ta następnie (no może nie tak od razu) jest zazwyczaj przekazywana tym drugim (developerom), którzy implementują te rozwiązania na tyle na ile je rozumieją.

Warto zastanowić się nad tym po co tworzona jest zazwyczaj specyfikacja funkcjonalna? Przeważnie tworzy się ją po to, by za jakiś czas pamiętać o tym co nasz system ma robić i jak ma to robić? Kluczowe jest tutaj „…za jakiś [znacznie dłuższy] czas…”.

Potrzeba istnienia specyfikacji funkcjonalnej sprowadza się do minimum (w zasadzie zależy to tylko od tego, czy z jakiegoś rozsądnego powodu chcemy mieć na przyszłość dokumentację tego, co zostało zaimplementowane), gdy mamy do czynienia z inkrementalnym i iteracyjnym wytwarzaniem oprogramowania jak na przykład w Scrum. Planując pracę na najbliższe dwa tygodnie nie potrzebujemy z góry szczegółowo zapisywać tego jak zamierzamy zaimplementować rozwiązania postawionych przed nami problemów. Zgodnie z zasadą Just In Time – pracujemy w danym momencie nad tym co jest w danym momencie najważniejsze. Przed rozpoczęciem Sprintu przeważnie nie wiemy jak zaimplementujemy dane wymaganie.

Cały ten Agile dotyczy właśnie tego by zbliżyć tych ostatnich w łańcuchu – developerów, do tych z samego początku – Interesariuszy. Chodzi o to, by to właśnie ludzie, którzy mają implementować rozwiązania mogli podejmować decyzje, co do tego jak dane wymaganie zostanie zrealizowane.

To plus rozróżnienie wymagań od specyfikacji to fundamentalne podstawy dobrego zrozumienia metod takich jak Scrum czy BDD. Niestety wydaje mi się, że wiele osób zgubiło to gdzieś po drodze i teraz na przykład piszą User Stories tak, jak by były dokumentacją funkcjonalną. Wielokrotnie spotykałem się z (oczywiście bzdurną) opinią, że User Stories mają być odpowiednikiem dokumentacji funkcjonalnej…

Co w takim razie z analitykami? Nic… Analitycy są potrzebni – bardzo potrzebni! Pomagają zrozumieć domenę biznesową developerom, a także często samym Interesariuszom. Pomagają znaleźć optymalne rozwiązania problemów wyrażonych w postaci wymagań.

Jeśli natomiast Twoja praca sprowadza się głównie do pisania specyfikacji funkcjonalnej, którą później wysyłasz do developerów to przykro mi, ale jest spora szansa, że jesteś dokumentalistą a nie analitykiem (nawet pomimo swoich wybitnych umiejętności w tym zakresie). Analizując problem i poszukując jego rozwiązań należy bowiem brać pod uwagę różne aspekty – a już na pewno kwestie biznesowe oraz możliwości implementacyjne. Dobry analityk będący częścią wskroś-funkcjonalnego zespołu developerskiego wnosi niesamowitą wartość – jeśli tylko rozróżniamy wymagania od specyfikacji funkcjonalnej (patrz powyżej).

Specyfikacja funkcjonalna – czy inna dokumentacja tego typu stanowi zasadniczy koszt wytwarzania oprogramowania i naprawdę warto jest się zastanowić czy mamy doby powód by koszt ten ponosić. Zauważcie, że nie neguję istnienia takiej dokumentacji zawsze i wszędzie – jest z pewnością wiele przypadków, w których jej istnienie jest konieczne! Proszę Was tylko o to, byście zadali sobie pytanie z jakiego powodu taka dokumentacja jest konieczna w Waszym przypadku, oraz zastanowili się, czy odpowiedź na nie ma sens…

–== C. D. N. ==–

4 komentarze więcej...