blog.testowka.pl

Coaching

Syzyfowe Prace – Agile Transformacje

opublikowany przez 14, Kwi, 2015, w kategoriach 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...

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...

Podsumowanie Quality Excites 2014

opublikowany przez 02, Cze, 2014, w kategoriach Coaching, Jakość, Konferencje, Testowanie

qe

W sobotę miała miejsce już trzecia edycja darmowej konferencji Quality Excites 2014 w Gliwicach, organizowanej przez firmę Future Processing. Uczestniczyłem w tym wydarzeniu jako prelegent po raz trzecie – dzięki temu miałem okazję od samego początku przyglądać się temu jak rozwija się samo wydarzenie jak i firma je organizująca.

Może zacznijmy od organizatorów – nie wiem za wiele o FP bo nigdy tam nie pracowałem, ale znam tych ludzi i wiem, że jakość ma dla nich znaczenie. Teraz odwiedzając ich biuro mogłem zobaczyć postępy jakie poczynili. Gdy dwa lata temu byłem tam po raz pierwszy to w miejscu obecnego kompleksu biurowego była dziura w ziemi. W tej chwili stoi tam nowoczesny kompleks biurowy z kantyną, siłownią, centrum spa, zjeżdżalniami(!) i wieloma innymi fajnymi rzeczami wspierającymi kreatywną pracę. Niewiele jest w naszym kraju firm zdających sobie sprawę z tego, że ich największym kapitałem są ludzie i ich wiedza, a do tego jeszcze inwestujących w ten kapitał nie ilościowo ale jakościowo.

O samej konferencji można by napisać wiele. Zacznę od tego, że jest to jedyna (znana mi) konferencja w tym kraju, na której testerzy i programiści mówią tym samym językiem. Jest to wydarzenie skierowane zarówno do testerów, programistów, managerów, analityków poświęcone jednemu – bardzo ważnemu tematowi: szerokiej jakości oprogramowania. W programie znalazły się prezentacje zarówno o testowaniu, automatyzacji testów, wymaganiach, metrykach jak i praktykach  i narzędziach developerski. A wisienką na torcie był wykład o tym Kim jest Agile Coach według Krysitana Kaczora zamykający konferencję.

Oprócz wykładów, równolegle odbywały się niesamowicie ciekawe warsztaty prowadzone przez praktyków z Future Processing. Najciekawsze były oczywiście rozmowy w kuluarach i podczas afeter party. Spotkałem wielu starych znajomych i poznałem jeszcze więcej nowych. Zaskakująco miło mi, gdy ktoś w rozmowie odnosi się do tematów, o których mówiłem na poprzednich konferencjach i innych wydarzeniach. To znaczy, że to co robię ma jakieś znaczenie i nie ginie w przestrzeni – zostaje w głowach przynajmniej jednostek, które z sukcesami stosują tą wiedzę w praktyce.

Future Processing z Quality Excites byli chyba pierwsi jeśli chodzi o niekomercyjne wydarzenia tego typu, organizowane na taką skalę. Na szczęście tego typu imprez oraz różnych mniej lub bardziej lokalnych grup entuzjastów jakości przybywa co przekłada się na realne postępy w dziedzinie jakości oprogramowania.

Na koniec jeszcze kilka słów na temat wspomnianego wykładu Krystiana Kaczora – już dawno nie widziałem wykładu na interesujący mnie temat, z którym bym się tak bardzo zgadzał. Sam jakiś czas temu miałem podobne przemyślenia – więcej tu i tu. Tym bardziej cieszę się, że Krystian dołączył do naszego zespołu trenerów w Code Sprinters.

18 komentarzy więcej...

Szanse na zmianę organizacji

opublikowany przez 18, Lut, 2014, w kategoriach Agile, Coaching, Kanban, Scrum, Zarządzanie

change1

Upłynęło już sporo wody w Wiśle od momentu, gdy po długiej, motywującej do działania dyskusji Mike Sutton powiedział mi:

If you can’t change organisation probably you need to change organisation…

Te słowa były powodem jednego z myślę, że kluczowych zwrotów w moim życiu. Ale te słowa wymagają również głębszego zastanowienia nad tym co tak naprawdę sprawia, że niektóre organizacje potrafią się zmienić, a inne nie?

Dzięki doświadczeniu jak by nie było w zmienianiu organizacji właśnie, które zbierałem przez ostatnich kilka lat udało mi się zaobserwować kilka czynników, które moim zdaniem w pewnym, znaczącym stopniu determinują czy dana organizacja ma szanse na zmianę.

Z moich obserwacji organizacje dzielą się na trzy typy.

  1. Success Story – Takie które radzą sobie w miarę dobrze. Dla takich organizacji nie ma przeważnie realnych zagrożeń które by zagroziły ich egzystencji (a przynajmniej zagrożenia te nie występują w sposób nagły i nieprzewidywalny). Przeważnie to że te firmy radzą sobie lepiej od innych wynika z tego, że wyrobiły sobie odpowiednie metody szybkiego wprowadzania zmian i reagowania na zmiany w otoczeniu. W takich organizacjach przeważnie wszyscy widzą potrzebę wprowadzania ciągłych zmian i usprawnień jako coś naturalnego, co może sprawić że będzie jeszcze lepiej.
  2. Standard – Organizacje w których nie wszyscy wyrażają chęć zmian czegokolwiek. Organizacje te radzą sobie zazwyczaj przeciętnie, ale nie widzą na horyzoncie (przynajmniej na razie) realnych zagrożeń, które mogły by wymusić jakiekolwiek realne zmiany. W takich organizacjach są oczywiście pojedyncze osoby, które chciały by sprawić by praca była bardziej efektywna i by organizacja wyrosła ponad przeciętną. Osoby te zazwyczaj dostrzegają zmiany na rynku, zmiany w konkurencyjnych firmach i nowe trendy w stosowanych na świecie metodach zapewniające wzrost efektywności.
  3. Tarapaty – Organizacje które są już w poważnych tarapatach. Dla nich zmiana często jest jedynym ratunkiem, a przynajmniej próbą ratunku przed mniej lub bardziej spektakularną porażką. „Poważne tarapaty” nie oznaczają, że organizacja z dnia na dzień przestanie istnieć jeśli nic nie zrobi – to raczej proces długotrwały, niemniej jednak widoczny. W takich organizacjach potrzeby zmian dostrzegane są przez wiele osób bardzo często również na samym szczycie struktury organizacyjnej.

Największe szanse na wprowadzenie realnych zmian mają organizacje z grupy pierwszej i trzeciej. Rozważając dlaczego właśnie tak się często dzieje warto zastanowić się nad tym co wywołuje opór przed zmianą. Prawdę powiedziawszy ludzie po prostu z natury boją się jakichkolwiek zmian, gdyż zmiana zawsze niesie z sobą niepewność, że to co po niej nastąpi będzie gorsze od tego co jest teraz. Oczywiście obawa ta nie jest nieuzasadniona, ale wystarczy w pełni otworzyć się nie tylko na najbliższe zmiany ale także na możliwe (albo raczej pewne) kolejne i strach zaczyna być irracjonalny. Jeśli coś pójdzie nie tak jak powinno to przecież zawsze można znowu coś zmienić.

W organizacjach typu drugiego nie ma realnej potrzeby wprowadzania zmian. Nie ma aspiracji do tego by stać się wybitnie lepszym i obecnie oraz nie ma realnych zagrożeń – przynajmniej chwilowo. Pracownicy takich organizacji, którzy często po prostu chcieli by się rozwijać i poprawiać efektywność swoją jak i swojego otoczenia często cierpią katusze z powodu słabo widocznych efektów ich działań oraz braku docenienia ich starań w kwestii poprawienia stanu obecnego.

Organizacje pierwszej kategorii nie mają problemu ze zmianami. Od pracowników tutaj wręcz wymaga się ciągłego kwestionowania status quo oraz eksperymentowania z różnymi metodami. Nie jest to oczywiście odpowiednie środowisko dla każdego niemniej jednak, ci którzy już się tam znajdą przeważnie nie narzekają na brak motywacji.

Organizacje w tarapatach również czują realną potrzebę wprowadzenia zmian. Jest to dużo trudniejsze niż w przypadku typu nr jeden, lecz opór jest znacznie niższy niż przypadku typu drugiego. Dużo łatwiej jest każdemu zracjonalizować potrzebę wprowadzenia zmian. Ponadto zazwyczaj ludzie i tak w takiej organizacji czują się zagrożeni więc zmiana rzadko kiedy może jeszcze bardziej pogorszyć sytuacje.

Reasumując, aby wprowadzić realne zmiany w organizacji potrzebna jest odpowiednia presja i dobre powody by takowe zmiany wprowadzić. Obecnie za każdym razem, gdy ktoś próbuje mnie zatrudnić do pomocy w transformacji zawsze pytam o konkretne powody wprowadzania zmian. Czasami takie dyskusje wymagają dużej ilości czasu, zastosowania metod coachingowych oraz innych narzędzi by dotrzeć do głównych potrzeb organizacji. Często okazuje się że znając powody potrzeby wprowadzania zmian jesteśmy w stanie dużo lepiej je zaadresować niż w przypadku, gdy klient przychodzi do nas z gotową propozycją rozwiązania swoich problemów i potrzebą zatrudnienia wykonawcy, który takie rozwiązanie wdroży. Zdarzyło mi się już kilkukrotnie odmówić pomocy, gdy widziałem, że jedynym powodem wprowadzania zmian w organizacji była moda lub irracjonalna chęć wykorzystania budżetu szkoleniowego w „jakiś” sposób.

Powyższe to oczywiście tylko moje luźne, subiektywne obserwacje dotyczące kilku organizacji. Nie są to sztywne reguły, które łatwo można dopasować do każdej organizacji. Są to raczej wskazówki pomagające mi i moim kolegom oraz koleżankom z Code Sprinters efektywniej pracować z naszymi klientami od samego początku – w zasadzie współpracować zanim jeszcze rozpoczniemy współpracę.

2 komentarze więcej...

Czym jest Agile Coaching

opublikowany przez 01, Gru, 2013, w kategoriach Agile, Coaching, Scrum, Zarządzanie

coaching

Pisałem jakiś czas temu o tym jak bardzo potrzebujecie Agile Coacha ale w zasadzie nigdy nie wytłumaczyłem czym Agile Coaching tak właściwie jest? Zakres Coachingu Agile dobrze obrazuje powyższy obrazek. Agile Coaching składa się z (co najmniej) pięciu elementów składowych.

Przede wszystkim Agile Coaching nie jest tym samym czym Coaching. Chociaż Coaching jest jednym z narzędzi często stosowanych przez Agile Coacha.

Po pierwsze Mentoring. Agile Coach służy zespołowi/organizacji całym swoim doświadczeniem. Daje przykład, udziela rad, często też uczy jak osiągnąć mistrzostwo. Bardzo istotne jest tutaj doświadczenie Agile Coacha, które nie powinno ograniczać się tylko do pojedynczych metod – jak na przykład Scrum. Coach powinien posiadać szeroką wiedzę i doświadczenie, gdyż celem Coachingu Agile niekoniecznie musi być wdrożenie Scrum czy Kanban – coaching taki ma przede wszystkim za zadanie poprawić efektywność wytwarzania oprogramowania i funkcjonowania organizacji. Częścią mentoringu jest oczywiście doradztwo.

Po drugie Trening. Agile Coach jest trenerem – szkoli zespół i organizacje. Dlatego bardzo istotna jest nie tylko wiedza Agile Coacha ale także umiejętność jej przekazywania. Docelowo Agile Coach chce doprowadzić do sytuacji, w której zespół staje się samodzielny i nie potrzebuje jego dalszej pomocy.

Po trzecie Facylitacja czyli wpływanie na efektywność pracy danej grupy. Zadaniem Agile Coacha jest między innymi usuwanie wszelkich przeszkód, które stoją na drodze zespołu i przeszkadzają w efektywnym dostarczaniu wartości. Facylitator nie musi być merytorycznie zaangażowany w pracę zespołu, wręcz nawet dobrze jeśli potrafi zachować obiektywność i neutralność zwłaszcza w kontekście rozwiązywania sporów. W skrócie Agile Coach w roli facylitatora odpowiedzialny jest za to, by dany proces działał.

Po czwarte Coaching. Coaching to proces mający na celu jak najlepsze wykorzystanie potencjału jakim dysponuje klient (zespół, organizacja). Coaching opiera się na wielu różnych zasadach i założeniach. Coach nie doradza, nie szkoli, nie zarządza – rolą tradycyjnego coacha jest wydobywanie informacji od klienta i pomoc w jak najlepszym zrozumieniu tych informacji, oraz następnie odpowiednim wykorzystaniu ich. Coaching stanowi nieodzowną pomoc podczas wyznaczania celów (dla poszczególnych osób, zespołu i organizacji), a także pozwala na odpowiednie wybranie drogi prowadzącej do osiągnięcia tychże celów, oraz pomaga podczas jej przemierzania. Coaching to proces – narzędzie, które z pewnością zasługuje na bardziej dogłębne opisanie w kolejnych notkach.

I na końcu Management. Jak pisałem w „Mitach i Problemach w Agile” zarządzanie wcale nie musi oznaczać mówienia ludziom co mają robić. Agile Coach zarządza procesem. Powinien też mieć odpowiednie umocowanie w organizacji pozwalające na pracę nad efektywnością stosowanych metod. Często też, organizacje, które zwracają się o pomoc do Agile Coacha pogrążone są w chaosie – w takich sytuacjach, twarde zarządzanie – często w stylu command and control jest najbardziej skuteczne podczas prac porządkujących chaos.

Najtrudniejsze w roli Agile Coacha moim zdaniem nie jest samo zdobycie kompetencji w każdym z wymienionych powyżej zakresów (chociaż do łatwych to nie należy). Znacznie trudniejsze jest odpowiednie „zmienianie kapeluszy” i trafne wcielanie się w każdą w z powyższych ról w zależności od zaistniałej sytuacji. Nieumiejętne wymieszanie powyższych taktyk może mieć bardzo negatywne skutki zarówno dla organizacji, zespołu i coachowanych jak i dla samego Agile Coacha.

Bardzo istotne jest to, że Agile Coach nie jest nigdy częścią grupy, która jest coachowana. Dzięki takiemu podejściu zachowywany jest odpowiedni dystans i obiektywność w ocenie stanu procesu i organizacji. Jeszcze lepsze efekty możemy osiągnąć, gdy Agile Coach nie jest częścią danej organizacji – wtedy jego perspektywa jest już zupełnie niezależna i obiektywna, a dostarczane dzięki temu informacje zwrotne mają jeszcze większą wartość dla całej organizacji.

7 komentarzy więcej...

Code i Coach Retreat

opublikowany przez 28, Lis, 2013, w kategoriach Agile, Coaching, Kanban, Scrum, Zarządzanie

duck
Wielkimi krokami zbliża się Światowy Dzień Code Retreat pora więc napisać o tym wydarzeniu kilka zdań. Od kilku lat programiści na całym świecie spotykają się jak co roku w grudniu by wspólnie programować. Podczas Code Retreat nie powstaje żaden projekt czy produkt. Chodzi o wspólną pracę nad własnymi umiejętnościami a nie nad produktem.

Code Retreat to kilka sesji programistycznych trwających około godziny podczas których za każdym razem podchodzimy do rozwiązania tego samego problemu na różne sposoby. Za każdym razem zaczynamy od zera. Programujemy oczywiście w parach – gdyż w ten sposób najlepiej jest się uczyć od siebie na wzajem. Każda sesja rządzi się swoimi zasadami i w każdej pracujemy nad konkretną techniką. Po każdej sesji następuje krótka retrospekcja i omówienie tego co się nauczyliśmy.

Zabawa jest przednia i zachęcam wszystkich do udziału w tym wydarzeniu. Tak – do udziału, gdyż Code Retreat 14 Grudnia będzie organizowane również w wielu miastach w Polsce. Wystarczy pogooglować.

Ale to nie wszystko! Dla tych z Was którzy nie tylko programują mam zaproszenie na jeszcze jedno ciekawe wydarzenie (na mniejszą skalę). 05.12.2013 w Krakowie organizuję Coach Retreat. Udało mi się zaprosić jedną z pomysłodawców Coach RetreatOanę Juncu, która pomoże nam w facylitacji tego wydarzenia.

Format Coach Retreat jest zbliżony do Code Retreat:

  • najpierw wybieramy jeden z kilku przygotowanych wcześniej problemów,
  • dobieramy się w grupy max 6 osobowe,
  • jedna osoba wciela się w rolę Coacha a druga w Coachowanego
  • pozostałe osoby w grupie są obserwatorami i udzielają feedbacku w trakcie i po sesji
  • mamy 5-6 sesji coachingowych podczas których próbujemy rozwiązać problem za każdym razem przy użyciu innych metod
  • po każdej sesji retrospekcja i zmiana grup/ról w grupach

Wydarzenie jest całodniowe i raczej darmowe (możliwe jednak, że wymagana będzie drobna opłata rzędu 50zł od osoby jeśli okaże się, że będziemy potrzebować bardzo dużej sali – okaże się wkrótce). Jeśli jesteście zainteresowani udziałem piszcie na adres szkolenia@codesprinters.com lub wiktor.zolnowski@gmail.com. Ilość miejsc ograniczona!

Oana poprowadzi dla nas również warsztaty 06.12.2013 w Krakowie o interesującym tytule Test Driven Business for Lean Startup (powołajcie się na mnie przy rejestracji a czeka Was niespodzianka).

Warsztaty te to kolejny z moich „projektów”. Tym razem nie jest za darmo, ale i tak w bardzo przystępnej cenie. „Projekt” ten polega na sprowadzeniu do Polski trenerów, na których szkolenia sam bym chętnie poszedł. Wynika to z tego, ze na Polskim rynku dość już jest podstawowych szkoleń z Agile i Lean, a na szkoleniu ze Scrum to już chyba każdy był. Ostatnia konferencja Agile By Example potwierdziła moją tezę, że praktycy w naszym kraju wyszli już na wyższy level. Teraz potrzebujemy czegoś więcej niż podstawowe szkolenia na oklepane tematy – potrzebujemy rozwoju. Ja też go potrzebuję dlatego z pewnością w warsztatach Oany wezmę udział jako uczestnik. W przyszłym roku pojawią się kolejne ciekawe szkolenia prowadzone przez niesamowitych trenerów z całego świata.

2 komentarze więcej...