blog.testowka.pl

Zarządzanie

Kluczowe wartości firmy – ale jak?

opublikowany przez 06, Paź, 2015, w kategoriach Agile, Zarządzanie

Zakładając ponad rok temu firmę developerską zastanawiałem się nad tym jak bym chciał by ta firma wyglądała za jakiś czas, z jakimi ludźmi chciałbym pracować docelowo, co będzie mnie/nas motywowało, czym będziemy się kierować? Oczywiście słyszałem o czymś takim jak „Kluczowe wartości firmy” ale w praktyce przeważnie to co widziałem różniło się zasadniczo od tego jak to według teorii powinno wyglądać. Z tego powodu dosyć sceptycznie podchodziłem do tematu ustanawiania kluczowych wartości, wypisywania tego na stronie czy na ścianach w biurze. Moja praktyka konsultanta i Agile Coacha często pokazywała, że na ścianach w wielu firmach widniały piękne frazesy o tym jacy to jesteśmy super i czym się tutaj kierujemy, a w rzeczywistości pracownicy tych firm mieli to gdzieś lub zupełnie się z tymi wartościami nie utożsamiali. Oczywiście winę za to można by zwalić na proces rekrutacji ale myślę że nie tylko.

Niemniej jednak, gdy podczas ostatniego roku nasza firma stopniowo rosła poczułem, że zaczyna nam brakować czegoś, co by nas wszystkich łączyło. Czegoś co by sprawiało, że wszyscy utożsamiali byśmy się z naszą marką i z tym co robimy. Ustanowienie kluczowych wartości, wspólnych dla wszystkich, którymi będziemy się kierować w codziennej współpracy wydawało się być dobrym pomysłem na rozwiązanie tego problemu.

No dobrze – ale jak ustanowić wartości wspólne dla wszystkich?

Samo mówienie o kluczowych wartościach to jedno, ale w jakiś sposób trzeba by ustalić jakie one mają być. Zrobienie tego w niewłaściwy sposób nie tyle będzie szkodliwe, co sprawi, że nie wszyscy będą się z tymi wartościami utożsamiać, a co za tym idzie wartości te nie będą w pełni działać o ile w ogóle będą działać. Pierwszy pomysł na ustanowienie wartości jaki przyszedł mi do głowy polegał na tym, że chiałem porozmawiać o naszych personalnych wartościach z wspólnikami, a następnie przedłożyć te wartości innym. W końcu my wiemy jakimi wartościami kierowaliśmy się zakładając firmę i zatrudniając ludzi oraz jakimi kierujemy się na codzień.

Pomysł ten o ile z pozoru bardzo dobry, wydawał mi się niekompletny. Miałem obawy (myślę, że słuszne), że zrobienie tego w taki sposób nie rozwiąże problemu związanego z tym, że ludzie nie będą się czuli związani z tymi wartościami. Z pomocą przyszedł Michał (jeden z pierwszych naszych developerów, który współpracuje z nami w zasadzie od samego początku Pragmatic Coders). Michał podsunął mi artykuł, o tym jak podobny problem rozwiązał CEO Imgur.

We wspomnianym artykule autor opisał swoją historię tego jak rozpoczynając pracę w Imgur dostał od swojego pracodawcy maila z pytaniem o jego personalne, kluczowe wartości, którymi kieruje się na codzień. Podobnego maila napisałem i ja do naszych współpacowników. Ale zanim do tego doszło postanowiłem zapytać innych (między innymi moich wspólników) co myślą o takim pomyśle? W dużym skrócie wszyscy z którymi rozmawiałem (oprócz Michała) byli do tego mocno sceptycznie nastawieni. Moi wspólnicy wręcz stwierdzili, że „w ten sposób się ośmieszę przed pracownikami i stracę autorytet”, poza tym „nikt nie przeczyta tego maila, a już napewno na niego nie odpowie”. Kolejną obawą moich wspólników było to, że „co jeśli ktoś odpisze i okaże się, że jego wartości są zupełnie sprzeczne z tym jak my widzimy naszą firmę?”. Tym ostatnim akurat postanowiłem się w ogóle nie przejmować – po pierwsze sami tych ludzi zatrudnialiśmy, więc raczej spełniają nasze oczekiwania także pod tym względem, a po drugie nawet jeśli kierują się innymi zasadami niż my to wiedza na ten temat może nam jedynie pomóc we wzajemnych relacjach.

Treść maila znajdziecie poniżej. Tak, wiem, że jest strasznie długi, ale bardzo zależało mi na tym, by wszyscy dobrze zrozumieli o co mi chodzi i dlaczego zależny mi na tym, by na niego odpowiedzieli.

Jako, że nasza firma cały czas rośnie i mamy nadzieję, że ten trend się nadal utrzyma, coraz bardziej istotne staje się odpowiednie zdefiniowanie wspólnych, kluczowych wartości, w oparciu o które dalej kształtować się będzie nasza kultura organizacyjna, jak na zewnątrz i wewnątrz firmy będzie wyglądała nasza marka, a także jak zostanie zaplanowana strategia dalszego rozwoju Pragmatic Coders.
Dlatego zwracam się do Ciebie z prośbą. Opisz prosze 3-5 wartości, które są dla Ciebie ważne. Wartości to coś, co definiuje to kim każdy z nas jest i kim chce być. Każda taka “wartość” może być pojedynczym słowem albo zdaniem, który opisuje to, co jest dla nas ważne w codziennej pracy.
Zdefiniowanie kluczowych wartości to próba określenia tożsamości Pragmatic Coders – zasad, tego w co wierzymy, filozofii którą wyznajemy na codzień w pracy i poza nią. Osobiście od jakiegoś czasu próbowałem takie wartości samemu opracować, ale doszedłem do wniosku, że to bez sensu – bo Pragmatic Coders to my wszyscy a nie tylko ja, Marcin i Marek.
Tylko wspólnie określone wartości mogą być czymś, w co wszyscy będziemy wierzyć, czymś co ma dla nas wszystkich znaczenie i motywuje nas każdego dnia do działania. To nie mogą być puste słowa i marketing bulshit, który wrzucimy na stronę i napiszemy na ścianie złotymi literami. Abyśmy mogli rozwijać się w określonym kierunku, który będzie odpowiadał każdemu z nas te wartości muszę mieć dla nas wspólne znaczenie.
To powinny być rzeczy, które są ważne dla każdego z nas personalnie, wcale nie muszą odzwierciedlać tego jak wygląda nasza firma w tej chwili. Odpisz proszę bezpośrednio do mnie, nie musisz jeśli nie chcesz o tym rozmawiać z innymi i dzielić się tym z nimi.
Mam nadzieję, że po zebraniu tego razem będziemy mogli lepiej zrozumieć to, co jest dla nas ważne i w jakim kierunku powinniśmy się rozwijać jako firma, zespół i ludzie.
Ku zdziwieniu niedowiarków na maila odpisali wszyscy. Niektórzy, bardzo krótko i zwięźle, inni rozpisując się na kilka stron. Natomiast najważniejsze było to, że teraz do wyznaczania naszych wspólnych wartości miałem już do dyspozycji wiedzę na temat tego jakie wartości wszyscy wyznajemy. Ostatecznie nawet jeden ze wspólników postanowił dopisać swoje wartości do listy wartości zebranych od wszystkich w firmie. Dalej było już z górki – wszystkie odpowiedzi wrzuciłem do arkusza w excelu rozbijajac je na pojedyncze wartości. Uważnie wszystko przeczytałem, poszukałem elementów wspólnych lub podobnych, pogrupowałem i uporządkowałem według tego jak często dana wartość powtarzała się w odpowiedziach moich kolegów i koleżanek. W efekcie powstało siedem kluczowych wartości, które następnie skróciliśmy do 4 najważniejszych:
  • Ludzie i Współpraca
  • Pasja i Zaangażowanie 
  • Satysfakcja i Jakość
  • Szacunek i Zaufanie

 

Dzięki odpowiedziom wszystkich w firmie, do każdej z powyższych kluczowych wartości mogliśmy też dopisać jej wspólne znaczenie dla każdego z nas.
Co dalej? Narazie te wartości zawisły na ścianie w biurze. Natomiast najważniejsze jest to, że te wartości są wypadkową nas wszystkich. Nie trzeba ich w żaden sposób „wdrażać” w naszą pracę – one tam po prostu są. Ale to, że teraz wiszą na ścianie cały czas przypomina nam dlaczego tu jesteśmy i dlaczego robimy to co robimy. A gdy z jakiegoś powodu, ktoś z nas zaczyna działać niezgodnie z tymi wartościami dużo łatwiej jest nam teraz wrócić na właściwe tory i naprawić to co zepsuliśmy.
O tym jak idzie nam ich wykorzystywanie w codziennej pracy pewnie jeszcze napiszę nie raz.
7 komentarzy więcej...

Jeśli nie wiadomo o co chodzi…

opublikowany przez 10, Lut, 2015, w kategoriach 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, 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...

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

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

opublikowany przez 22, Lip, 2014, w kategoriach 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...

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