blog.testowka.pl

Syzyfowe Prace – Agile Transformacje

opublikowany przez 14, Kwi, 2015, kategorie: Agile, Coaching, Lean

3195818623_6757843874_o

„(…) We can see that the insanity – and tragedy – of agile – lies in the Sisyphean task of trying to build effective teams – and ways of working- inside ineffective organisations.”

Bob Marshal „What Is Agile Software Development?

Powyższy cytat bardzo dobrze obrazuje to co od kilku lat zauważam podczas mojej pracy jako Agile Coach. Głównym problemem moich klientów jest przeważnie to, że konieczne zmiany wymagane do usunięcia wielu dysfunkcji powinny zachodzić na poziomie całej organizacji a tymczasem wszyscy próbują optymalizować na poziomie poszczególnych zespołów.

Brak spójnej wizji, jasno określonych wartości, misji lub też misja i wartości jako marketingowy chwyt całkowicie sprzeczne z tym jak naprawdę działa organizacja to chleb powszedni wielu firm.

Krytyka Boba Marshal’a w artykule z którego pochodzi powyższy cytat – mniej lub bardziej przesadzona jest jednak w dużej mierze trafna – większość Agile’owych technik i metod skupia się głównie na pracy zespołu (zespołów) wokół produktu – ponad tym wszystkim jest jeszcze organizacja wewnątrz której dany zespół egzystuje i wytwarza produkty.

Stąd też moje zainteresowanie Lean Software Development i System Thinking – w tych dwóch podejściach pracujemy z całymi organizacjami i jednocześnie z zespołami. Praktycznie za każdym razem pracując z nowym zespołem i organizacją zaczynam od zwizualizowania strumienia wartości (Value Stream Mapping). Za pierwszym razem robimy to z perspektywy zespołu a następnie staramy się tą wizję zweryfikować i rozszerzyć o to jak faktycznie wygląda przepływ wartości w organizacji. Gdzie zaczyna się wartość – skąd biorą się wymagania? Co dzieje się z wymaganiami zanim trafią do developmentu? Co dzieje się z nimi później – w jaki sposób są weryfikowane? W których miejscach pojawiają się przestoje produkcyjne – gdzie wymaganie czeka, czyli gdzie generowane są straty? Gdzie są wąskie gardła (w skali całej organizacji raczej rzadko w zespole developerskim)? To tylko kilka z pytań które mogą być przydatne podczas stawiania takiej diagnozy.

Źródła wielu problemów widocznych i często powodujących brak motywacji i frustrację w zespołach wynikają z dysfunkcji, które mają miejsce poza zespołami. Niezliczoną ilość razy słyszałem na warsztatach, szkoleniach i przede wszystkim podczas sesji coachingowych jak wszyscy narzekają na to jak jest źle i nie da się nic z tym zrobić. Oczywiście w wielu takich przypadkach wystarcza zmiana postawy członków zespołu, czasem właśnie po to, by wywrzeć odpowiednia presję na organizację i wypracować pewne zmiany.  Niemniej jednak jest też masa sytuacji w których narzekania na poziomie zespołów i związana z nimi niemoc poprawienia czegokolwiek są przynajmniej częściowo uzasadnione. Bez konkretnych zmian na różnych poziomach organizacji i współpracy z ludźmi, którzy na kształt organizacji mają największy wpływ prędzej czy później możemy natrafić na barierę nie do pokonania. Zawsze można oczywiście zmienić organizację (o ile świat byłby lepszy, gdyby ludzie pracowali w firmach w których CHCĄ pracować), ale to raczej utopia i o ile realna w poszczególnych przypadkach, o tyle niemożliwa do spełnienia przy większej skali.

Patrząc w przeszłość na projekty transformacji agile, które miałem okazję wspierać w ten czy inny sposób jasno widać, ze najlepsze efekty udało się nam osiągnąć tam, gdzie pracowaliśmy z całą organizacją. Począwszy od prezesa/zarządu, poprzez managerów wysokiego i średniego szczebla i skończywszy na developerach (i nie tylko – istotne np. jest też zaangażowanie działów produktowych, marketingowych i przede wszystkim HR).

Tam, gdzie miałem okazję pracować jedynie z pojedynczymi zespołami zmiany zaszły stosunkowo niewielkie. Przeważnie udawało się zoptymalizować pracę zespołu ale potencjał zwiększenia efektywności był znacznie większy – wystarczyłoby tylko wprowadzić pewne usprawnienia na poziomie organizacji, na które nie było zgody (a raczej możliwości porozmawiania z kimkolwiek, kto taką zgodę mógłby wyrazić).

A czy Twoja organizacja (a nie tylko zespół) jest gotowa na zmiany?

1 komentarz więcej...

Trzech developerów – czyli krótka historia z morałem

opublikowany przez 09, Kwi, 2015, kategorie: Agile, Automatyzacja, TDD, Testowanie, XP

5597863793_60f320a45d_o

Trzech programistów zostało zapytanych o to jak długo zajmie im przejście przez pole do domu?

Junior Developer popatrzył na dystans dzielący go od domu i powiedział: „Nie wygląda żeby było daleko  – zajmie mi to 10 minut”. 

Senior Developer popatrzył uważnie na pole i powiedział: „Powinienem być w stanie dotrzeć tam w ciągu dnia”. Oczywiście zdziwiło to Junior Developera. 

Ninja Developer popatrzył na pole i powiedział: „Wygląda na dziesięć minut drogi, ale myślę, że piętnaście minut będzie odpowiednią estymatą”

Junior Developer wystartował ale po kilku krokach wybuchła pierwsza mina zakopana na polu co sprawiło, że Junior Developer musiał zboczyć z najprostszej drogi. Po tym jak wielokrotnie musiał zawracać wysadzając po drodze kolejne miny, po dwóch dniach udało mu się dotrzeć do celu. Oczywiście nie obyło się bez ran.

Senior Developer od razu rozpoczął swoją podróż na czworaka uważnie sprawdzając każdy metr drogi i przemieszczając się tylko tam gdzie jest bezpiecznie. Oczwiście kilka razy natknął się na minę ale zdążył dotrzeć do celu w trochę ponad jeden dzień. 

Ninja Developer wystartował i spokojnie przeszedł przez pole do celu. Dotarł tam po dziesięciu minutach. 

Dwaj pozostali programiści zszokowani zapytali: „Jak udało Ci się to osiągnąć?”, „Jak przeszedłeś przez pole nie wysadzając żadnej miny?”

„To było łatwe” odpowiedział Ninja Developer – „Po prostu nie zakopałem tam tych min wcześniej”.

[znalezione na Quorze  i przetłumaczone na nasze]

Konkluzja: Emergent Architecture – fajna sprawa, ale warto czasem pamiętać o reużywalności i możliwościach rozwoju naszego kodu. Warto też mieć testy automatyczne, które przez takie pole minowe nas spokojnie, może trochę powoli, ale jednak bezpiecznie przeprowadzą.

 

 

Dodaj komentarz więcej...

Jeśli nie wiadomo o co chodzi…

opublikowany przez 10, Lut, 2015, kategorie: Praca, Programowanie, Testowanie, Zarządzanie

…to chodzi o pieniądze…

Konkretnie o stawki w widełkach płacowych w ogłoszeniach o pracę. Już któryś raz spotkałem się z opinią, że ogłoszenia o pracę dla developerów/testerów/etc. powinny zawierać widełki płacowe. Oczywiście się z tym zgadzam. Ale ostatnio na grupie poświęconej testowaniu oprogramowania na Facebooku pojawił się też pomysł by widełki te nie były zbyt szerokie. Z perspektywy (dosyć świeżego) pracodawcy to mnie to troszeczkę ukłuło.

Co jeśli ktoś płaci ludziom faktycznie pomiędzy 2k a 10k PLN i to faktycznie zależy od umiejętności danej osoby? W Pragmatic Coders szukamy zarówno doświadczonych wymiataczy jak i osób ambitnych lecz jeszcze z niewielkim doświadczeniem, które maja duży potencjał. Ponadto zdarza się, że sporo osób z najwyższymi oczekiwaniami finansowymi (pytamy o to zanim zaprosimy kogoś na rozmowę) wypada dużo słabiej na rozmowach niż osoby z oczekiwaniami z pierwszej połowy widełek.
 
Sami zatrudniamy ludzi i stawki są naprawdę różne (może nie aż tak rozjechane, ale jednak) i faktycznie jest to w dużej mierze zależne od ich umiejętności. A raczej od tego jak dobrze wypadną na rozmowie/podczas rozwiązywania zadań rekrutacyjnych.
Jeśli chciałbym wrzucić widełki typu 8-10k to musiał bym podziękować większości kandydatów, których zatrudniliśmy bo najzwyczajniej ich umiejętności nie były dla nas tyle warte. Nie wiem też ile osób doszło by do wniosku, że są po prostu „za słabe” na takie pieniądze i by do nas nie napisało. Niemniej jednak dzięki temu, że nasze widełki są szersze pracujemy teraz z ludźmi z dużym potencjałem, których pensje odpowiadają ich umiejętnościom.
 
To co proponuję wszystkim malkontentom, którzy narzekają na brak czy niedokładność widełek to aby podawali swoje oczekiwania finansowe w przesyłanych CV. Wystarczy zrobić tam dopisek, żeby pracodawcy nie zawracali nam głowy jeśli uważają, że na podstawie CV/profilu na linkedIn/20 minut rozmowy przez telefon nasze umiejętności nie są dla nich tyle warte, lub jeśli w ogóle nie są w stanie tyle zapłacić komuś na tym stanowisku. Z mojego doświadczenia – takie coś w zasadzie eliminowało temat pieniędzy podczas dalszych rozmów lub było to dogadywane z różnym skutkiem na samym początku komunikacji. I pisze to zarówno z perspektywy kandydata jak i pracodawcy. 
 
Oczywiście moja propozycja nie wyklucza potrzeby widełek w ogłoszeniach. To tylko pewna propozycja rozszerzenia netykiety dla wspólnego dobra pracodawców i kandydatów. 
 
Z trzeciej strony jeśli dla kogoś jedynym powodem do tego by z nami współpracować miała by być kasa, to nie jestem przekonany czy wszyscy będziemy docelowo z takiego układu zadowoleni.
Osobiście gdy, kiedyś szukałem pracy to uważałem, że podanie moich oczekiwań płacowych na początku kontaktów (w CV, pierwszym mailu, przez telefon) to po prostu pragmatyczna oszczędność czasu osoby rekrutujące ale także przede wszystkim MOJEGO… Także szczerze polecam taki sposób komunikacji – także z nami gdybyście programowaniem w Pythonie byli zainteresowani.

4 komentarze więcej...

Światełko w tunelu dla Skalowania Agile

opublikowany przez 17, Gru, 2014, kategorie: 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, kategorie: 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, kategorie: 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).

 

1 komentarz więcej...

Ludzie zawsze podejmują najlepsze z możliwych decyzji – a managerowie?

opublikowany przez 22, Lip, 2014, kategorie: Agile, Zarządzanie

decisionPisałem blisko rok temu o postawie coacha i o kilku faktach na temat nas samych którymi coach powinien się kierować. Jedną z przytoczonych przeze mnie prawd było stwierdzenie, że „Ludzie zawsze podejmują najlepszą z możliwych decyzji w oparciu o informacje, którymi dysponują”.

Tak, zdaję sobie sprawę z tego jak bardzo kontrowersyjne jest powyższe stwierdzenie. Wielokrotnie sam też miałem wątpliwości co do jego poprawności zwłaszcza obserwując osoby decyzyjne w firmach zajmujących się różnymi rzeczami (nie tylko IT).

Managerów można podzielić na tych dobrych i tych złych – na tych, którzy w naszej ocenie podejmują dobre decyzje i na tych, których decyzje nie są najlepsze (z naszej perspektywy). Często też upływ czasu pokazuje, że nasza perspektywa i obserwacje były poprawne i manager się mylił od samego początku.

Ale jak to? Przecież podejmował najlepszą z możliwych decyzji w oparciu o informacje które posiadał… No właśnie, pytanie brzmi czy posiadał wszystkie informacje jakie mógł zdobyć w danym momencie? Czy zrobił wszystko by te informacje pozyskać? Czy zadał odpowiednie pytania odpowiednim osobom? Czy może po prostu podjął decyzję na podstawie tego co wiedział w danym momencie?

Miałem przyjemność w swojej karierze pracować z wieloma managerami/osobami decyzyjnymi – zarówno jako pracownik, współpracownik jak i doradca czy agile coach. W mojej ocenie dobrego managera charakteryzuje właśnie ta dociekliwość i umiejętność pozyskania jak największej ilości informacji potrzebnych do podejmowania decyzji. Jednocześnie kluczowe jest podejmowanie decyzji wystarczająco szybko by nie powodować niepotrzebnych opóźnień.

Dlatego też radzę wszystkim osobom decyzyjnym, a przecież wszyscy podejmujemy na co dzień – zarówno w pracy jak i w życiu osobistym różne decyzje, by zanim powiedzą ostatnie słowo i przejdą do działania upewnili się, że informacje, które posiadają są względnie kompletne i prawdziwe.

4 komentarze więcej...