Miernik, metryka, a może wskaźnik, czyli o mierzeniu w projekcie

indicator

Przy okazji rozmów jeden na jeden rozmawiamy często o tym, w jakim stanie są nasze projekty. Zastanawiamy się czy są jakieś problemy, szukamy możliwych usprawnień. Z moich doświadczeń na bazie wielu takich spotkań wynika, że cała rozmowa zwykle sprowadza się do tego, w jaki sposób podchodzimy do mierzenia naszego procesu. Gdy zaczynamy o tym rozmawiać, to okazuje się, że nie wszystkie obszary projektu są dla nas w pełni zrozumiałe, a to prowadzi do tego, że nie mamy kontroli nad procesem i tym samym, nie jesteśmy w stanie proponować sensownych usprawnień. W mojej ocenie mierzenie jest często mocno upraszczane, powielane są mechanizmy stosowane przez innych (np. mamy burndown chart i przecież to nam wystarczy) i brakuje większej refleksji nad tym, jak podchodzić do pomiarów w projekcie.

Z drugiej strony wszyscy liderzy widzą wartość w retrospektywach i niezależnie od tego, w jaki sposób pracuje dany zespół (scrum, kanban itp.), wszyscy chwalą ten element procesu. Zdecydowanie się z tym zgadzam, gdyż jest to skuteczne narzędzie pozwalające na ciągłe doskonalenie. Uważam jednocześnie, że aby w pełni wykorzystać jego potencjał, nie tylko lider, ale i cały zespół musi rozumieć swój proces i mierzyć to, co jest w nim kluczowe. Ujmując nieco inaczej – zespół nie może bazować tylko na intuicji i własnych emocjach, ale także na danych liczbowych.

Warto wobec tego omówić podstawowe pojęcia związane z mierzeniem, zwłaszcza, że często są one mylone bądź źle rozumiane.

Definicje

Metryka (metric) jest liczbowym pomiarem przedstawiającym wycinek danych w odniesieniu do jednego lub kilku wymiarów. Metryka może być budowana zarówno z mierników, jaki i wskaźników.

Przykład: Komputer pokładowy w moim samochodzie mierzy zużycie paliwa. Planując podróż na wakacje, zakładam średnie spalanie, którego nie chcę przekraczać. W czasie jazdy sprawdzam stan średniego spalania na bieżąco i porównuję z tym, co sobie założyłem.

Miernik (measure) przedstawia wartość zestawioną względem przyjętego standardu, wynikającą z pomiaru. Można powiedzieć, że miernik oznacza precyzyjny pomiar, zgodny z przyjętym standardem.

Przykład: prowadząc samochód, podejmuję decyzję w oparciu o pomiar aktualnej prędkości. Prędkość (km/h) jest mierzona zgodnie z standardami (precyzja).

Wskaźnik (indicator) jest ilościową bądź jakościową wartością, która wskazuje stosunek wielkości rozpatrywanej do przyjętej podstawy. Można powiedzieć, że wskaźnik oznacza pewne przybliżenie, nie oznacza dokładnego pomiaru, a jedynie wskazanie.

Przykład: prowadząc samochód, podejmuję decyzję w oparciu o wskazanie poziomu wypełnienia baku paliwem. Nie jest to dokładny pomiar, a jedynie wskazanie, że bak jest pełny lub pomału zacznie mi brakować paliwa.

KPI (key performance indicator) jest wskaźnikiem związanym z celem. Performance oznacza, że mierzymy naszą wydajność (stopień realizacji celu). Key oznacza, że jest on ważniejszy od pozostałych wskaźników.

Wskaźnik wyprzedzający (Leading Indicator) – wskaźnik, który wskazuje na pewne zjawisko z wyprzedzeniem. Czyli analizując go, możemy spodziewać się pewnych zjawisk, który wystąpią w przyszłości.

Wskaźnik opóźniony (Lagging Indicator) – wskaźnik, który wskazuje na pewne zjawisko już po jego wystąpieniu. Czyli analizując go, możemy otrzymać potwierdzenie na istnienie pewnych zjawisk.

 

W skrócie możemy przyjąć, że:

  • Metryka pozwala nam na porównanie pomiarów względem siebie
  • Miernik mierzy coś (precyzja pomiaru jest ważna)
  • Wskaźnik wskazuje na coś (precyzja nie jest konieczna)

Przykłady

Całkiem możliwe, że po zapoznaniu się z tymi pojęciami, zastanawiacie się, w czym tkwi różnica i o co tak właściwie chodzi. Posłużmy się dłuższym przykładem, aby to lepiej zrozumieć.

Załóżmy, że jesteśmy odpowiedzialni za dział sprzedaży i chcemy wiedzieć, jak nam idzie. Zajmiemy się wobec tego całkowitą sprzedażą. Patrzymy na najbliższy miesiąc, mamy luty 2016. Standardem będzie dla nas polski złoty (PLN) i mierzymy całkowitą sprzedaż w tym miesiącu. Mamy tym samym nasz miernik – całkowita sprzedaż w lutym 2016 i jego wartość to 1000 PLN.

Dobrze to wiedzieć, niemniej sam miernik niewiele nam mówi i warto by go było do czegoś odnieść i porównać (pewnie zastanawiamy się, czy 1000 PLN to dużo czy mało). Zaczynamy mierzyć naszą sprzedaż w kolejnych miesiącach i finalnie otrzymujemy dane z kolejnych miesięcy od lutego 2016 do lutego 2017. Teraz mamy już jakiś kontekst, możemy porównywać wyniki sprzedaży w poszczególnych miesiącach i obserwować trend. Całkowita sprzedaż od luty 2016 do luty 2017 jest naszą metryką.

Przed nami kolejny rok i zastanawiamy się, jak zaplanować budżet i jakiej sprzedaży powinniśmy się spodziewać.  W wyniku analiz obliczyliśmy wartości oczekiwane sprzedaży (trend bazowy) i w kolejnym roku będziemy mierzyć wyniki naszej sprzedaży względem planu. Właśnie stworzyliśmy nasz wskaźnik – całkowita sprzedaż od luty 2017 do luty 2018 względem planu. Jednocześnie pozwala nam on na podejmowanie kluczowych decyzji związanych z naszym biznesem (wyznacza nasz cel) i jest on naszym KPI. Możemy także powiedzieć, że udoskonaliliśmy naszą metrykę poprzez uwzględnianie planowanego trendu.

Minął kolejny rok i nasze podejście do mierzenia nie sprawdza się do końca. Mamy nasz KPI, dzięki czemu wiemy, jak nam idzie. Niemniej chcielibyśmy jeszcze potrafić reagować z wyprzedzeniem. Dokonujemy kolejnej analizy i wprowadzamy wskaźnik wyprzedzający (leading indicator) w postaci mierzenia ilości zapytań względem minimalnej ilości, której się spodziewamy. Dzięki temu możemy poprawiać naszą sprzedaż już na wcześniejszym etapie związanym z samymi zapytaniami. Możemy także analizować ilość pozyskanych klientów, jako wskaźnik opóźniony (lagging indicator) dla poprawy jakości zapytań.

 

Po co to wszystko?

Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.
H. James Harrington

Mam nadzieję, że omówienie podstawowych pojęć związanych z mierzeniem pozwoli Wam uporządkować ten obszar w swoich projektach. Bardzo możliwe, że mierzycie już teraz sporo elementów Waszego procesu, zwłaszcza, że wiele narzędzi zawiera wbudowane metryki. Moim zdaniem warto korzystać czy to z gotowych rozwiązań czy też metryk dostępnych w sieci. Warto także wiedzieć, jak zostały one skonstruowane i czemu mają służyć. To pozwoli nam na podejmowanie lepszych decyzji w naszych projektach. Jeśli natomiast do tej pory mierzenie było Wam obce, to zachęcam do skonstruowania i wdrożenia pierwszych metryk. Raczej nikt z nas nie prowadzi samochodu zupełnie ignorując wszelkie wskazania dotyczące naszej jazdy. Czy lider może prowadzić projekt nie wiedząc, co się tak naprawdę w tym projekcie dzieje?

 

Image credit: (c) Pixabay 

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

5 teorii motywacji, o których lider wiedzieć powinien

7921567316_c83d01e959_z

Przyznam szczerze, że o motywacji chciałem napisać już dawno temu, ale ciągle nie byłem pewien, jak podejść do tego tematu – czy pisać szeroko, czy może jak najkrócej i konkretnie, czy stworzyć cykl artykułów, czy może jeden post, który pomoże Czytelnikom w ich własnych poszukiwaniach.

Dziś dzielę się z Wami treścią, która wynika z moich doświadczeń i poszukiwań w obszarze teorii motywacji. Liczę, że nie tylko pozwoli Wam to uporządkować ten obszar, ale będzie to także dla Was zachęta do dalszych poszukiwań.

Ostatecznie zdecydowałem, że powstanie jeden dłuższy post, dzięki czemu będziecie mogli wracać do niego w razie potrzeby bez konieczności zapisywania wielu różnych linków.

Wstęp

Każdy lider wcześnie czy później musi zmierzyć się z tematem motywacji – czy to ze względu na ludzi, z którymi pracuje, czy też ze względu na swoją osobę i poszukiwanie swojej drogi rozwoju. Jest to moment, w którym zaczynamy zadawać sobie pytanie o przyczyny i sens tego, co robimy. Zastanawiamy się, co jest dla nas ważne, co potrzebne, a bez czego możemy sobie poradzić. Następnie próbujemy nasze rozważania sprowadzić do bardziej ogólnego opisu, szukamy jakiegoś potwierdzenia w nauce, aby upewnić się, czy nasze przemyślenia są słuszne i pozwalają nam na podejmowanie dobrych decyzji.

Pierwsze modele

Moje poszukiwania pozwoliły mi kilka lat temu na porównanie dwóch modeli do otaczającej mnie rzeczywistości:

Model Maslowa mówi nam, że ludzie kierują się potrzebami zgodnie z ustaloną hierarchią, jak na poniższej piramidzie.

piramida_1

Oznacza to, że przykładowo najpierw pragniemy zaspokoić swoje potrzeby związane z bezpieczeństwem (odpowiednie wynagrodzenie), a następnie myślimy dopiero o potrzebach wyższego rzędu (rozwojowy projekt). Myślę, że dość dobrze oddaje to współczesna wersja piramidy;)

piramida_2

Dość często przedstawienie piramidy w „nowej wersji” podczas konferencji czy prezentacji wywołuje śmiech uczestników, niemniej jest w tym sporo prawdy. Brak dostępu do sieci dla osób z branży IT jest niezwykle uciążliwy i powoduje rzeczywisty niepokój i spadek chęci do pracy. Oczywiście problemy fizjologiczne zgodnie z definicją Maslowa mają dość szeroki zakres i doświadczony lider powinien potrafić je rozpoznawać w zespole (np. problemy zdrowotne, przemęczenie, spędzanie w pracy zbyt wielu godzin, problemy ze snem, problemy z odżywianiem się, huśtawki nastrojów itp.). Dzięki temu lider ma świadomość istnienia potrzeb „niższych” i zaspokojenia ich, zanim sięgnie po elementy motywacji z górnych części piramidy.

Przykładowe potrzeby bezpieczeństwa z kolei to wynagrodzenie, pewność zatrudnienia, stabilna pozycja firmy, zrozumienie przełożonego i całego zespołu, brak konfliktów z kimś w firmie czy klientem.

Podsumowując – dzięki teorii Maslowa dostrzegamy, jak wiele czynników (oraz w jakim porządku) może wpływać na motywację. Widzimy także, że wiele z nich może nie być związanych bezpośrednio z samą pracą czy obecnie realizowanym projektem. Nie należy także zapominać, że każda osoba w zespole w danej chwili może być w innym miejscu na piramidzie i potrzeby poszczególnych osób z zespołu mogą być różne.

 

McGregor natomiast pokazuje dwa sposoby myślenia o pracownikach ujęte w teorii X i Y.

Według teorii X ludzie nie lubią pracy i starają się jej unikać, zaś zgodnie z teorią Y praca jest naturalną częścią życia i ludzie sami odnajdują w sobie wewnętrzną motywację.

W praktyce podejście zgodne z teorią X będzie cechować się brakiem zaufania dla pracowników, szukaniem winnych, kontrolą, stosowaniem kar (jak lider nie dopilnuje, to pracownik zrobi źle lub nie zrobi wcale).

Zgodnie z teorią Y z kolei pracownicy obdarzeni są zaufaniem, pozwala im się na branie większej odpowiedzialności. Zakłada się, że są ambitni, chętni do pracy, potrafią samodzielnie podejmować decyzje i co najważniejsze – czerpią satysfakcję ze swojej pracy, jeśli pozwoli im się na bycie twórczym i kreatywnym. Dla lidera oznacza to, że jeśli stworzymy ludziom odpowiednie warunki pracy, to pojawi się satysfakcja z jej wykonywania i będzie to czynnik motywujący. Zadaniem lidera będzie wobec tego usuwanie wszelkich przeszkód na drodze do swobodnej pracy twórczej wśród ludzi.

Dalsze poszukiwania

Moje obserwacje nie do końca pokrywały się z tymi opisami. Zauważyłem, że hierarchia potrzeb nie zawsze była tak jednoznaczna, jak pokazuje piramida Maslowa. Przykładowo dla jednych osób wynagrodzenie miało bardzo duże znaczenie, dla innych dużo mniejsze (choć w teorii były to osoby o zbliżonym poziomie kompetencji i wynagrodzenia). Były osoby, którym bardzo zależało na pracy w cichym pomieszczeniu, dla innych nie było to istotne. Okazywało się także, że nie zawsze potrzeby z dołu piramidy są ważniejsze od tych z jej szczytu (każdy inaczej definiował czym dla niego jest bezpieczeństwo czy potrzeba przynależności).

Szukając natomiast odzwierciedlenia modelu McGregora w swoich projektach, nie zdarzyło mi się zauważyć, aby ktoś podchodził do pracy zgodnie z teorią X. Nie oznaczało to jednak automatycznie, że teoria Y działała bez zarzutu. Branie pełnej odpowiedzialności za swoje decyzje nie wszystkim przychodziło łatwo i nie każdemu odpowiadał taki model pracy.

Postanowiłem rozważyć kolejne teorie i modele, które z większą precyzją pokrywałyby się z moimi doświadczeniami. Dzięki temu trafiłem na dwuczynnikową teorię motywacji Herzberga.

Herzberg zauważył, że możemy wyróżnić dwa rodzaje czynników wpływających na nasz odbiór pracy:

  • Czynniki wpływające na satysfakcję z pracy (motywatory wewnętrzne) [Motywacja]
  • Czynniki powodujące niezadowolenie z pracy (czynniki higieny) [Demotywacja]

herzberg_table

Image source: Peakon.com

Herzberg pokazał, że każdy czynnik do pewnego stopnia może być w obu grupach (higiena i motywacja). Oznacza to dla nas, że w praktyce ludzie mogą różnie postrzegać te same obszary, np. wynagrodzenie. Z drugiej strony możemy też wyróżnić takie czynniki, które dość mocno wpisują się w tylko jedną ze stron osi. Ostatni, najbardziej istotny wniosek z opracowania Herzberga mówi nam, że powinniśmy generalnie postrzegać motywację przez pryzmat dwóch oddzielnych grup – higieny oraz motywacji (wewnętrznej). Braki w danej grupie nie mogą być uzupełniane przez elementy z grupy przeciwnej. Aby utrzymywać całościowo odpowiedni poziom motywacji, należy zapewniać odpowiedni poziom dla czynników w każdej z grup oraz uwzględnić brak relacji / powiązania między tymi dwoma grupami. Jeśli zatem jakiś czynnik z grupy higieny wpływa negatywnie (np. niskie wynagrodzenie) na całościową motywację, to nie poprawimy jej poprzez wzrost czynnika z grupy motywatorów wewnętrznych (np. powierzenie ambitnego zadania). Analogicznie możemy powiedzieć, że nie można kupić motywacji (twoje praca jest nudna, brak Ci chęci, to może zapłacę Ci więcej). Kluczowe jest także to, że zaspokojenie czynników higieny nie powoduje wzrostu całościowej motywacji, jednak ich niezaspokojenie bardzo silnie demotywuje. Kontynuując przykład z wynagrodzeniem – brak odpowiedniego wynagrodzenia mocno demotywuje, ale podwyżka nie wpływa długoterminowo pozytywnie na wzrost motywacji (a jedynie zmniejsza demotywację). Poprzez zadbanie o czynniki higieny w pierwszej kolejności stwarzamy przestrzeń do tego, bo zadziałały czynniki podnoszące satysfakcję.

herzberg_pl

Przykład – kilka lat temu w ramach akcji oceniania zespołu postanowiłem stworzyć ranking (zespół liczył sporo osób – ponad dwadzieścia). W formie ankiety poprosiłem każdego z zespołu o ocenę pozostałych osób. Na tej podstawie stworzyłem ranking i podczas rozmów podsumowujących ostatni okres informowałem każdego, jak w nim wypadł. Intencje może i nie były złe, ale efekt…Osoby, które postrzegały siebie lepiej niż wypadły, poczuły się bardzo źle po tym, co zobaczyły. W jednej chwili swoim błędem sprawiłem, że u niektórych osób pojawiła się demotywacja.

Podsumowując – teoria Herzberga pokazuje podział na dwie grupy czynników wpływających na motywację. Lider powinien zapewniać odpowiedni poziom w obu grupach, pamiętając że czynniki z obu grup są niezależne.

Szersze spojrzenie na motywację wewnętrzną

Omówione powyżej teorie pokazały mi, że rolą lidera jest rozpoznawanie i usuwanie przeszkód (na które jako lider mogę mieć wpływ). Niemniej, brakowało mi szerszego spojrzenia na motywację wewnętrzną – jeśli zapewnimy ludziom odpowiedni warunki, to co jeszcze ma wpływ na to, by mieli satysfakcję z wykonywanej pracy oraz co może zagrażać w utrzymaniu odpowiedniej motywacji?

Pozwolę sobie zacząć od kolejnego przykładu. Miałem w zespole bardzo dobrego programistę i momencie, gdy zespół zaczął dynamicznie rosnąć, pojawiła się potrzeba skutecznego wdrażania nowych osób. Postanowiłem, że wspomniana osoba poprowadzi szkolenie z pewnej technologii. Oczywiście zostawiłem jej pełną swobodę i zakładałem, że wszystko zadziała. Okazało się jednak, że szkolenie poszło „tak sobie” lub mówiąc nieco bardziej wprost – nie każdy czuje się dobrze w roli prowadzącego szkolenia, zwłaszcza jeśli nie ma do tego żadnego wcześniejszego przygotowania. W efekcie doszliśmy razem do wniosku, że prezentacja przed większą grupą nie jest idealnym rozwiązaniem i zamiast tego zastosowaliśmy pracę w parach. Zadziałało rewelacyjnie. Zamiast wykorzystać wewnętrzną motywację danej osoby o pozwolić jej zrobić po swojemu zgodnie z tym, czym jest dobra, na siłę szukałem zewnętrznych motywatorów i namawiałem do zrobienia szkolenia w formie, która mi pasowała.

Przypadki takie jak ten sprawiły, że poszukiwałem dalej wiedzy, która mogłaby mi pomóc w podejmowaniu lepszych decyzji w przyszłości. W ten sposób trafiłem na dwie, dość zbliżone teorie motywacji – Pinka oraz teorię automotywacji [Self Determination Theory (SDT)].

Self Determination Theory (SDT)

SDT bazuje na wielu badaniach przeprowadzonych w przeciągu kilkudziesięciu lat przez profesorów Edwarda Deci i Richarda Ryana. W swoich pracach skupiali się mocno na tym, dlaczego ludzie są zmotywowani (co wpływa pozytywnie, a co negatywnie na naszą motywację).

Deci i Ryan w swoich poszukiwaniach sprawdzili różne formy wpływania na motywację i warto zwrócić uwagę ich kluczowe odkrycia.

Czy motywację można kupić?

Wyobraźmy sobie, że robimy coś, co sprawia nam dużą przyjemność i można powiedzieć, że nie potrzebujemy żadnych dodatkowych bodźców zewnętrznych, żeby to robić. Sami odnajdujemy w sobie chęć do wykonywania tej czynności. Nagle ktoś zaczyna nam płacić za to 100 zł. Myślimy sobie, że w sumie, czemu by to miało być złe – w końcu i tak to lubimy robić i jeszcze ktoś nam za to zapłaci. Po jakimś czasie ta sama osoba oferuje nam 200 zł. Jeszcze lepiej, dostaniemy więcej niż poprzednio, a nasza praca przecież tak nam się podoba. Po kilku tygodniach dowiadujemy się, że nie ma już więcej pieniędzy i w związku z tym, nikt nam już nie zapłaci za naszą pracę. Co się stanie? Czy w dalszym ciągu będziemy chcieli ją wykonywać?

Badania oparte na podobnych scenariuszach pokazały bardzo wyraźnie, że motywacji nie można kupić (w dłuższej perspektywie). Podany przykład pokazuje jeszcze jeden mechanizm – poprzez nagrody (spodziewane, do których przyzwyczajamy ludzi) możemy zniszczyć ich wewnętrzną motywację, a zbudować zewnętrzną – oczekiwanie nagrody.

Czy do bycia zmotywowanym można zmusić?

Stosowanie nagród kar może działać w krótkim terminie, ale długofalowo się nie sprawdzi i może prowadzić do:

  • Rywalizacji i osłabienia pracy zespołowej
  • Spadku motywacji wewnętrznej – zawsze, gdy z 10 osób nagradzasz tylko jedną, pozostałe 9 czuję się z tym bardzo źle
  • Spadku znaczenia samej pracy – pracujemy tylko po to, by coś wygrać lub uniknąć kary
  • Spadku jakości i kreatywności – w celu uzyskania nagrody bądź uniknięcia kary poszukujemy „drogi na skróty”
  • Oszukiwania – w celu osiągnięcia nagrody lub uniknięcia kary możemy uciekać się nawet do oszukiwania
  • Dodatkowego monitorowania – w celu kontrolowania systemu pod kątem działania zgodnie z założonymi regułami

Co wpływa na motywację?

Badania Deciego i Ryana wykazały, że ludzie mają pewne potrzeby wewnętrzne i jeśli zostaną one zaspokojone, to będą zmotywowani. Zidentyfikowali oni trzy kluczowe obszary:

  • Kompetencje (Competence)
  • Autonomia (Autonomy)
  • Istotność (Relatedness)

sdt

 

Pink z kolei podaje bardzo zbliżoną wersję i mówi o:

  • Autonomia (Autonomy)
  • Mistrzostwo (Mastery)
  • Cel (Purpose)

pink

 

Myślę, że warto rozpatrzyć oba te modele wspólnie, gdyż moim zdaniem dość mocno się one pokrywają. Przyjrzyjmy się wobec tego bliżej każdemu z trzech kluczowych obszarów automotywacji.

Autonomia jest naturalną potrzebą człowieka do kierowania własnym życiem i podejmowania samodzielnych decyzji. Oznacza to wolność wyboru i sprawia, że odczuwamy wewnętrzną chęć zrobienia czegoś. Autonomię można rozpatrywać w czterech głównych wymiarach:

  • Zadań (co robimy)
  • Czasu (kiedy robimy)
  • Zespołu (z kim robimy)
  • Techniki (jak to robimy)

autonomia

Każdy z nas postrzega te wymiary nieco inaczej (dla jednych osób ważniejszy jest czas, dla innych na przykład technika).

Kompetencje / Mistrzostwo należy rozumieć nie tyle, jako bycie kompetentnym do wykonania danego zadania, ale jako wewnętrzne przekonanie, że potrafimy wykonać określone zadanie – mamy niezbędne kompetencje, ale też podejmuje się pewnego wyzwania i nie wszystko będzie łatwe i przyjemne. Traktujemy swoje zdolności, jako coś nieskończonego, co można stale ulepszać.

Istotność / Cel to nadanie sensu naszej pracy. Każdy z nas będzie chciał widzieć większy sens swojej pracy, wiedzieć, że komuś ona ma służyć, coś ulepszać. To naturalna potrzeba realizowanie czegoś większego i trwalszego niż my sami.

Co to oznacza dla lidera?

W praktyce odkrycia z zakresu automotywacji dość jasno pokazują liderowi, co powinien robić – nie motywować zewnętrznie, ale usuwać wszelkie przeszkody na drodze automotywacji. Dla każdej z osób w zespole warto rozeznać szerzej, jak rozumie autonomię, mistrzostwo oraz cel i organizować taki system / sposób pracy zespołu, który będzie te obszary wzmacniał. Przykładowo dla wielu naszych projektów realizowanych dla klientów zewnętrznych, organizujemy na starcie projektu spotkanie, podczas którego klienci pokazują nam wizję produktu, szerszy opis tego, komu będzie on służył i dzięki temu nadajemy sens pracy całego zespołu.

Wracając jeszcze do poprzedniego przykładu z bardzo dobrym programistą – gdybym wcześniej rozeznał obszar Mistrzostwa oraz Autonomii, zdecydowalibyśmy zapewne wspólnie od razu o przekazywaniu wiedzy poprzez pracę w parach, zamiast ślepo brnąć w prezentację dla całej grupy (podjąłem jako lider decyzję i odebrałem autonomię).

Kilka słów podsumowania

Mam nadzieję, że udało mi się przekazać Wam kluczowe teorie motywacji i ich praktyczne zastosowanie. Podsumowując moje wcześniejsze rozważania można powiedzieć, że powinniśmy w pierwszej kolejności dla każdej osoby indywidualnie określić i zniwelować oddziaływanie czynników wpływających na demotywację (czynniki higieny), a następnie, kierując się zasadami automotywacji, wspierać motywację wewnętrzną. Należy przy tym pamiętać, że każdy ma inne predyspozycje i jedne osoby potrzebują bardzo dużej swobody, inne natomiast wymagają większego wsparcia od lidera.

 

Chciałbym także zwrócić uwagę na pewien trend, który obserwujemy w branży IT. Otóż możemy dziś zauważyć, że w związku z coraz większym popytem na usługi w tym sektorze gospodarki, firmy prześcigają się w tym, co można oferować przyszłym pracownikom. Ten proces, niezależnie od tego czy organizacja ma szczere intencje, czy też nie, sprawia, że ludziom coraz trudniej jest się w tym zamieszaniu odnaleźć. Można zauważyć, że:

  • Co chwilę ktoś oferuje nam nową pracę
  • Otrzymujemy informację o dużo lepszym wynagrodzeniu
  • Pojawiają się kolejne „udogodnienia”, które na nas czekają

W efekcie zaczynamy tracić koncentrację, zastanawiamy się, czy faktycznie obecne miejsce pracy jest dość dobre, czy rzeczywiście zarabiamy odpowiednio dużo itd.

Moim zdaniem istnieje niebezpieczeństwo polegające na tym, że na bazie tych wszystkich sygnałów, zaczynamy sobie tworzyć obraz idealnego miejsca pracy i bardzo trudno jest nam potem taki ideał odnaleźć w rzeczywistości. Nagle może okazać się, że praca, która dotychczas dawała nam tyle satysfakcji, przestaje nam się podobać i sami już nie wiemy, czego chcemy (zamieniliśmy motywatory wewnętrzne na zewnętrzne, które coraz trudniej zaspokoić).

Myślę, że warto jednocześnie zaznaczyć, że moje wnioski dotyczą branży IT, z którą jestem bezpośrednio związany i zakładam, że mogą one być prawdziwe dla innych obszarów, w których wymagana jest praca twórcza.

 

Image credit: (c) Pablo Fernández, Creative Commons 2.0, 

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Czego nauczyła mnie tegoroczna Agilia?

AgiliaConference2016banner
Agilia Conference 2016 już za mną jednak przemyślenia po konferencji towarzyszą mi każdego dnia. Tegoroczna Agilia nie miała żadnego przewodniego hasła. Przynajmniej oficjalnie. Dla większości osób, z którymi miałem okazję rozmawiać, Agilia skupiała się na jednym – „dostarczaniu wartości”.

Nim postaram się przybliżyć treści, na niej poruszane, wrócę na chwilę jeszcze do spraw organizacyjnych samej konferencji. Tegoroczna edycja Agilia miała miejsce nieco bliżej naszej południowej granicy (Ołomuniec), aniżeli miało to miejsce rok temu (Brno). Ołomuniec, oddalony o 190 km od Katowic, choć jest niewielkim miastem, ma swój urok – ponad tysiąc lat historii w połączeniu z nowoczesnością hotelu, w którym miała miejsce konferencja, robi miłe wrażenie zawsze zostawiając coś na deser. Czeskie piwa znamy przecież nie od dziś, a w Ołomuńcu mieści się kilka minibrowarów. Wróćmy jednak do konferencji, bo to o niej miał być ten artykuł.

Ołomuniec  źródło: https://en.wikipedia.org/wiki/Olomouc
Ołomuniec źródło: https://en.wikipedia.org/wiki/Olomouc

W tym roku głównymi „twarzami” konferencji byli Tom Gilb, Scott W. Ambler oraz David Farley, którzy świetnie wpisali się w temat dostarczenia wartości.

Część konferencyjną rozpoczął Tom Gilb swoim wystąpieniem „Value Planning in a Lean and Agile Way for Managers”, podczas którego omawiał konieczność kwantyfikacji potrzeb interesariuszy względem każdego projektu i ich późniejszego monitorowania. Ważne, by cele postawione przed projektem, wspierały zdefiniowane mierniki. Często zapominamy o prostym fakcie – oprogramowanie nie jest odpowiedzią na każdą potrzebę, a wczesne określenie potrzeb i zestawienie ich z celami pozwala na dobranie optymalnego podejścia do rozwiązania problemu. Tom starał się maksymalnie zaangażować ludzi i trafić do swojej publiczności. Patrząc po pytaniach, które pojawiły się po jego temacie oraz zebranych oklaskach – wyszło mu to świetnie.

Tom postawił wysoko poprzeczkę dla reszty prelegentów i trzeba przyznać, że tego dnia prawie wszyscy sprostali zadaniu. Mógłbym długo pisać o świetnych wystąpieniach, których miałem okazję wysłuchać. Tutaj przytoczę tylko niektóre prezentacje, skupiając się na tych mniej oczywistych lub kontrowersyjnych z różnych względów.

Do dzisiaj w pamięci mam występ Łukasza Węgrzyna o prawnej stronie zwinnego prowadzenia projektów. Można powiedzieć, że człowiek z zewnątrz, a jednak udało mu się pożenić zawiłości prawne ze zwinnością projektów. Jego wykład pokazał tę stronę prowadzenia projektów, której często nikt nie dostrzega, czyli kontrakty i umowy, bez których niemożliwe jest rozpoczęcie jakiegokolwiek projektu. Łukasz na tym nie poprzestał prezentując przykłady obrazujące problemy, z którymi boryka się system prawny (przy okazji oberwało się prawnikom i sędziom). W tym miejscu polecę cykl artykułów, których Łukasz jest autorem „Jak pisać umowy dla projektów IT realizowanych w modelu Agile”, a w których przybliża ten „zły i wydawałoby się, że mało ciekawy świat zawiłości prawnych”.

Legal Side of Agile
Legal Side of Agile źródło: twitter.com

Najbardziej kontrowersyjną prezentacją pierwszego dnia bezdyskusyjnie było wystąpienie Yegora Bugayenko. Mówił o przyszłości prowadzenia projektów za pomocą metody, która nazwał XDSD – eXtremely Distributed Software Development. Sama metoda jest kontrowersyjna z jednego powodu – zabrania ona bezpośredniego kontaktu osób zaangażowanych w projekt (mówiąc wprost – spotkania to kradzież!). Jedyna forma dostępnej komunikacji to ta poprzez system ticketów, dzięki czemu w XDSD nie ma silosów wiedzy. Największym zbiorem wiedzy jest sama dokumentacja. Wszystko po to, by ograniczyć wpływ czynnika ludzkiego do minimum, a efektywność pracy programistów osiągała maksima (pytanie: lokalne, czy globalne?). Programista to zasób, który można w każdej chwili wymienić bez spadku efektywności, bo przecież… projekt powinien zdobywać wiedzę, a nie ludzi. Można się z takim podejściem zgadzać, bądź nie. Yegor pokazał kilka działających przykładów, a jak coś jest szalone i działa, to nie jest szalone. Nadal mam wątpliwości do takiego modelu pracy. To jednak temat na kolejny wpis lub dyskusję w komentarzach.

Drugiego dnia konferencji było równie emocjonująco. Tym razem rozpoczął Scott W. Ambler swoim wystąpieniem o Disciplined Agile Delivery (DAD) lub Disciplined Agile 2.0 (jak kto woli). Scott opowiedział o frameworku wspierającym podejmowanie decyzji procesowych w projektach IT. DAD wspiera każdy projekt bazując na praktykach wyniesionych z innych metod zwinnych i procesów tradycyjnych starając się wyciągnąć z nich najlepsze praktyki w zadanym kontekście. Zdanie, które utkwiło mi najmocniej to:

Powtarzalne rezultaty są o wiele ważniejsze od powtarzalnych procesów.

Trzeba przyznać, że Scott wykonał kawał dobrej roboty starając się wprowadzić słuchaczy w całą koncepcję. Nie będę zaskoczony, jeśli zainspirował do eksperymentowania chociaż część publiczności.

Disciplined Agile Delivery
Disciplined Agile Delivery

Jeśli o eksperymentach mowa, to dzień zakończyło wystąpienie kolejnej wybitnej osobistości – Dave’a Farleya. Dave mówił o potrzebie ciągłego eksperymentowania w celu uzyskania najlepszych wyników lub po prostu wyników pozwalających na osiągnięcie sukcesu. Całą prezentację ubrał w mnóstwo błędów poznawczych oraz zagadek, które miały za zadanie zaprezentować publiczności pułapki myślowe. W sumie, to nie można było się spodziewać mniej od autora książki Continuous Delivery, którą miałem okazję wygrać (z podpisem autora!). Jego wystąpienie kończyło część główną konferencji.

Farley's Three Laws
Farley’s Three Laws źródło: twitter.com
Continuous Delivery - David Farley, Jez Humble
Continuous Delivery – David Farley, Jez Humble

Prócz powyższych dwóch panów, tego dnia znalazłem jeszcze dwa wystąpienia, które zapadły mi w pamięć. Pierwsze należało do Olliego Pietikäinena, który opowiadał o sposobie komunikacji z różnymi interesariuszami z wykorzystaniem modelu SCARF. Model SCARF obejmuje pięć parametrów (pozycja – Status, pewność – Certainty, autonomia – Autonomy, przynależność – Relatedness oraz sprawiedliwość – Fairness), które mają wpływ na reakcję osoby w stosunku do sytuacji, z jaką się mierzy, a to przekłada się na podejmowanie decyzji i motywację do działania. Zrozumienie tych reakcji jest bardzo ważne i wpływa na pozytywne budowanie relacji, nie tylko z interesariuszami, ale na co dzień.

Drugie wystąpienie, które miało na mnie pozytywny wpływ, to wystąpienie mojego kolegi – Pawła Nowaka (http://nowy.me). Paweł opowiadał o budowaniu relacji na linii UX Designer – Product Owner. Opowiedział o różnych kontekstach współpracy tych dwóch osób oraz o tym, czego każdy z nich może się nauczyć dzięki kooperacji i wzajemnemu zrozumieniu. Sama prezentacja nie była może idealna, ale… w głowie utkwiła mi dyskusja podczas pytań do prelegenta. Paweł powiedział jedną ważną rzecz.

Realizacja każdego systemu, który ma zastąpić obowiązki człowieka, powinna równocześnie wspierać lepsze wykorzystanie umiejętności tej jednostki.

Bardzo często zapominamy o tej prawdzie w naszym, nastawionym na zysk, świecie.

UX Designer meets Product Owner - how to set up successful cooperation
UX Designer meets Product Owner – how to set up successful cooperation źródło: twitter.com

Po zakończonej części wykładowej, pozostały dwa dni warsztatów, czyli część bardziej praktyczna. W tym roku nie miałem okazji w nich uczestniczyć, ale co się odwlecze, to nie uciecze – może za rok.

Sama konferencja, to nie tylko wystąpienia, czy warsztaty, ale także, a może przede wszystkim networking. W tym roku oficjalne okazje ku temu były dwie – kręgle, które odbywały się dzień przed konferencją oraz spotkanie w restauracji między pierwszym, a drugim dniem wykładowym. Poza tym każdy z prelegentów był dostępny także podczas całej konferencji w kuluarach, więc okazji do rozmowy było co niemiara. Podczas takich rozmów można było się także sporo ciekawych rzeczy dowiedzieć. Nie tylko tych ze świata Agile, ale także historii – np. tego, że Tom Gilb miał okazję wykładać w latach 70-tych w Katowicach w ramach Programu Wymiany Naukowej między państwami NATO i Układu Warszawskiego (takie rzeczy tylko na Agilii!).

Konferencja zasługuje na uwagę. Mimo, że od zakończenia konferencji minęły już dwa tygodnie, ja nadal o niej myślę i odkrywam w notatkach nowe treści. Dla mnie jest to aktualnie jedna z najlepszych konferencji w Środkowej Europie. Michal Vallo z roku na rok wykonuje coraz lepszą robotę. Nikt nie powinien tej konferencji opuścić w przyszłym roku – a planowana jest także w Ołomuńcu, więc niebywała okazja dla całego południa Polski na posłuchanie, co bracia z Czech mają nam do zaserwowania.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

7 poziomów delegowania

delegation_7

Samoorganizujący się zespół to pojęcie, które jest obecnie bardzo popularne w branży IT. W teorii oznacza to grupę osób, która chce osiągnąć wspólny cel i ma ku temu możliwości w organizacji (jest uprawomocniona to podejmowania decyzji samodzielnie). W praktyce osoby, które wcześniej nie miały możliwości pracować w takim zespole, mogą czuć się zagubione i obciążone odpowiedzialnością, która na nich spoczywa. Co więcej, nie bardzo wiedzą, w jaki sposób maja się same organizować. Można powiedzieć, że dojrzałość takiego początkującego zespołu jest dość niska i przed liderem stoi zadanie budowania umiejętności samoorganizacji w całym zespole. Cel ten może być realizowany poprzez umiejętne i stopniowe delegowanie odpowiedzialności na zespół i w dzisiejszym poście chciałbym przedstawić Wam, jak można to wykonać w praktyce.

Dlaczego delegujemy?

Idea samoorganizujących się zespołów umocniła się razem z zwinnymi metodykami i teorie złożoności (Complexity Theory) wskazują, że jest to najbardziej efektywny sposób na osiąganie celów we współczesnych organizacjach. Stawia to zespoły przed wyzwaniem, polegającym na nauczeniu się tego, w jakich obszarach i z jakimi prawami mogą się one poruszać. Jeśli pozostawimy zespół sam sobie, to będzie on musiał metodą prób i błędów odkrywać swoje prawa i granice. Będzie to nieefektywne i zrodzi zapewne frustrację w całym zespole. Dlatego właśnie lider, który zna daną organizację i kontekst projektu, powinien stopniowo odkrywać ten świat przed zespołem (delegowanie będzie oznaczało oddawanie władzy / decyzyjności zespołowi, przy jednoczesnym braniu odpowiedzialności za otrzymany obszar przez zespół).

7 poziomów delegowania

Spośród wielu różnych teorii i modeli delegowania warto rozważyć 7 poziomów delegowania, które opracował Jurgen Appelo. Idea ta opiera się na zdefiniowaniu obszarów decyzyjnych i ustanowieniu poziomu delegowania dla każdego z takich obszarów. Co ważne, jest to delegowanie między dwoma stronami, czyli na przykład lider – zespół. Przez obszar decyzyjny rozumiemy obszary typu: godziny pracy, technologie, UX, architektura, urlopy itp. Nie stosujemy tych poziomów do indywidualnych / pojedynczych zadań.

Poziomy, które będą stosowane to:

  1. Powiedz: Podejmujesz decyzję za innych i możesz wyjaśnić swoją motywację, ale nie musisz.
  1. Sprzedaj: Podejmujesz decyzję za innych i starasz się im uzasadnić swój wybór. Chcesz, aby czuli się włączeni w ten proces.
  1. Skonsultuj: Bierzesz pod uwagę opinię innych osób i w oparciu o nią podejmujesz decyzję.
  1. Uzgodnij: Bierzesz udział w dyskusji z innymi i razem osiągacie porozumienie oraz podejmujecie wspólnie decyzję.
  1. Doradź: Oferujesz innym swoją opinię, ale to nie Ty podejmujesz decyzje.
  1. Zapytaj: Zostawiasz decyzję innym i gdy już zostanie ona podjęta, to prosisz o wyjaśnienie ci jej.
  1. Oddaj: Zostawiasz decyzję innym i nie chcesz wiedzieć nic o szczegółach.

 

W przeciwieństwie do przywództwa sytuacyjnego, 7 poziomów delegowania jest modelem symetrycznym i działa w obu kierunkach. Poziom 2 (uzasadnianie swojej decyzji) jest odpowiednikiem poziomu 6 (wysłuchanie uzasadnienia), widzianego z przeciwnej strony. Podobnie poziom 3 (jawne pytanie o opinię), jest odwrotnością poziomu 5 (oferowanie swojej opinii).

Tablica delegowania (Delegation Board)

Bardzo przydatnym narzędziem wizualizacji naszych ustaleń w temacie delegowania jest tablica delegowania. Może przyjmować ona formę zwykłej fizycznej tablicy czy też arkusza w Excelu. Ważne, żeby była ona dostępna dla każdej osoby w zespole i abyśmy nie zapominali o aktualizowaniu jej co jakiś czas. Sama tablica jest bardzo prosta i składa się z kolumny zawierającej strefy decyzyjne oraz kolumn opisujących poziomy delegowania (1,2, …,7). Dla każdej ze stref przypisany jest w formie znacznika wybrany poziom delegowania. Tablica informuje o tym, które obszary decyzyjności i na jakim poziomie ktoś oddelegowuje innym. Przykładowa tablica, gdzie lider rozpoczyna pracę z nowym, niedoświadczonym zespołem:

 

Powiedz
[1]
Sprzedaj
[2]
Skonsultuj
[3]
Uzgodnij
[4]
Doradź
[5]
Zapytaj
[6]
Oddaj
[7]

Godziny pracy

  X          
Technologie         X    
Terminy   X        

 

Ta sama tablica po jakimś czasie – zespół nabrał doświadczenia, jest coraz lepszy w samoorganizacji:

 

Powiedz
[1]
Sprzedaj
[2]
Skonsultuj
[3]
Uzgodnij
[4]
Doradź
[5]
Zapytaj
[6]
Oddaj
[7]

Godziny pracy

     X      
Technologie          X  
Terminy        

 

Tablica delegowania pokazuje kluczowe obszary decyzyjności oraz ukształtowanie władzy w systemie – tym samym pokazuje jasne granice i odpowiedzialności, co jest niezbędne do kształtowania się samoorganizacji. Jest także przydatnym narzędziem w sytuacji wdrażania nowych osób, na przykład przy zwiększaniu się zespołu.

 

Słowem podsumowania

W mojej ocenie zastosowanie 7 poziomów delegowania to bardzo skuteczny i przejrzysty sposób na stopniowe wdrażanie samoorganizacji w zespołach. Poprzez odpowiednią implementację tej metody (wizualizację, aktualizację i transparentność) możemy skutecznie krok po kroku kształtować zwinne i efektywne zespoły.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Podsumowanie pierwszego roku

anniversary

Właśnie mija rok od pierwszego oficjalnego posta na blogu.

Pewnie powtórzę to, co często czytacie, ale… Zupełnie nie wiem, kiedy ten czas tak szybko upłynął. Nie zdawałem sobie sprawy, że to już dwanaście miesięcy i ponad dwadzieścia postów. Poniżej wszystkie artykuły, które pojawiły się do tej pory według popularności (od najbardziej do najmniej popularnych):

Jak zostałem Mojżeszem Agile

7 powodów, dla których Slack po prostu daje radę

Czego uczy Agile o… zarządzaniu ryzykiem

Dyskusje w formule Open Space

Scrum i spotkanie planujące. Rób to dobrze!

The Culture Map, czyli o skutecznej komunikacji

Co jest najważniejsze w rozmowie jeden na jeden

Czynnik ludzki w praktyce

Syndrom Mail Managera

Agile Silesia #8

Kto odpowiada za rozwój

Jak udzielać dobrego feedbacku

Czego Rule of Three uczy o podejmowaniu decyzji

Czynnik ludzki stale aktualny

O czym pamiętać przy zwiększaniu liczebności zespołu

Agile Silesia #10

8 cech dobrego lidera

Kudo Cards w praktyce

Pomodoro, czyli zadania o smaku pomidora

Co zapamiętam z tegorocznej Agilii

Już wkrótce Quality Excites

 

Jeżeli nie mieliście okazji odwiedzać bloga od samego początku, to liczę, że znajdziecie powyżej coś dla siebie.

Nie chcę Was zanudzać i powiem tylko, że w przygotowaniu są kolejne posty. Oczywiście zachęcam także do polubienie strony na facebooku, przesyłania linków znajomym i po prostu korzystania z wiedzy, którą się z Wami ja oraz inni autorzy dzielimy.

Dziękuję Wam za ten rok!

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Czynnik ludzki w praktyce

firma_czynnik_ludzki

Misja firmy, w której pracuję, brzmi „Great software because we put People first” i nasze działania pokazują, że nie jest to tylko slogan. Hasło „put People first” oznacza dla nas traktowanie wszystkich osób z organizacji w sposób wyjątkowy. Obdarzamy ludzi zaufaniem i dajemy im wolność wyboru oraz odpowiedzialność za podejmowane decyzje. Jednocześnie staramy się tworzyć takie miejsce pracy, w którym ludzie będą się po prostu czuli dobrze. Dziś chciałbym przedstawić Wam w szybkim skrócie moje obserwacje z ponad dziesięciu lat spędzonych w naszej organizacji i drogę do odkrywania naszej misji. Zanim zaczniemy, chciałbym tylko dodać, że moim celem nie jest promowanie samej firmy (stąd nie podaję nazwy, chętni mogą dość szybko ją odnaleźć na blogu), ale pokazanie, że „Czynnik ludzki” może działać w praktyce i naprawdę można stworzyć wyjątkowe miejsce pracy, w którym ludzie czują się po prostu dobrze.

Gotowi? No to zaczynamy!

Gdy dołączałem do firmy w 2004 roku, dysponowała ona tylko małym biurem w Katowicach, które służyło nie tyle, jako miejsce pracy, co spotkań. Pracowaliśmy zdalnie i spotykaliśmy się albo w biurze, albo w domu szefa i właściciela firmy. Nie mieliśmy wtedy zdefiniowanych wartości, misji czy wizji, po prostu tworzyliśmy soft, pomagaliśmy sobie wzajemnie w codziennej pracy. Ufaliśmy, że każdy robi dobrze swoją robotę i na tym zaufaniu budowaliśmy firmę. Oczywiście łączyła nas pasja do tworzenia oprogramowania i rozwiązywania trudnych problemów.

Klienci doceniali naszą pracę, zaczęły pojawiać się kolejne zapytania i dość szybko staliśmy się firmą liczącą już nie dziesięć, a kilkadziesiąt osób. W międzyczasie powstało nasze własne biuro, gdzie mogliśmy już pracować na co dzień. Dość szybko okazało się jednak, że to pierwsze własne biuro nie wystarczy na nasze rosnące potrzeby i ostatecznie przenieśliśmy się do Gliwic. Byliśmy młodą firmą, wielu z nas studiowało lub dopiero co skończyło studia i szukaliśmy osób o podobnym profilu. Wtedy też pojawiły się pierwsze konsole do grania czy piłkarzyki. Zmieniła się lokalizacja naszego biura, nie zmieniło się podejście. Stawialiśmy na zaufanie względem ludzi (nie kontrolowaliśmy czy, kto i ile gra). Każdy miał prawo pracować zarówno z biura, jak i zdalnie. Każdy miał prawo korzystać z dodatkowych atrakcji w biurze. Rozumieliśmy, gdy ktoś miał trudny egzamin na studiach i nie był w stanie się w pełni angażować w pracę. Uważaliśmy, że ludzie wiedzą, jak sobie poradzić z otrzymanym kredytem zaufania i potrafią zarządzać swoim czasem. To się sprawdziło i firma w dalszym ciągu się rozwijała i pozyskiwała nowych klientów.

Upłynęło kilka lat i staliśmy się firmą kilkusetosobową. Te kilka lat zmieniło także w pewnym stopniu nas samych. Wielu z nas założyło rodziny, pojawiły się pierwsze dzieci. Do firmy przyszło także wiele osób doświadczonych, mających inne spojrzenie na świat niż wielu z nas. Piłkarzyki i konsole zostały z nami, ale pojawiły się inne formy wsparcia pracowników – imprezy dla rodzin z dziećmi i przedszkole dla dzieci. Dla wielu z nas było to olbrzymie udogodnienie. Nie musieliśmy tracić czasu na transport po mieście z i do przedszkola. Jednak dla mnie osobiście największym plusem był i wciąż jest fakt, że cały czas jestem blisko swoich dzieci i mogę uczestniczyć we wszystkich wydarzeniach, które dla nas są ważne – występy, jasełka, św. Mikołaj, dzień rodziny czy dzień babci i dziadka. Nikt nie odlicza rodzicom czasu spędzonego w przedszkolu. Podobnie jak nikt nie mierzy czasu spędzonego na piłkarzykach czy siłowni  (mamy też saunę, zjeżdżalnię i wiele innych rzeczy…). Nasze podejście do ludzi jest niezmienne – sprawiać, by ludzie czuli się dobrze w pracy i pozostawić im wolność wyboru.

Chciałbym także dodać, że zaufanie oznacza dla nas to coś więcej niż tylko dawanie swobody wyboru. To także bycie transparentnym we wszystkim, co dotyczy całej organizacji. Niezależnie do tego czy jest dobrze, czy źle, dzielimy się z ludźmi informacjami. Nie zawsze jest to łatwe i przyjemne. Nie jesteśmy nieomylni i popełniamy błędy, ale mamy też odwagę o nich mówić i przyjmować feeback od naszych ludzi. Robimy tak dlatego, że ufamy sobie nawzajem.

 

Chciałem tym postem przedstawić Wam pewien wycinek naszej filozofii i kultury organizacji. Mam nadzieję, że przy okazji udało mi się także Wam pokazać, że wszelkie dodatkowe atrakcje w pracy (jakże popularne teraz zwłaszcza w świecie firm IT), nabierają znaczenia dopiero wtedy, gdy powiążemy je z tym, czemu mają służyć i jakie motywy kierują organizacją, która je wprowadza.

Mam swoje obowiązki w pracy, mam też rodzinę i mogę łączyć te rzeczy – mi osobiście taki model odpowiada i chętnie korzystam z tego, co firma mi oferuje. Rozumiemy także osoby, które zdecydowanie wolą oddzielać pracę od reszty życia. Dla mnie kluczowe jest to, że każdy z nas może wybierać. Jestem w firmie od wielu lat. Nie wiem, czy będzie to firma, w której spędzę całe swoje życie zawodowe. Wiem jednak, że jest to miejsce wyjątkowe i autentyczne, w którym „Czynnik ludzki” po prostu działa.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

O czym pamiętać przy zwiększaniu liczebności zespołu

hands-565603_1920

Jednym z istotnych czynników decydujących o wyborze firmy dostarczającej oprogramowanie jest możliwość skalowania zespołu – zarówno w dół, jak i w górę.

Pokazuje to, że tworzenie oprogramowania to proces nauki i bardzo często nie jesteśmy w stanie przewidzieć wszystkich zdarzeń, które wpłyną na projekt, w tym z góry zaplanować stały skład zespołu przez cały czas trwania projektu.

Dziś chciałbym Wam przybliżyć ten temat i pokazać, jakie są ryzyka związane z zwiększaniem liczebności zespołu oraz wskazać możliwe działania pozwalające na zarządzanie tymi ryzykami.

 

Zacznijmy od krótkiego przypomnienia definicji liczby Dunbara, która wskazuje na nasze ograniczenia poznawcze – przeciętnie człowiek jest w stanie utrzymać relacje z maksymalnie 150 osobami.

Moim zdaniem poza liczbą Dunbara warto także przywołać prawo Brooksa, które mówi, że dodanie kolejnych ludzi do opóźnionego projektu opóźnia go jeszcze bardziej. Powodowane jest to przez następujące czynniki.

  • Czas wdrożenia – nowe osoby muszą najpierw zrozumieć projekt, poznać ludzi i środowisko i tym samym same nie są w stanie od razu wnieść wartości, a spowalniają innych.
  • Chaos komunikacyjny – liczba kanałów komunikacyjnych wzrasta wraz ze wzrostem liczby osób w projekcie, zgodnie z wzorem:

kanaly_komunikacji

 

kanaly_komunikacji

  • Zaburzenie stanu zespołu – dołączenie nowych członków prowadzi do wybicia z rytmu ukształtowany już zespół i wymusza ponowne przejściu cyklu Tuckmana.
  • Niepodzielność zadań – czynnik związany z typem zadań – nie wszystkie zadania da się zrównoleglić i podzielić na wszystkie osoby w projekcie.
  • Spadek jakości – nowe osoby mogą nieświadomie wprowadzać błędy, jednocześnie aktualni członkowie zespołu są pod większą presją i mogą popełniać więcej błędów (poświęcanie swojego czasu na wdrożenie nowych osób kosztem realizowania swoich zadań na dotychczasowym poziomie).

 

W praktyce oznacza to, że zanim zdecydujemy się zwiększanie liczebności zespołu, warto upewnić się, jakie niesie to za sobą ryzyka i czy są możliwe inne rozwiązanie niż „dorzucanie ludzi”. Jeśli natomiast zwiększanie liczebności zespołu to jedyna opcja, to zastanówmy się jak to wpłynie na proces i jakie zmiany wprowadzić, aby zminimalizować wpływ negatywnych czynników. Możliwe działania:

  • Przydzielenie indywidualnego opiekuna nowej osobie.
  • Zapewnienie istnienia aktualnej dokumentacji ułatwiającej wdrożenie (FAQ itp.).
  • Częste spotkania lidera z nowymi osobami w celu szybkiego wykrywania i naprawiania wszelkich przeszkód pojawiających się przy wdrożeniu.
  • Aktualizacja istniejących lub wprowadzenie nowych mierników pozwalających ocenić wpływ oraz trendy po pojawieniu się nowych osób w zespole.
  • Obserwowanie zespołu po zmianie i szybkie reagowanie w razie potrzeby.
  • Przygotowanie zespołu do zmiany, zbudowanie odpowiedniej atmosfery dla zmiany.
  • Podzielenie zespołu na dwa mniejsze.

Przy okazji tematu zwiększania zespołu pojawia się często pytanie o optymalną wielkość zespołu. Wielu z nas spotkało się zapewne z stwierdzeniem, że najbardziej optymalna liczba członków zespołu zawiera się w przedziale 5 do 9 osób. Moim zdaniem nie powinniśmy się zbytnio przywiązywać do tej liczby. Jakość funkcjonowania zespołu nie zależy bowiem tylko od jego wielkości – jest to tylko jeden z wielu czynników.

Naszym zadaniem jest upewnianie się, że nasz proces oraz struktura zespołu jest odpowiednia i pozwala optymalnie realizować cele stawiane zespołowi.

Gdy będziemy o tym pamiętać, to poradzimy sobie w każdej sytuacji, także w przypadku nagłego wzrostu liczby osób w naszym teamie.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Czynnik ludzki stale aktualny

czynnik_ludzki

Po raz pierwszy czytałem Czynnik ludzki 10 lat temu i postanowiłem sięgnąć do tej książki ponownie. Mimo upływających lat mam przekonanie, że wciąż wiele zasad, o których pisze DeMarco i Lister, jest aktualnych i każdy lider powinien je znać.

  1. Prawo Parkinsona to mit

Prawo Parkinsona mówi, że praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie.

Niemal każdy z nas słyszał pewnie o tym prawie i wielu z nas przyjmuje je za pewnik. Tymczasem jest to mit, który można odnosić to pracy administracyjnej, ale nie do pracy twórczej. Można powiedzieć, że Ilość pracy administracyjnej zwiększa się po to, żeby wypełnić dzień pracy. Jednak w przypadku osób wykonujących pracę twórczą to prawo nie ma zastosowania. Osobiście uważam, że wszędzie tam, gdzie motywacja jest na odpowiednim poziomie (zgodnie z tym, co podaje Pink), prawo to nie istnieje.

  1. Entropia i chaos

Entropia to miara stopnia nieuporządkowania układu, zanikania różnic w układzie. Im większa entropia, tym mniej energii możemy wygenerować. Z organizacjami jest podobnie. Po pewnym czasie organizacja staje się co prawda bardziej uporządkowana, ale też przez to zbyt jednolita i ociężała.

Co więcej, fakt dążenia organizacji do pewnej jednorodności sprawia, że dwie osoby z jednej firmy mają na ogół podobną wydajność. Oznacza to, że na przykład najbardziej wydajni programiści zbierają się w jednej firmie, a najmniej wydajni w drugiej. Przewidział to zjawisko Harlan Mills w 1981r.

Autorzy zwracają także uwagę na postrzeganie chaosu.

Jest coś w naturze ludzkiej, co robi z nas nieprzejednanych wrogów chaosu. Gdy tylko natrafimy na chaos, podwijamy rękawy i bierzemy się do pracy, żeby go zastąpić porządkiem. Porządek wprowadzony przez człowieka panuje wszędzie… w domu, ogrodzie, uczesaniu. Nie oznacza to wcale, że będziemy bezgranicznie szczęśliwi, jeżeli nie będzie już chaosu. Przeciwnie – będziemy bezgranicznie znudzeni. Resztki chaosu pozostałe w nowoczesnym społeczeństwie są cennym dobrem.

Myślę, że o chaosie będzie jeszcze okazja na blogu napisać, na dziś krótko w nawiązaniu do bycia liderem – nie zakładajmy, że wszystko wokół nas musimy koniecznie uporządkować i jest to naszym głównym zadaniem. Chaos jest nam potrzebny.

  1. Inwersja i analogia

Każdy z nas zetknął się pewnie z sytuacją, gdy zabrakło mu pomysłu na rozwiązanie jakiegoś problemu. Autorzy książki podają możliwe sposoby na wybrnięcie z takiej sytuacji.

Inwersja – jeśli przy rozwiązywaniu jakiegoś problemu utknąłeś w martwym punkcie, to zamiast zastanawiać się jak osiągnąć cel, pomyśl jak doprowadzić do czegoś przeciwnego (pomysł zaczerpnięty z książki „Myślenie równoległe” Edwarda deBono).

Analogia – znajdź podobny problem (np. w przyrodzie) i sprawdź jego rozwiązanie. Następnie postaraj się dostosować je do własnego przypadku.

 

Na koniec jeszcze kilka złotych myśli do rozważenia.

Ludzie pod presją czasu nie pracują lepiej, a jedynie szybciej.

Jakość jest za darmo, ale tylko dla tych, którzy są gotowi drogo za nią zapłacić.

Jest milion sposobów na to, żeby stracić dzień pracy, ale nie ma ani jednego na odzyskanie go.

 

Dziś wybrałem dla Was tylko niewielką część „Czynnika ludzkiego” i jeśli nie mieliście jeszcze okazji sięgnąć po tę lekturę, to naprawdę gorąco Was do tego zachęcam – zwłaszcza, że nie napisałem nic o policji meblowej czy zespole testerów siejącym postrach wśród wszystkich programistów…

Jestem przekonany, że znajdziecie tam sporo uniwersalnych reguł, którymi warto kierować się w swojej codziennej pracy.

 

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

8 cech dobrego lidera

leadership

Niemal dwa lata temu w grudniowym wydaniu magazynu Harvard Business Review ukazał się bardzo ciekawy artykuł na temat roli managerów w Google oraz oczekiwań inżynierów wobec osób na tych stanowiskach.

Okazało się, że inżynierowie w pierwszej kolejności nie tolerują mikrozarządzania, jednocześnie bardzo potrzebują wsparcia w obszarze rozwoju oraz kariery i właśnie tym aspektem w szczególności powinni zajmować się liderzy.

Dalsze badania (realizowane poprzez różne eksperymenty) wykazały już nieco bardziej szczegółowo, że najlepsi managerowie w Google to osoby o następujących cechach (kolejność od najważniejszej do najmniej ważnej):

  1. Good Coach
  2. Empowers the team and does not micromanage
  3. Express interest in and concern for team members’ success and personal well-being
  4. Is productive and results-oriented
  5. Is a good communicator – listens and shares information
  6. Helps with career development
  7. Has a clear vision and strategy for the team
  8. Has key technical skills that help him or her advise the team​​

Inżynierowie cenią wobec tego osoby, które mają doświadczenie związane z wytwarzaniem oprogramowania (technical skills), ale nie jest to kluczowa cecha. Zdecydowanie wyżej są umiejętności miękkie oraz rzeczywiste wsparcie dla każdej osoby z zespołu.

W wyniku tych analiz Google wie, jakich managerów im potrzeba oraz jakie obszary pracy i postawy należy mierzyć. Każdy manager jest oceniany przez swój zespół i następnie wraz z swoim przełożonym w oparciu o zebrane dane planują działania rozwojowe.

W moje ocenie możemy przyjąć, że wnioski z tego artykułu dotyczą nie tylko inżynierów, ale duże szerszej grupy osób, której praca polega na tworzeniu, przekładaniu swojego potencjału na realizację konkretnych rozwiązań (praca twórcza). Uważam również, że każda organizacja musi sama sobie odpowiedzieć na pytanie, jakich liderów potrzebuje, a następnie wdrożyć mechanizmy (np. feedback dla liderów od zespołów), które zapewnią, że te oczekiwania będą spełniane.

 

Image credit: (c) photosteve101, Creative Commons 2.0

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Jak udzielać dobrego feedbacku

mark-804935_1280

Feedback jest jednym z najbardziej popularnych zapożyczeń, które weszły już na stałe do naszego codziennego życia w organizacji. Feedback z definicji oznacza sprzężenie zwrotne mające na celu dostarczenie informacji, która pozwoli skorygować wcześniejsze błędy. W praktyce nazywamy czasem to działanie przekazywaniem informacji zwrotnej.

Sposoby przekazywania feedbacku mogą być różne i jednym z najczęściej wymienianych przez liderów jest tak zwana kanapka feedbackowa, która sprowadza się do tego, że przeplatamy informacje pozytywne i negatywne. Moim zdaniem nie jest to idealne rozwiązanie i chciałbym dziś zwrócić Waszą uwagę na to, czym powinien cechować się dobry feedback oraz pokazać schemat takiego feedbacku.

KIEDY?

Dobry feedback to taki, który jest udzielany na czas – mówiąc wprost – SZYBKO. Jeśli jakieś zdarzenie zwraca naszą uwagę i wymaga feedbacku, to powinniśmy od razu go udzielić.

KOMU?

Informacja zwrotna powinna być przekazywana prywatnie. Dotyczy zwykle konkretnej osoby i tylko ta osoba powinna uczestniczyć w tym procesie. Oczywiście zdarzają się sytuacje, które mogą stanowić wyjątek od tej reguły.

 CO?

Opisujemy zachowania i / lub wyniki działań danej osoby (w konkretnym kontekście), nie wyrażamy opinii o danej osobie. Przykład ilustrujący różnicę:

Dobrze: Dla zdania ‘X’ pominąłeś trzy elementy przy sprawdzaniu i w efekcie system nie zadziałał prawidłowo.

Źle: Pracujesz bardzo niestarannie i ciągle pomijasz coś przy testowaniu.

Więcej o samej treści feedbacku w dalszej części tego posta.

ILE?

Słuchamy – feedback to nie monolog. Osoba, której go udzielamy, może mieć swoje zdanie i swój punkt widzenia na daną sytuację i warto go poznać.

 

Jak wobec tego może wyglądać schemat dobrego feedbacku?

Prosty i moim zdaniem bardzo trafiony wzór na dobry feedback można znaleźć w książce Jurgena Appelo #Workout. Oto przepis.

  1. Opisz swój kontekst.
  2. Uporządkuj swoje obserwacje.
  3. Wyraź swoje emocje.
  4. Uszereguj według wartości dla Ciebie.
  5. Zakończ sugestiami.

Stosując ten wzór możemy nie tylko udzielić dobrego feedbacku podczas bezpośredniego spotkania, ale także w formie pisemnej, co przy dzisiejszym trybie pracy oraz trendzie na pracę zdalną, jest dodatkową zaletą tej metody.

Jeśli połączymy ten przepis z wskazówkami podanymi w pierwszej części tego artykułu (kiedy, komu, co, jak), to mamy gotowy mechanizm udzielania feedbacku.

 

Drogi Czytelniku!

zapisz_mnie

Jeśli chciałbyś otrzymać przykład feedbacku udzielonego zgodnie z podanym powyżej przepisem, to po prostu zapisz się do newslettera na tym blogu. Zapraszam:)

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Kto odpowiada za rozwój

Knowledge
image: (c) Pootar

Bardzo często przy okazji rozmów między liderami pojawia się temat rozwoju i tego, kto jest za niego odpowiedzialny – czy lider danej osoby, czy może ta osoba? Prawda w tym przypadku leży po środku – obie strony mają w tym obszarze swoje obowiązki do wypełnienia.

Obie strony są odpowiedzialne za rozwój

Lider inicjuje i wspiera rozwój poprzez regularne rozmowy jeden na jeden. Szuka także możliwości rozwojowych dla danej osoby i upewnia się, że plany rozwojowe są związane z jej codzienną pracą.

Obie strony weryfikują, czy cele rozwojowe są ważne i wciąż mają sens. Jeśli tak, to razem oceniają postępy w ich osiąganiu. To w dużej mierze od danej osoby zależy, czy i w jakim kierunku chce się rozwijać.

Co robią dobrzy liderzy?

Dobry lider wie, że warto wspierać rozwój ludzi i możliwość osiągania prze nich celów, gdyż zwiększa to możliwości jego zespołu, działu czy całej organizacji. Takie wsparcie pokazuje ludziom, że nam na nich zależy i nie dbamy tylko o wyniki ich pracy tu i teraz. Co wobec tego robi lider:

  • Rozumie swoich ludzi i wie, czego chcą
  • Tworzy razem z nimi plan działań i monitoruje jego realizację
  • Szuka możliwości rozwojowych
  • Nie blokuje ludzi
  • W razie potrzeby tworzy plan przejścia / zmiany roli i wspiera jego realizację
  • Oddziela temat rozwoju od oceny okresowej
  • Pełni rolę nauczyciela, mentora lub coacha (w zależności od posiadanych umiejętności i kontekstu)

W praktyce oznacza to, że trzeba poznawać swoich ludzi, uczyć się tego, co jest dla nich ważne, w czym są mocni, a z czym mają problemy. Gdy zachodzi potrzeba, lider pozwala ludziom pójść dalej (spróbować czegoś innego), nawet jeśli w danym momencie nie jest mu to na rękę.

Czy rozwój ma mieć miejsce w pracy?

Drugim popularnym pytaniem związanym z rozwojem jest doprecyzowanie tego, czy rozwijać się można tylko w pracy czy może poza nią? W idealnej sytuacji rozwój ma miejsce w pracy. Lider powinien szukać takich opcji i szans, które pozwolą na to, aby połączyć pracę z rozwojem.

Z drugiej strony każdy z nas jest odpowiedzialny za swój los i swoją karierę. Pozwolę sobie zacytować Roberta C. Martina (znanego jako Uncle Bob)

Your career is your responsibility, do not leave it up to your employer to train you, send you on courses or buy you books. Take control of yourself.

The time you spend at work should be spent on your employers problems, not yours. A professional works hard for his employer and makes time for his ‚career’ in his own time. This also doesn’t mean you should spend all your time on your career. You have a family/life too. Balance your work, your career and your life in appropriate measures.

To w dużej mierze od każdego z nas zależy własny rozwój i w pierwszej kolejności powinniśmy sami się o niego troszczyć, a następnie korzystać ze wsparcia lidera (czy całej organizacji).

Słowem podsumowania

Jako liderzy powinniśmy wspierać rozwój naszych ludzi.  Z drugiej strony mamy także prawo oczekiwać, że ludzie sami troszczą się i dbają o niego. Obie strony powinny brać odpowiedzialność za ten obszar.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Co jest najważniejsze w rozmowie jeden na jeden

Efektywne spotkania jeden na jeden pozwalają na poruszanie się w kilku obszarach i stwarzają przestrzeń na dawanie feedbacku, dyskusję o aktualnym stanie prac, rozmowę o planach rozwojowych, a dla doświadczonych i odpowiednio przygotowanych liderów także możliwość coachingu dla rozmówcy.

one on one
image: (c) Hansel Teo

Jak możemy zwiększyć efektywność naszych spotkań?

Przede wszystkim powinniśmy zacząć od określenia tego, jak będą wyglądały nasze regularne spotkania (forma, zasady) i co chcemy na nich omawiać (plan, treść). Gdy zestawiamy te elementy razem, mamy naszą strukturę efektywnych spotkań jeden na jeden. Poniżej znajdziecie kilka wskazówek dotyczących zarówno formy spotkań, jak i ich treści.

Zasady – ustal zasady, które będą przestrzegane przez Ciebie i pozwolą na efektywne spotkanie. Przykładowo możesz:

  1. Określić rytm spotkań (co 2 tygodnie, poniedziałek o 10.00 w Sali 10, 30 minut na spotkanie)
  2. Ustalić, że obie strony są zawsze przygotowane na spotkanie.
  3. Trzymać się ustalonych terminów – nie przesuwasz, nie anulujesz spotkań (to pokazuje, że są one ważne dla ciebie i szanujesz rozmówcę).
  4. Trzymać się (zwykle) tego samego planu, dzięki czemu spotkania nie będą zaskoczeniem.
  5. Być elastycznym – trzymanie się planu nie oznacza, że w ważnych przypadkach należy go przestrzegać za wszelką cenę. Być może jakiś temat dla rozmówcy będzie na tyle istotny, że zajmie cały czas spotkania.
  6. Robić notatki – pozwala nam to śledzić historię rozmów, lepiej się przygotować do spotkań oraz podejmować działania po rozmowie (wynikające z notatek)
  7. Unikać wszelkich rozpraszaczy – komórki, tablety – najlepiej wyłączyć przed spotkaniem, żeby nie rozpraszały nas w trakcie.
  8. Ustalić spójną nazwę spotkań, która będzie się jednoznacznie kojarzyła naszym rozmówcom. Przykładowo w naszej organizacji popularne są „Rozmowy przy kawie” czy „Pogadanki”.
  9. Więcej słuchać, mniej mówić – wbrew pozorom wielu liderów ma z tym problem i warto to sobie przypominać przed samym spotkaniem.

Plan – warto nakreślić plan typowego spotkania, który będzie zawierał następujące elementy:

  1. Powitanie – dobrze jest rozpocząć rozmowę od zwykłego „Cześć, co słychać?”. Dość szybko pozwoli nam to określić nastrój drugiej osoby i odpowiednio podejść rozmowy.
  2. Omówienie aktualnego stanu – czyli co się udało zrobić, czy wszystko przebiega zgodnie z planem, czy wyszły jakieś nowe rzeczy itp. W dłuższej perspektywie (wielu spotkań) będziemy coraz lepiej rozumieć, czy nasz rozmówca ma z czymś problemy, czy w jakimś obszarze wyróżnia się itp.
  3. Problemy i przeszkody – sprawdzamy, czy jest coś, co utrudnia pracę i możemy w tym pomóc.
  4. Wsparcie – pytamy, czy możemy w czymś pomóc. Pomoc może przybierać różne formy, czasem oznacza wykonanie działań z naszej strony, czasem podpowiedzenie, podzielenie się swoim doświadczeniem, a czasem po prostu wysłuchaniem drugiej osoby.
  5. Rozwój – zakładam, że jakiś plan rozwojowy między liderem i rozmówcę jest określony i regularne rozmowa to dobry moment do upewnienie się, że plan jest realizowany.
  6. Co jeszcze – warto zapytać na koniec, czy jest jeszcze jakiś temat do omówienia, czy o czymś nie zapomnieliśmy. Być może tutaj pojawi się temat, dla którego wcześniej nie było przestrzeni na spotkaniu.
  7. Podsumowanie – jeśli podczas spotkania ustalamy konkretne akcje / działania, to warto je podsumować na koniec. Dobrą praktyką jest też przesłanie po rozmowie pisemnego podsumowania (na przykład w oparciu o nasze notatki ze spotkania).
  8. Podziękowania – na pożegnanie zawsze warto podziękować za poświęcony nam czas.

Moim zdaniem stosowanie tych kilku prostych zasad pozwala na prowadzenie efektywnych spotkań jeden na jeden, a w przypadku gdy mamy wiele takich spotkań z różnymi osobami, pozwala nam to na uporządkowanie wszystkich rozmów w ramach tego samego wzorca.

Podobał Ci się artykuł? Myślisz o prowadzeniu bardziej efektywnych rozmów jeden na jeden? Zachęcam Cię do zapisania się do newslettera na stronie, dzięki czemu otrzymasz przykładowy formularz regularnej rozmowy jeden na jeden oraz informacje o kolejnych artykułach na blogu.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

7 powodów, dla których Slack po prostu daje radę!

Slack
www.slack.com

Paweł pisał ostatnio o Syndromie Mail Managera i jego sposobie na ograniczenie czasu pracy ze skrzynką pocztową. Pewnie część jego problemów by zniknęła, gdyby tylko używał w swoim projekcie / organizacji sprytnego rozwiązania, jakim jest Slack.

Slack to narzędzie, które jest obecne na rynku kilkanaście miesięcy (swój oficjalny debiut miało 12 lutego 2014 roku) i które dzięki swojej prostocie i intuicyjności bardzo szybko zaskarbiło sobie przychylność wielkich tego świata – ze Slacka korzystają tacy giganci, jak eBay, Spotify, Sony, Google, Apple, czy Microsoft (co ciekawe – Microsoft przecież posiada Yammera :) ).

Nazwać Slacka „bardzo przemyślanym komunikatorem”, to tak, jakby nazwać Porsche po prostu „bardzo szybkim samochodem”. Slack to nie tylko komunikator. To także, a może przede wszystkim, narzędzie, które usprawnia komunikację wewnątrz grupy.

Poniżej opiszę kilka przykładów, dla których dla mnie Slack jest jedynym słusznym wyborem w swojej grupie na dziś.

1. Transparentność i komunikacja – czyli mniej maili, a wszystko dostępne dla każdego

Jednym z głównych powodów, dla których warto przejść na Slacka jest ograniczenie komunikacji mailowej. Jeśli mam być szczerym, to Slack pozwolił w moim przypadku na całkowite zaprzestanie korzystania z innych komunikatorów, a od początku istnienia projektu dostałem JEDEN mail projektowy. Cała reszta komunikacji odbywała się na Slacku. Wszystko w jednym miejscu.

Okno główne programu
Okno główne programu

2. Kanały, grupy, wiadomości prywatne…

Ile razy się zdarzyło, że dostaliśmy maila, który nie miał być wysłany do nas lub część osób zaangażowania w prace, nie była do niego dołączona? Mi zdarzało się to notorycznie.
Na Slacku można stworzyć kanał, gdzie każdy zaangażowany w daną prace, może swobodnie dyskutować. Świetne rozwiązanie – cała dyskusja w jednym miejscu! Jeśli istnieje potrzeba bardziej prywatnej dyskusji, można stworzyć grupę, gdzie zaproszona zostanie tylko część zespołu, lub napisać bezpośrednią wiadomość prywatną, tak jak na Skype, Lync, czy Google Talks.
Zdarza się również, że wiadomość email ginie w gąszczu innych, przez co nadawca czeka na odpowiedź, która długo nie nadchodzi (lub nigdy nie nadejdzie). Na Slacku można wołać pojedynczych użytkowników nawet całe grupy korzystając z prefixu @. Mała rzecz, a cieszy…

3. …a wszystko dostępne z poziomu jednej wyszukiwarki

Największym problemem większości komunikatorów jest wyszukiwanie, które zwyczajnie działa tylko w zakresie pojedynczego wątku. Nawet, jeśli już wiadomo, czego szukać, to i tak jest to problematyczne. Szukanie wewnątrz skrzynki pocztowej pozostawię bez komentarza.
Slack ma bardzo fajną wyszukiwarkę, która pozwala dowolnie zmieniać zakres wyszukania dostosowując wyniki do naszych potrzeb.

Wyszukiwarka
Wyszukiwarka Slacka

4. Dzielenie się fragmentami kodu banalnie proste

Kolejnym udogodnieniem, jakie oferuje Slack, to Snippety. Dzielenie się kodem jest banalnie proste, a dodatkowo wszystkie snippety zapisywane są w Slacku w osobnym miejscu, dzięki czemu nawet powrót do nich po czasie nie sprawia żadnych problemów. Snippety, podobnie jak inne załączniki, mogą być okraszone stosownymi komentarzami, dzięki czemu nasza komunikacja staje się jeszcze bardziej uporządkowana.

Przykładowy Snippet
Przykładowy Snippet

5. Integracja – integracja wszędzie

integracja
Jedną z największych sił i zalet Slacka są integracje. Na pewno każdy użytkownik znajdzie coś dla siebie – od prostych integratorów dla notyfikacji z Trello, Jiry, Bitbucketa, SVNa, Githuba, RSS,… po bardziej skomplikowane, jak skaner dokumentów, wideokonferencje, czy dodatkowe miejsce na dokumenty. Na chwilę obecną Slack posiada 77 zdefiniowanych integratorów oraz daje możliwość pisania własnych używając bota, API, kolejek SQS, czy WebHooks (jest ich także 7 – przypadek? ;) )

Slackbot - przykład użycia
Slackbot – przykład użycia

6. Jesteś dostępny – gdziekolwiek chcesz

Slack to nie tylko aplikacja internetowa. To także szereg aplikacji przeznaczonych na różne systemy – Windows, Mac OS X, czy systemy mobilne – Android oraz iOS. Do pełni szczęścia brakuje niestety Windows Phone’a, jednak aplikacja jest już w trakcie przygotowywania i w tej chwili trwają jej beta-testy. Aplikacje te oferują identyczne możliwości, jak aplikacja webowa, a także wspierają notyfikacje, dzięki którym korzystanie ze Slacka jest jeszcze przyjemniejsze.

Aplikacje dedykowane pod różne systemy
Aplikacje dedykowane pod różne systemy

7. A to wszystko za darmo!

Slack jest narzędziem darmowym. Oczywiście w tej wersji występują pewne ograniczenia, jednak nie są one dużym kłopotem. Największym problemem jest możliwość użycia tylko 5 integratorów na raz – porównując to do ogromnego wyboru integratorów, może pojawić się pewny niesmak. Ja jednak nie dotarłem jeszcze do momentu, gdy wersja darmowa byłaby zbyt ograniczona, więc na temat wersji płatnych trudno mi się powiedzieć. Najlepiej samemu sprawdzić na https://scrabble.slack.com/pricing.

Podsumowanie

Slack to bardzo dobre narzędzie, które wspomaga komunikację na poziomie dotychczas niedostępnym. Przejście na Slacka jest bezproblemowe i już po kilku chwilach zespół zaczyna doceniać tę zmianę.
Sam Slack w swojej krótkiej historii nie przestrzegł się kilku problemów z bezpieczeństwem danych. Swego czasu publicznie dostępne były nazwy grup istniejących na Slacku, czy spory wyciek danych użytkowników (po którym wprowadzona została dwustopniowa autentykacja). Slack do swoich kłopotów podchodzi bardzo uczciwie szybko reagując na każde zgłoszenie.

Zapłacili nawet nagrodę za emotkę hamburgera, gdzie dostrzec można było ser. Nie tylko zapłacili – wykonali rzeczową analizę (patrz poniżej)! To tylko pokazuje, że potrafią pochylić się nad każdym, nawet najbardziej błahym problemem.

Slack - "krytyczny błąd sera"
Slack – „krytyczny” błąd sera (źródło: http://niebezpiecznik.pl/)
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Agile Silesia #10

agile_silesia

Dziesiąte spotkanie Agile Silesia już za nami. Mieliśmy aż trzy wystąpienia, każde w nieco innym temacie.

Kasjan Kotynia – Mój PO nie zna odpowiedzi na pytania teamu!

IMG_0236

Rozpoczął Kasjan Kotynia, który w oparciu o swoje doświadczenia w dużym, kilkuletnim projekcie, opowiadał o tym, jak można wspierać Product Ownera (PO) w jego pracy. Zwrócił uwagę, że PO też się wdraża w projekt, że czasem jest to dla niego nowa rola, że ma sporo spraw biznesowych do rozwiązania, często spędza całe dnie na delegacjach i rozmowach z klientami / użytkownikami. Ważne, żeby zespoły, organizacja i sami Scrum Masterzy mieli tego świadomość i wspierali PO – ustalali sposób, w jaki można się najefektywniej komunikować, minimalizować momenty braku dostępu do PO. Bywa też tak, że PO nie zna od razu odpowiedzi na wszystkie nasze pytania i musi jej poszukać. Czasem możemy mu w tym pomóc jako zespół deweloperski, a czasem odpowiedź leży po stronie biznesu i PO musi się najpierw rozeznać, zanim do nas wróci z konkretnymi danymi. Prezentacja Kasjana dostępna jest tutaj.

Dobry Scrum Master = Dobry Zespół Scrumowy?… czyli o samoorganizacji słów kilka

IMG_0251

Drugim prelegentem był Daniel Wicher, którego możecie już znać z poprzednich wystąpień bądź też postów na www.okiemlidera.pl lub blogu FP. W swoim wystąpieniu Daniel przedstawił nam etapy rozwoju zespołów scrumowych:

as_teams

Następnie omówił etapy rozwoju dla Scrum Mastera:

as_sm

Daniel opowiedział o każdym z tych etapów oraz o tym, jakie są kroki przejścia do kolejnych wyższych poziomów. Przygotował także macierz dopasowania poszczególnych poziomów zespołów do wybranych rodzajów Scrum Masterów, gdzie pokazał, jak dane zestawienie może zadziałać. Prezentacja Daniela dostępna jest tutaj.

Tomasz Włodarek – Skalowanie Scruma

IMG_0272

Ostatnie wystąpienie dotyczyło tematu skalowania w Agile. Tomek Włodarek bardzo sensownie podszedł do zagadnienia i starał się nam pokazać, że skalowanie nie jest łatwe i być może są inne sposoby na rozwiązanie naszych problemów.

Tomek wskazał dwie kluczowe przeszkody w skalowaniu: Komunikacja i Zależności. Przypomniał o liczbie Dunbara, która mówi, że przeciętnie człowiek jest w stanie utrzymać relacje z maksymalnie 150 osobami. Zwrócił także uwagę na prawo Conway’a, które mówi, że projektowane systemy odzwierciedlają strukturę komunikacji w organizacji. Często działa to także odwrotnie – zespoły próbują się przypasować pod powiązania systemu. Jest to o tyle istotne, że przy skalowaniu powinniśmy unikać zależności, minimalizować je wszędzie, gdzie tylko się da i uważać, żeby przypadkiem nie podzielić systemu zgodnie z strukturą organizacji, zwłaszcza, jeśli ma ona wiele zawiłych połączeń i powiązań między sobą…Cytując Tomka:

Zależności są złe.

Na koniec Tomek przedstawił nam ideę Nexusa, który opiera się na Scrumie i mówi nam, jak można stosować Scruma do skalowania. To, co warto zapamiętać to słowo INTEGRACJA – żeby skalowanie dobrze działało, to najważniejsza jest ciągła integracja na każdym poziomie, upewnianie się, że dostarczamy konkretny i widoczny inkrement, realną wartość dla użytkowników po sprincie.

Integracja w skalowaniu Scruma jest kluczowa.

Słowo podsumowania

Moim zdaniem warto było przyjść na dziesiąte spotkanie Agile Silesia, każde z wystąpień dało realną wartość i co ważne, opierało się na rzeczywistych doświadczeniach w projektach, codziennej pracy nad dostarczaniem oprogramowania. Pozytywnego wrażenie nie popsuł nawet mikrofon, do którego nie wolno mówić D i P;)

 

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Czego Rule of Three uczy o podejmowaniu decyzji

Rule of Three
image: (c) Graeme Maclean

Dziś krótko o regule podejmowania decyzji, znanej jako Rule of Three. Całość opiera się na zasadzie, że zwykle pierwszy pomysł, który przychodzi nam do głowy, niekoniecznie jest tym najlepszym i warto mieć większy wybór. Gdy mamy dwa możliwe rozwiązania, to jest już nieco lepiej, ale wciąż mamy dylemat, co wybrać. Dopiero pojawienie się trzeciej opcji do wyboru daje nam już jakiś szerszy obraz problemu, z którym się mierzymy i co więcej – prowadzi zwykle do kilku kolejnych ciekawych alternatyw.

W skrócie:

  • Jeden pomysł to ryzykowane rozwiązanie. Jeśli się mylimy, to nie mamy już żadnej alternatywy
  • Dwie idee to wciąż mało – mamy tylko złudzenie wyboru
  • Trzy możliwe rozwiązania to już realny wybór

 
Gdzie można zastosować regułę?

Kilka możliwych przykładów zastosowania reguły poniżej:

  • Organizowanie pracy projektowej
  • Tworzenie procesów / procedur
  • Decyzje w projekcie (techniczne, procesowe)
  • Przyjęcie rozwiązań związanych z architekturą i projektowaniem
  • Analiza działań związanych z mitygacją ryzyk

Jak można ją stosować?

  • W pierwszej kolejności generujemy pomysły, a potem zastanawiamy się, kto i jak może je realizować
  • Generujemy wartościowe pomysły (realne alternatywy)
  • Analizujemy każdą z opcji, zanim podejmiemy decyzję o jej odrzuceniu
  • Jesteśmy gotowi na łączenie opcji – być może pojawi się takie rozwiązanie, które skupi w sobie kilka różnych pomysłów lub ich części

Rule of Three to prosta zasada, która wymusza na nas bardziej przemyślane działania przy podejmowaniu ważnych decyzji. Nawet jeśli finalnie wybierzemy pierwszą opcję po analizie pozostałych, to jest to zdecydowanie bardziej dobra, przemyślana i świadoma decyzja, niż przyjęcie pierwszego pomysłu bez rozważenia kolejnych. Co więcej, poszukiwanie dalszych alternatyw pozwala nam lepiej zrozumieć problem, z którym się mierzymy.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Syndrom Mail Managera

 
Dziś poczta elektroniczna używana jest w zasadzie do wszystkiego i przez każdego. Badania wykazały, że każdego dnia wysyłanych jest 100 miliardów maili biznesowych. Spędzamy średnio cztery godziny codziennie na sprawy związane z pocztą elektroniczną, czyli połowę naszego dnia pracy. Każdy z nas wysyła 37 maili na dzień i odbiera 78, co w sumie daje 115 maili. Oczywiście zdarza się, że liczby te są zdecydowanie wyższe dla konkretnych przypadków. Szacuje się, że każdy z nas sprawdza pocztę około 36 razy w ciągu godziny i zwykle powrót do pełnej koncentracji dla poprzedniej czynności zajmuje nam 16 minut. Sprawdzanie poczty to jedna z naszych pierwszych porannych czynności i jedna z ostatnich każdego wieczora. Czy maile rządzą naszym życiem i czy wpływają na naszą efektywność?
Dziś chciałbym opowiedzieć Wam moją historię, historię Mail Managera…
 

Gdy zaczynałem swoją pracę zawodową jako programista moim głównym narzędziem pracy było szeroko rozumiane środowisko deweloperskie (IDE, edytory, konsole, wirtualne maszyny, przeglądarki itp.). Jedną z aplikacji, która także towarzyszyła mi w codziennej pracy, był klient poczty elektronicznej. Wówczas używałem go sporadycznie, nie miałem potrzeby się z nim bliżej wiązać i swoją uwagę skupiałem na działaniach w innych obszarach.

mail_manager_1

 

Z biegiem czasu, wraz z zmianą mojej roli w ramach organizacji, zaczęło się także zmieniać moje nastawienie do aplikacji pocztowej. Narzędzie wcześniej stosowane sporadycznie bardzo szybko pozyskało moją uwagę, aż nagle, któregoś dnia, zrozumiałem, że nie potrafimy bez siebie żyć. Zaobserwowałem, że:

  • Dzień zaczynał się i kończył sprawdzaniem maili
  • W trakcie dnia klient pocztowy stale mi towarzyszył
  • Na czas przebywania poza komputerem stacjonarnym znalazłem godne zastępstwo w postaci aplikacji pocztowej na smartfona

Zrozumiałem, że tak dalej być nie może, że moja produktywność mocno na tym cierpi i postanowiłem przeanalizować całą sytuację, co przełożyło się na diagram zbliżony do poniższego.

mail_manager_1

Oczywiście wraz ze zmianą roli, ilość zadań związanych z szeroko rozumianym zarządzaniem znacznie wzrosła, a to przełożyło się także na dużo większy udział komunikacji w mojej pracy. Nie da się ukryć, że poczta elektroniczna jest jednym z tych narzędzi komunikacji, które towarzyszą każdemu liderowi. Często pracujemy zdalnie, współpracujemy z wieloma osobami, z którymi nie mamy bezpośredniego kontaktu, chcemy przekazać informację, która nie wymaga natychmiastowej odpowiedzi. Ten model komunikacji działa w trybie asynchronicznym, czyli wysyłamy komunikat, ten jest odbierany, analizowany i następnie otrzymujemy odpowiedź. Czas między wysłaniem komunikatu i otrzymaniem informacji zwrotnej nie jest znany i może wynosić od kilku sekund  do nieskończoności (brak odpowiedzi).

Pojawia się pierwszy ważny element analizy – nieznany czas odpowiedzi.

Zaobserwowałem także, że wysyłając maile zmuszony jestem to przerwania wątku i przełączenia się w inny, aż do momentu otrzymania odpowiedzi, kiedy mogą wrócić ponownie do poprzedniego wątku. Pojawia się drugi element analizy – zawieszone wątki.

Bardzo często zdarzało się także, że poszukiwałem różnych informacji wśród maili, gdyż nie były one gromadzone w innych miejscach. Pojawia się trzeci element analizy – maile jako moje centrum informacji.

Nie pozwól, by maile sterowały Twoją pracą, podejmij proaktywne działania i zmień złe nawyki

Zastanowiłem się także, która z zidentyfikowanych przeze mnie przyczyn jest najbardziej dokuczliwa i moim zdaniem głównym powodem dla którego stajemy się Mail Managarem i pozwalamy, aby program pocztowy sterował naszą pracą, a czasem i życiem, jest fakt pojawiania się otwartych wątków. Nasz umysł nie radzi sobie z taką sytuacją najlepiej i stara się jej przeciwdziałać – stąd ciągła potrzeba szybkiego zamykania tematów, które „wiszą na mailach”.

W efekcie, starając się przeciwdziałać objawom syndromu Maila Managera, postanowiłem wprowadzić zmiany w swoim zachowaniu:

  • Wszystkie tematy, które byłem w stanie szybko omówić, dyskutowałem bezpośrednio (skype, face to face)
  • Wszystkie tematy, które wymagały szerokiego wyjaśnienia i jednocześnie nie wymagały formy pisanej, starałem się omawiać bezpośrednio (skype, face to face)
  • Wszystkie ważne informacje trafiały ze skrzynki w inne miejsca, lepiej to tego predysponowane
  • Do zarządzania zadaniami zastosowałem inny program (zrezygnowałem z wbudowanego modułu do zadań w kliencie pocztowym)
  • Wyłączyłem automatyczne sprawdzanie maili na urządzeniach mobilnych
  • Ustawiłem w swoim planie dnia momenty na pracę z klientem pocztowym

 
Te działania pozwoliły mi ponownie odzyskać równowagę i zdecydowanie wpłynęły pozytywnie na moją produktywność, choć wymagały ode mnie pracy przez  wiele tygodni, a nawet miesięcy. Dziś bardziej efektywnie zarządzam swoim czasem, moja skrzynka pocztowa jest w stanie „Inbox 0″, a ja sam czuję się dużo lepiej.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Scrum i spotkanie planujące. Rób to dobrze!

W tym artykule chciałbym podzielić się z Wami moimi doświadczeniami ze spotkania planującego obecnego w Scrumie. Możliwe, że uznacie, że informacje tu przekazane są wartościowe na tyle, byście sami spróbowali tych praktyk. Wszystkie z nich są bezpieczne do wykorzystania. Użycie ich nic nie kosztuje, tylko odrobiny wytrwałości. Zapraszam do lektury i dzielenia się innymi praktykami w komentarzach.

W Scrumie, każdy sprint (iteracja) rozpoczyna się spotkaniem planującym. To spotkanie ma jeden podstawowy cel – stworzenie listy user stories (historyjek), które będą dostarczone w najbliższym sprincie. Oczywiście, wymagania mogą być także przedstawione jako funkcjonalności, scenariusze, elementy Backlogu Produktu, etc. Ja ze swojej strony preferuję historyjki, jednak każda z poniższych praktyk/zasad może być użyta także z innym typem wymagań.

Z mojego doświadczenia wynika, że jest to jedno z najtrudniejszych spotkań do poprowadzenia w całym cyklu Scrumowym. Product Owner (właściciel produktu) oraz zespół deweloperski muszą pracować razem by stworzyć Backlog Sprintu.

Backlog Sprintu jest swego rodzaju umową między Product Ownerem, a zespołem deweloperskim. Deweloperzy zobowiązują się* do osiągnięcia celu w ograniczonym czasowo sprincie. Właśnie dlatego ważne jest, aby wszyscy byli skupieni na spotkaniu. Źle przeprowadzone spotkanie planujące będzie miało wpływ na cały Zespół Scrumowy.

Bądź przygotowany. Miej swój cel.

Product Owner przygotowuje się do spotkania planującego już nawet kilka dni wcześniej. Musi zebrać wszystkie wymagania od interesariuszy. Nieprzygotowany Product Owner bez spriorytetyzowanego Backlogu produktu to bardzo poważny problem. Marnowanie czasu deweloperów to nie przelewki, więc Product Owner musi wiedzieć dokładnie, które funkcjonalności są najważniejsze dla interesariuszy, biznesu, zespołu, etc., a odpowiedź na to pytanie będzie się różnić zależnie od projektu. Zdarza się, że priorytet jest wymuszony przez Zespół Scrumowy, gdyż określone user story pochodzić będzie z Retrospektywy. Istnieją także sytuacje odwrotne i Product Owner musi uwzględnić potrzeby interesariuszy, którzy np. już zdążyli obiecać daną funkcjonalność swoim klientom. Odpowiednie wyważenie obu tych światów jest bardzo trudnym zadaniem, które spoczywa na barkach Product Ownera.

Product Owner musi mieć określony cel na najbliższy sprint. Dobrą praktyką jest, by każda osoba zaangażowana w projekt była go świadoma. Dobrze na czas planowania nawet napisać cel w zasięgu wzroku uczestników. Powinien on być jasny, a dzięki temu każdy może się w niego zaangażować. Wszystkie wymagania powinny pochodzić od wspólnego celu, który pomoże skupić się na nich. Nawet jeśli priorytety nie są dla wszystkich jasne lub „wszystko ma wysoki priorytet” (skąd ja to znam?), wspólny cel scala spotkanie planujące.

Miej swój cel! (źródło: https://www.flickr.com/photos/hikingartist/)
Miej swój cel! (źródło: https://www.flickr.com/photos/hikingartist/)

Ogranicz spotkanie czasowo

W Scrumie wszystkie spotkania mają określone ramy czasowe i spotkanie planujące nie jest wyjątkiem. Nie powinno ono trwać dłużej, niż jeden dzień pracujący dla iteracji trwającej miesiąc (i relatywnie mniej dla krótszych). Z mojego doświadczenia wynika, że zespoły Scrumowe bardzo często o tym zapominają (mi także się to zdarzyło!) – omawiają bardzo małe szczegóły, a samo spotkanie zaczyna błądzić. Dodaj do tego niejasny cel i efekt końcowy będzie bardzo sławy. Rolą Scrum Mastera jest by trzymać rękę na pulsie i pilnować czasu. To Scrum Master powinien przypominać Zespołowi Scrumowemu o ich ograniczonym czasie.

Kilka słów o estymacjach

Estymacje są bardzo ważne (jeśli nie najważniejsze) w Scrumie. Zespół Scrumowy używa estymacji podczas całego projektu do zaplanowania pracy, jednak nie tylko w jednej iteracji. Estymacje mogą zostać użyte jako punkt odniesienia w przyszłych sprintach.

We wpisie skupiłem się na estymacjach punktowych jako najbardziej popularnym sposobie przedstawiania estymat wymagań w projektach prowadzonych zwinnie.

Estymacje w punktach muszą spełniać dwa wymagania:
– punkty muszą być jasne dla wszystkich;
– estymacje muszą być przedstawione w jednostkach idealnych i abstrakcyjnych.

Szeroko rozumiany biznes chętnie przyjmuje estymacje czasowe lub kosztowe. Jednak praca na bardziej abstrakcyjnych wartościach pozwala przełączyć rozmowę na zupełnie nowy poziom – bitwę na godziny zastępuje się rozmową o rozwiązaniu. Używanie abstrakcyjnych estymacji jest korzystne także z dwóch innych powodów, a mianowicie możliwe jest uwzględnienie w takich estymacjach także złożoności oraz niepewności. Takie podejście pozwala estymować bardziej efektywnie, niż pozostawanie na poziomie estymacji godzinowych.

Golden triangle of estimation
Złoty trójkąt estymacji

Najbardziej podstawowym typem estymacji jest ciąg Fibonacciego. Najprostsze user story będą miały 1 punkt, te najtrudniejsze, bardziej zaawansowane lub te z najwyższą niepewnością – uzyskują najwyższą wartość. To, co jest ważne i to, o czym powinno się pamiętać podczas estymacji jest relacją między punktami.

Niestety, często znajdą się ludzie, którzy będą ingerować w punkty i będą nawet próbować porównywać dwa zespoły Scrumowe bazując tylko na ich estymacjach. Można ich zignorować lub… można zmienić podejście do estymacji! Można zacząć estymować w rozmiarach koszulek. Dzięki temu uzyskasz skalę S, M oraz L. Jeśli to zbyt mało, można także dodać XS oraz XL, czy nawet XXL. Jeśli rozmiary koszulek nie są wystarczająco abstrakcyjne, można estymować w zwierzętach. Spróbuj skończyć jednego słonia, kozę oraz trzy wiewiórki w jednym sprincie… a potem porównaj je z 20 punktami, które uzyskał inny zespół. Myślę, że jest to wystarczająco jaskrawy przykład. Takie porównanie jest niemal niemożliwe, a spotkanie planujące może stać się dzięki użyciu takiej skali bardzo interesujące.

Animal estimation
Estymacja w zwierzętach? Czemu nie!

Spraw by planowanie było bardziej atrakcyjne

Teraz, kiedy posiadasz już własną skalę, możesz rozpocząć estymacje. W tej chwili pojawia się kolejny problem, który warto rozwiązać. Zazwyczaj deweloperzy estymują jeden po drugim, co na początku może być świetnym podejściem. Estymacje różnią się od siebie i jest spore miejsce do dyskusji. Po kilku rundach estymacje się stabilizują, ale czy na pewno? Może ludzie stają się zbyt zmęczeni i po prostu powtarzają estymację jeden po drugim, by mieć to już za sobą? Trudno zgadnąć…

Jednak jest na to rozwiązanie. Możesz użyć Planning Pokera. Dzięki temu rozwiązaniu każdy wybiera jedną kartę reprezentującą jego estymację. Następnie wszystkie karty odsłaniane są równocześnie. Różnią się? Pozwól deweloperom wyjaśnić najniższą i najwyższą wartość. Dzięki takiemu podejściu będziesz pewny, że wszyscy rozumieją user story identycznie. Następnie pozwól przeprowadzić kolejną rundę. Po takiej operacji możesz mieć niemal 100% pewność, że estymacje są poprawne i, co ważniejsze, cały zespół identyfikuje się z nimi. To najprostsza droga by wszyscy byli zaangażowani w proces. Możesz użyć zwykłych kart do gry lub dedykowanych do planning pokera. Możesz dodać także kilka dodatkowych kart do swojego zestawu – z symbolem kawy lub czasu. Dzięki temu, jeśli ktoś czuje się przemęczony, może zgłosić przerwę, a spotkanie wznowione zostanie po kilku minutach, gdy wszyscy będą ponownie gotowi.

Przykład kart do Planning Pokera (źródło: www.it-zynergy.com)
Przykład kart do Planning Pokera (źródło: www.it-zynergy.com)

Dziel i zwyciężaj

Pamiętasz swój ostatni stand up? Ktoś powiedział, że pracuje nad historyjką X? Jest to trzeci raz z rzędu! Kiedy skończy?…

Powyższa sytuacja wygląda znajomo? Na pewno tak! Historyjki są często zbyt duże by skończyć je jednego dnia. Co zrobić, gdy masz kilka epiców, a każdy z nich zajmuje cały sprint by go skończyć? W takiej sytuacji jeden deweloper może pracować przez cały sprint nad tym samym zadaniem (może być więcej powodów, dlaczego deweloper przy chodzi na Stand Upy cały czas z taką samą informacją, jednak tutaj nie skupiam się na nich). Może to być irytujące i nieznośne, ale to nie jego wina. Oczywiście – może być bardziej specyficzny co do swojej pracy na stand upach, ale ten problem można naprawić już na spotkaniu planującym!

Wszystko dlatego, że nie przeprowadziłeś swojej sesji planującej poprawnie. Każde spotkanie planujące powinno składać się z dwóch części:
– Co zespół będzie robił?
– Jak zespół to wykona?

Odpowiedź na oba te pytania jest bardzo ważna. Dotychczas pisałem tylko o pierwszej części. Do tego momentu zespół powinien mieć wybrane i wyestymowane historyjki do sprintu, czyli powinien być zdefiniowany Sprint Backlog. Wygląda na to, że skończyliśmy nasze zadanie.

Nic bardziej mylnego! Druga część spotkania jest o wiele ważniejsza dla deweloperów i o wiele bardziej angażująca. To teraz następuje moment dyskusji, jak zespół deweloperski ma zamiar spełnić wymagania klienta – co musi zostać zrobione, by dostarczyć funkcjonalności. Zespół deweloperski powinien wyszczególnić wszystkie zadania, które kryją się za danym wymaganiem klienta. Oczywiście wyodrębnienie zdań dla bardzo małej historyjki może być uznane za bezcelowe, jednak nie jest to do końca prawdą. Jest to jeden z procesów translacji wymagań biznesowych, na zadania techniczne.

Breakdown user stories
Rozbicie User Stories na taski

Podsumuj swoje spotkanie

Pamiętaj, że każde spotkanie musi zostać podsumowane. Dla spotkania planującego, dobrym podsumowaniem jest Sprint Backlog. Powinien to być efekt ciężkiej pracy głównie zespołu deweloperskiego, ale także Product Ownera i Scrum Mastera. Jeśli Sprint Backlog zawiera także podział na wszystkie zadanie, jakie w ramach poszczególnych wymagań należy wykonać – jeszcze lepiej! Jednak Sprint Backlog nie jest jedynym rezultatem tego spotkania.

Ze swojej strony na zakończenie spotkania planującego zawsze prezentuję zespołowi tzw. Point Board. Wygląda podobnie do Sprint Backlogu, jednak została dodana do niego jedna dodatkowa rzecz. Wymagania zostały posortowane wg ich wag by pokazać zachodzące między nimi relacje. Wymagania z identyczną/podobną estymacją powinny na takiej tablicy znajdować się niedaleko siebie – może to być ich trudność, wysiłek potrzebny do ich skończenia, czy niepewność. Dzięki takiej tablicy, zespół bardzo szybko może przejrzeć swoje estymacje i zweryfikować, czy jakieś user story jest „większe” od innego i w efekcie należy poprawić ową estymację (w takiej sytuacji dodatkowa dyskusja jest zazwyczaj potrzebna). Oczywiście na tej tablicy zachodzą także dodatkowe relacje – między sąsiadami w wagach. Wszystko pokazane jest na poniższym obrazie.

Przez pokazanie Point Boarda zespołowi, pozwalam zespołowi uzyskać pełną informację na temat zakresu sprintu i potwierdzić, że jest o poprawny, a wszystkie estymacje są słuszne.

Relacje na Point Boardzie
Relacje na Point Boardzie

Oczywiście. Zaprezentowane powyżej pomysły nie są jedynymi. Starałem się pokazać te, które nie są specjalnie absorbujące, a dają dobre efekty. Jeśli macie więcej podobnych przykładów, nie bójcie podzielić się nimi w komentarzach. Jeśli coś jest niejasne – także zapraszam poniżej.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Czego uczy Agile o… zarządzaniu ryzykiem

risk

W wywiadzie dla magazynu „Zarządzanie Projektami” (nr 1(8) /2015) wspomniałem, że metodyki zwinne pozwalają na eliminowanie wielu ryzyk projektowych:

Osobiście uważam, iż podejście zwinne znacznie podnosi jakość zarządzania ryzykiem w projekcie i to jest największą korzyścią w stosunku do tradycyjnych metodyk. Nikt z nas nie wie, co wydarzy się w przyszłości, natomiast jako kierownicy projektów powinniśmy być stale przygotowani na zmiany w otoczeniu projektowym. Należy zadać sobie pytanie, jak długo jesteśmy gotowi czekać, zanim odkryjemy, że projekt przekracza budżet, opóźnia się lub dostarczy nie takiej funkcjonalności, której chce klient. Podejście iteracyjne pozwala nam śledzić postępy projektu z bardzo duża dokładnością i daje nam możliwość zareagowania z wyprzedzeniem, co finalnie przekłada się na korzyści w różnych obszarach projektu.

Dziś omówię zarządzanie ryzykiem w Agile nieco szerzej i wskażę możliwe podejścia do tego tematu.

Chciałbym zacząć od tego, że zarządzanie ryzykiem jest niejako wpisane w filozofię Agile. Chcemy dostarczać wartość, działający software i tym samym powinniśmy eliminować wszelkie zagrożenia, które mogą mieć istotny wpływ na wynik naszej pracy (lub zwiększać szansę tych zdarzeń, które mogą pozytywnie oddziaływać na rezultaty naszych działań).

Jeśli zarządzanie ryzykiem kojarzy Ci się z czymś ciężkim, bardziej tradycyjnym, to zapewniam, że tak nie jest i można nim zarządzać naprawdę zwinnie – zapraszam do lektury.

Podejście lekkie

W zależności od skali, stopnia złożoności, doświadczenia zespołu czy innowacyjności naszego produktu, będziemy stosować podejście mniej lub bardziej aktywne. W pierwszym przypadku zakładamy po prostu, że koszty zarządzania ryzykiem są nieadekwatne do nakładów, w związku z czym potencjalne ryzyka eliminowane są w oparciu o nasze procesy, przykładowo:

  • Codzienne spotkania zespołu pozwalają zidentyfikować i eliminować typowe ryzyka związane ze sprintem
  • Retrospektywa pozwala szerzej spojrzeć na projekt oraz proces i daje szanse na wprowadzenie usprawnień oraz eliminowanie zagrożeń
  • Porządkowanie Backlogu pozwala na unikanie ryzyk związanych z błędnym rozumieniem wymagań
  • Dema z użytkownikami końcowymi pozwalają na szybką weryfikację, czy produkt dostarcza wymaganą funkcjonalność
  • Na poziomie pracy development teamu – code review w celu uniknięcia problemów z nieczytelnym kodem w przyszłości

Podejście lekkie mocno związane jest z zakresem prac, zwłaszcza na wczesnym etapie projektu, kiedy najbardziej istotne ryzyka i działania z nimi związane włączane są do naszego Backlogu. Przykładem takich działań może być sprawdzenie sensowności zastosowania danego narzędzia / technicznego podejścia w pierwszej iteracji, aby w kolejnych wybrać już właściwą drogę rozwoju produktu.

Attack risk before they become tomorrow’s problem.

W podejściu lekkim ryzyka są zatem zarządzane, choć może się zdarzyć, że nie jest to w pełni świadome działanie, zwłaszcza dla mniej doświadczonych zespołów.

Podejście aktywne

W podejściu aktywnym stosujemy mechanizmy znane z świata tradycyjnych metodyk, takich jak PRINCE2 czy PMBOK, odpowiednio dostosowując je do potrzeb naszego projektu. Oznacza to, że powinniśmy uwzględnić w naszym procesie podstawowe kroki zarządzania ryzykiem.

image001

Zanim zaczniemy

Zanim zaczniemy podejmować konkretne działania związane z ryzykami, warto ustalić kilka prostych reguł / definicji, które określą, jak będziemy zarządzać ryzykiem w projekcie. Będzie to nasz odpowiednik dla strategii zarządzania ryzykiem, który powinien zawierać takie informacje jak:

  • Przyjęta skala dla wpływu i prawdopodobieństwa występowania ryzyka
  • Sposób opisywania ryzyka (wpływ, prawdopodobieństwo, nazwa, opis itp.)

Moim zdaniem na początek to w zupełności wystarczy i w trakcie prac możemy (jeśli to będzie konieczne) ustalać kolejne elementy (sposoby zapisu ryzyk, częstotliwość spotkań itp.).

Pamiętajmy także, że taki zapis powinien się zmieniać w trakcie projektu, jeśli zajdzie taka potrzeba (na przykład przedefiniowanie skal na wartości pieniężne w momencie, gdy Product Owner i Zespół są już w stanie to zrobić).

Identyfikacja ryzyk

Ryzyka mogą występować na wielu poziomach, dlatego bardzo ważne jest zaangażowanie każdej osoby mającej wpływ na projekt (Product Owner, Development Team, Sponsorzy, Klienci, Użytkownicy Końcowi itp.). Jeśli to możliwe, powinniśmy włączyć w proces identyfikowania ryzyk każdego, kto może coś wnieść wartościowego do tego procesu.

if we have no involvement, we have no commitment.

Być może będzie to także lider innego projektu i jego doświadczenia, mogą to być lessons learned z poprzednich projektów, rejestry ryzyk, profile i wszelkie inne źródła danych na temat ryzyk, które mogą wystąpić w naszym projekcie. Jeśli nie wiemy, od czego zacząć, to można skorzystać z dostępnych publicznie list ryzyk.

Zwykle zaangażowanie wszystkich stron wymaga sporo wysiłku, niemniej warto przynajmniej raz, przy starcie projektu, takie spotkanie poświęcone identyfikacji (i najlepiej także ocenie) ryzyk zorganizować. Następnie zespół projektowy może regularnie już sam pracować dalej z stworzonym zapisem dotyczącym ryzyk.

Ocena ryzyk

Ryzyko możemy wyrażać poprzez iloczyn prawdopodobieństwa (jak pewne jest wystąpienie danego ryzyka) oraz wpływu (jakie konsekwencje poniesiemy, jeśli ryzyko się zmaterializuje).

Ekspozycja na ryzyko = Pradwopodobieństwo x Wpływ

Jedną z możliwych do zastosowania implementacji jest przyjęcie skali uproszczonej, opisanej wartościami 1, 2 lub 3. Pozwala to na szybką ocenę i priorytetyzację ryzyk. Przykładowy uproszczony rejestr ryzyk po uszeregowaniu wg wartości.

Risk Name Probability Impact Severity
Driver performance 2 3 6
Legacy module performance 3 2 6
Access to external API 2 2 4
Server patches 1 1 1
Total Risk Severity (Exposure)     17

 

Planowanie działań

Zespół może przeznaczyć część planowania na działania związane z ryzykami, może także organizować dedykowane spotkanie, na przykład co dwa tygodnie. Tutaj w dużej mierze zależy to od tego, jak bardzo ryzyka wpływają na projekt i zespół musi sam znaleźć równowagę i ocenić jaki koszt zajmowania się ryzykiem będzie odpowiedni.

Dodatkowo można zastanowić się na nad mechanizmem aktualizowania informacji na temat ryzyk od pozostałych osób mających wpływ na projekt, np. użytkownicy końcowi korzystający z narzędzia typu bug tracker do zgłaszania potencjalnych ryzyk, którymi zespół może się zająć.

Działanie

Jednym ze sposobów na włączenie działań związanych z ryzykiem do prac zespołu jest wydzielenie odpowiedniego czasu na ryzyka w iteracji.

Można także stosować inne podejście poprzez tworzenie dodatkowych user stories (lub innej formy zapisu wymagań). Zapisujemy ryzyka jako dodatkowe user stories i traktujemy ja analogicznie do wszystkich standardowych wymagań (ustalamy ich wartość oraz priorytet). Przykład takiego procesu doboru działań związanych z reakcjami na ryzyko i włączanie ich do backlogu produktu.

risk

Monitorowanie

W zależności od przyjętego sposobu zapisu i działań związanych z ryzykiem, ryzyko monitorowane może być w trybie ciągłym bądź w wybranych momentach czasu. Idealnie, jeśli przynajmniej kluczowe ryzyka są widoczne dla całego zespołu przez cały czas, dzięki czemu zapewniamy ciągły i mało nas kosztujący mechanizm monitoringu. Na przykład rejestr ryzyk w formie tablicy umieszczony w pokoju zespołu.

image005

Innym rozwiązaniem może być aktualizowanie po każdym sprincie rejestru ryzyk w formie tabeli.

Risk Name / Month June July August September October
Driver performance 6 0 0 0 0
Legacy module performance 6 3 0 0 0
Access to external API 4 4 0 0 0
Server patches 1 1 1 1 0
Product Owner Absence 3 0
Total 17 8 1 4 0

 

Można także zobrazować zmiany poprzez risk burndown chart.

image006

Kolejny widok, obrazujący status i trend kluczowych ryzyk, można uzyskać poprzez cumulative project risk profile.

image008

Podsumowanie

Moim zdaniem ryzykami w Agile należy zarządzać aktywnie, w oparciu o bardzo proste i skuteczne mechanizmy, które te działania ułatwiają. Agile Risk Management to:

  • Mniej formalizmów niż w podejściu zalecanym przez PMBOK czy PRINCE2
  • Odpowiedzialność całego zespołu za zarządzanie ryzykami
  • Pełna ciągłość, aktualność informacji na temat ryzyk
  • Zorientowanie na działanie
  • Pełna kontrola przez cały projekt
  • Ryzyka biznesowe także widoczne dla zespołudeweloperskiego
  • Ryzyka techniczne widoczne dla biznesu

Na koniec jeszcze mała niespodzianka – zarządzanie ryzykiem w zwinnym projekcie w wersji mini.

image010

 

 

 

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Kudo Cards w praktyce

image001

Kilkanaście miesięcy temu Jurgen Appelo odwiedził naszą firmę,  a ja pomagałem w przygotowaniu tej wizyty. Wtedy też otrzymałem swojego pierwszego kudosa, właśnie od Jurgena, w ramach podziękowań za organizację pobytu u nas. Sama idea kudosów była mi znana, jednak nie stosowałem jej aż do tego momentu.

Czym są kudosy i czy warto je stosować?

Kudosy to określenie, które przyjęło się w naszej firmie, natomiast można spotkać się z tym samym pomysłem przedstawionym pod innymi nazwami (kudo cards, notes of appreciation, hero awards). Idea ta polega na stworzeniu w ramach organizacji mechanizmu, który pozwala ludziom na przekazywanie sobie nawzajem podziękowań za dobrze wykonaną pracę. Podziękowania te wyrażane są w formie papierowych bądź elektronicznych kart typu kudo, czasem jest to drobny upominek (np. bilet do kina, książka). System ten, żeby działać prawidłowo, powinien spełniać sześć kryteriów (zgodnie z opisem w książce „#Workout” Jurgena Appelo.

  1. Nagrody powinny być niespodziewane – nie obiecaj nagród, nie ustalaj harmonogramu, unikaj atmosfery oczekiwania na nagrodę. Niech będzie to zawsze zaskakujące i stanowi miłą niespodziankę.
  2. Nagrody powinny być symboliczne – kudosy nie powinny działać jako system bonusów. Wyrazem docenienie są kartki kudo bądź jakieś upominki i to w zupełności wystarcza.
  3. Utrzymuj ciągłość systemu – każdego dnia ktoś może komuś za coś podziękować, nie ustalaj sztywnych terminów lub momentów do świętowania. Zdrowy system, przy dobrej atmosferze w pracy, sam zachowa ciągłość.
  4. Nagradzaj publicznie* – każdy ma prawo wiedzieć czemu i za co kogoś nagradzamy.
  5. Nagradzaj zachowanie, nie wyniki – cele można osiągnąć działając na skróty, zachowania natomiast świadczą o faktycznej pracy i wysiłku. W ten sposób ludzie uczą się pożądanych zachowań, a nie dążenie do osiągniecia celu za wszelką cenę.
  6. Nagradzaj wszystkich – system nie ma wychodzić tylko od liderów do członków zespołów. Każdy ma w nim uczestniczyć i mieć możliwość nagradzania innych osób.

*- ten punkt moim zdaniem nie jest kluczowy w samej idei i osobiście stosują również kartki kudo w formie cichych podziękowań, gdzie nikt inny poza mną i osobą, której dziękuję, nie wiem o tym.

Mój pierwszy kudos dla kogoś

Zachęcony swoim pierwszym otrzymanym kudosem postanowiłem skorzystać z generatora online i sam zacząłem wysyłać kartki kudo w formie elektronicznej, zarówno do pojedynczych osób, jak i całego teamu (np. po zakończonym sprincie).

image003

Uznałem także, że warto jeszcze bardziej przybliżyć ideę w ramach całej firmy i ułatwić dzielenie się kudosami. Wykorzystałem nasz wewnętrzny system do zgłaszania pomysłów na usprawnienie organizacji i od kilku tygodni na naszej platformie dostępny jest moduł do wysyłania kudosów. Przykład takiego kudosa, który ostatnio otrzymałem.

image005

 

Jeśli kudosy są dla Ciebie czymś nowym, to zachęcam do eksperymentowania. Nie musisz zmieniać od razu całej organizacji, wystarczy mała zmiana w Twoim zespole, wysłanie pierwszego kudosa, być może stworzenie skrzynki na kudosy papierowe. Eksperymentuj!

Poniżej kudobox używany w jednym z naszych zespołów, stworzony przy współpracy z… naszymi przedszkolakami:)

image007

 

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Co zapamiętam z tegorocznej Agilii

agilia

W tym roku miałem przyjemność opowiedzieć o kulturze organizacyjnej firmy Future Processing podczas konferencji Agilia 2015 w Brnie. Poniżej slajdy z mojej prezentacji.

Konferencja była także okazją do poznania nowych osób oraz wysłuchania co najmniej kilku ciekawych prelekcji. Szczegółową relację można znaleźć na stronie agile247.pl.

Ze swojej strony natomiast chciałbym dziś opowiedzieć o tym, co mi najbardziej zapadło w pamięć, czyli wystąpienie Jánosa Kocsány (How to attract talent? Graphisoft Park – Vision behind the unique working place)

János Kocsány w roku 1996 dołączył do firmy Graphisoft R&D (twórcy aplikacji ArchiCAD) i jego zadaniem było stworzenie Graphisoft Parku, czyli miejsca pracy, które będzie przyciągać największe talenty i sprzyjało pracy twórczej. Od roku 2006 Graphisoft Park SE stał się niezależną, notowaną na giełdzie, firmą zarządzającą nieruchomościami, a János został jej CEO. W swojej prezentacji pokazał, jak krok po kroku realizował swoją koncepcję unikalnego miejsca pracy i w zasadzie z niczego w 20 lat stworzył imponujący park technologiczny.

Our vision was to create a park with comfortable buildings ideal to work in and even more so in an intellectual environment (János Kocsány)

Model biznesowy tego przedsięwzięcia opiera się na wynajmowaniu poszczególnych budynków firmom, które nastawione są na unikalne miejsca pracy dla swoich pracowników (obecnie klientami są między innymi: Microsoft, SAP). Warta odnotowania jest także sama lokalizacja parku, gdyż jest to stosunkowo bliskie centrum Budapesztu i pokazuje to, że nawet w centrach dużych miast można stworzyć wyjątkowe miejsce pracy, odbiegające od dość powszechnego modelu „korpo”.

graphisoft_park

Zachęcam do pobrania broszury informacyjnej i zapoznania się z tym, co osiągnął Graphisoft Park przez te 20 lat.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Już wkrótce Quality Excites

Quality Excites - CFP

Niemal rok temu miałem przyjemność poprowadzić wykład otwierający konferencję Quality Excites, w trakcie którego starałem się przekazać słuchaczom swoją drogę odkrywania i zrozumienia stanu Jakości. Zdecydowałem się na to wystąpienie, gdyż temat jakości jest mi bardzo bliski – jest to jedna z naszych wartości firmowych. Jednocześnie miałem pełne zaufanie do samej idei konferencji, gdyż jest to inicjatywa Daniela oraz Łukasza, z którymi mam przyjemność pracować w naszym FP i wiem, z jak wielką pasją podchodzą do tego tematu.

Quality Excites

Jeśli temat jakości jest dla Ciebie ważny, to daj o tym znać organizatorom i zgłoś się do wystąpienia w tegorocznej edycji. Quality Excites to miejsce dla ludzi, którzy kierują się jakością każdego dnia i którzy chętnie wymienią się doświadczeniami, poznają nowe koncepcje i metody.

Jeżeli Ty także jesteś taką osobą, to zaproponuj swój temat – niczym nie ryzykujesz poza tym, że możesz sprawić, że ktoś dzięki Tobie stanie się lepszy w tym, co robi.

Quality Excites 2014

Jeśli mimo to nie czujesz się na siłach, ale chętnie weźmiesz udział w samej konferencji, to zapraszam do śledzenia tego, co dzieję się na oficjalnej stronie edycji 2015.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Dyskusje w formule Open Space

Open Space Technology to metoda organizacji spotkań dla grup, która zyskuje na popularności, nie tylko dzięki swojej prostocie, ale także efektywności w rozwiązywaniu problemów. Nie jest to tylko formuła dobra na konferencje, ale także sprawdzająca się w codziennej pracy. W poście wyjaśnię pokrótce cel takiej formy dyskusji, jej zasady oraz efekty.
Artykuł skupia się na pojedynczych spotkaniach w takiej formule – należy jednak pamiętać, że forma takich dyskusji świetnie nadaje się na całe bloki dyskusyjne, gdzie kilka dyskusji w tej formie odbywa się równolegle. Takie bloki dyskusyjne poprzedzane są zwykle giełdą tematów. Na takiej giełdzie każdy uczestnik ma prawo zgłosić własny pomysł na dyskusję, która zostanie dodana do planu spotkania. Ludzie mogą przechodzić z jednej dyskusji do innej bez niezręczności, a każde spotkanie ma niepowtarzalny skład i może prowadzić do zaskakujących wniosków.

Idealnych warunków do zaistnienia dyskusji w formie Open Space jest kilka, jednak nie wszystkie są konieczne by taka dyskusja się odbyła. Takimi warunkami są:
– praca na konkretnym problemie, nad którym ludzie chętnie chcą się pochylić lub go rozwiązać;
spora złożoność, która gwarantuje, że efekty samej dyskusji będą lepsze od samodzielnej pracy pojedynczych osób;
szeroka wiedza z różnych dziedzin, która gwarantuje różne spojrzenia na problem, dzięki czemu rozwiązanie może być niespodziewane, ale także prawdopodobieństwo powodzenia jest większe;
osobiste zaangażowanie;
ograniczony czas na znalezienie rozwiązania – najlepiej, by decyzja lub odpowiednie akcje zostały podjęte jak najszybciej.

Zaistnienie tych warunków gwarantuje, że dyskusja nie będzie jałowa, a jej efekty wartościowe.

Open Space to nie „wolna amerykanka”. Całą formułą rządzi pięć zasad oraz jedno prawo. Ich przestrzeganie jest kluczowe dla zaistnienia synergii i pozytywnych wyników Open Space’a. Zasady i reguły zachowałem w oryginale.

Zasada 1.Whoever comes is [sic] the right people… W dyskusji wszyscy są równi i każdy jest tak samo wartościowym uczestnikiem spotkania, jak inni;

Zasada 2. Whenever it starts is the right time… Spotkanie ma określony czas i jest on właściwy właśnie dla tej dyskusji.

Zasada 3. Wherever it is, is the right place… Podobnie, jak powyżej – tym razem odnośnie miejsca. Dwie powyższe zasady można podsumować krótko: „spotkanie jest tu i teraz”;

Zasada 4. Whatever happens is the only thing that could have… Cokolwiek wydarzy się na spotkaniu i w którym kierunku dyskusja pójdzie, jest właściwym kierunkiem i nie należy z tym walczyć;

Zasada 5. When it’s over, it’s over… Nieważne, jak dużo czasu zostało do końca spotkania – jeśli temat został wyczerpany, to nie należy się martwić i przedłużać go niepotrzebnie. Należy ruszyć dalej i nie martwić się tym.

Przykład graficznej reprezentacji zasad Open Space'a.
Przykład graficznej reprezentacji zasad Open Space’a. źródło: La Futura 2011, Berlin

Sam Open Space zawiera jeszcze jedną bardzo ważną regułę, która oddaje bardzo dobrze jej ducha – prawo dwóch stóp (Law of two feet). Reguła ta jest esencją całej formuły. Jeśli kiedykolwiek w trakcie całej dyskusji zauważysz, że niczego nowego się nie uczysz lub nie uczestniczysz w dyskusji, powinieneś ruszyć dalej i opuścić spotkanie szukając nowych inspiracji na innych równoległych dyskusjach. Jałowe pozostawanie w miejscu jest w sprzeczności z duchem tej formuły prowadzenia dyskusji.

Jak widać powyżej, formuła Open Space nie mówi nic o prowadzących. Oczywiście ktoś musi ją rozpocząć, by inni mogli ewentualnie zapisać się na interesujący ich temat. Dyskusja jest jednak niemoderowana – to ludzie uczestniczący w niej tworzą temat i oni wszyscy są za niego odpowiedzialni – zarówno za jego przebieg, jak i efekty. Dzięki takiemu podejściu, efekty dyskusji mogą być przeróżne – od bardzo prostych odpowiedzi na postawione pytania, po złożone systemy, które rozwiązują zaprezentowany problem.

Formuła Open Space bardzo wspiera uczenie, przez co po spotkaniu osoba rozpoczynające spotkanie powinna przekazać innym wyniki dyskusji (lub inna osoba, która czuje się na siłach) będące rozwiązaniem postawionego problemu, odpowiedzią na pytanie, czy opinią uczestników spotkania, która wyłoniła się podczas dyskusji.

Ze swojej strony w panelach dyskusyjnych w tej formule brałem udział kilkukrotnie – na konferencjach takich, jak ALE (Agile Lean Europe), czy ABE (Agile By Example) był to dosłownie hit – dyskusje potrafiły trwać i trwać. Podobne spotkania organizowałem także w firmie, w której pracuję. Jeden wniosek zawsze jest prawdziwy – ludzie chcą sobie wzajemnie pomagać, a formuła Open Space im to umożliwia. Przy niewielkim wysiłku można wiele zyskać.

Jeśli ktoś chciałby szerzej poznać całą metodę, może sięgnąć do publikacji Harrisona Owena Open Space Technology: A User’s Guide (http://www.amazon.com/Open-Space-Technology-Users-Guide/dp/1576754766).

Open Space Technology: A User's Guide by Harrison Owen
Open Space Technology: A User’s Guide by Harrison Owen
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Jak zostałem Mojżeszem Agile?

Family-Guy-4ACX30-Moses-Griffin

Jakiś czas temu rozpoczynałem współpracę z nowym zespołem. Cała ekipa już się w miarę dobrze znała – ostatnio przeszli przez wymagający projekt. Ja miałem być ich nowych Scrum Masterem i szczerze mówiąc nie mogłem się doczekać współpracy z nimi – mieli opinię świetnych specjalistów, a praca z takimi osobami jest zawsze ciekawa :) (czytaj: niekoniecznie łatwa).

Zgodnie z naszym firmowym systemem ocen, powinienem był zdefiniować swoje oczekiwania w stosunku do całego zespołu i poszczególnych jego członków. Podchodząc do tematu „zwinnie”, chcąc zaangażować zespół w to ważne zadanie (w końcu oni też powinni zdefiniować swoje oczekiwania w stosunku do mnie i siebie nawzajem), zdecydowałem, że chcę zaproponować zespołowi jakiś inny sposób na definiowanie oczekiwań, coś czego jeszcze prawdopodobnie nikt nie robił.

Akurat w tym czasie wieczorami czytałem nową książkę Jurgena Appelo (#Workout) i natknąłem się na ciekawy rozdział „Work Profile and Project Credits”. Porusza on istotny temat tytułów w firmie, drabinek kariery, ról projektowych itp. Pojawia się z nim też pewna inspirująca myśl…

Job titles and project roles can have a significant impact on the clarity, branding, status, and behavior of employees.

Tak! Dokładnie tego szukałem! Chcąc zdefiniować swoje oczekiwania w stosunku do zespołu (oraz dać zespołowi narzędzie do zdefiniowania oczekiwań w stosunku do siebie) powinniśmy rozpocząć od rozmowy o tym w jakich rolach się widzimy. Tak więc mamy do czynienia z klasycznym przypadkiem „steal and tweak”, gdzie wykorzystując istniejące idee, konstruujemy coś nowego. Teraz wystarczyło tylko zbudować warsztaty dla zespołu oraz je przeprowadzić.

Forma warsztatów jest całkiem prosta:

  • Przedstawić uczestnikom teorię opisaną w książce Jurgena. Jedną z najważniejszych myśli jest to, że każdy z nas jest odpowiedzialny za budowanie własnej marki osobistej. Markę budujemy na różne sposoby, w pewnym stopniu również poprzez wpisywanie siebie w tytuły firmowe. Elementami najbardziej jednak wpływającymi na naszą markę osobistą są role, w które wcielamy się w projekcie. To one pokazują, czym się zajmowaliśmy, co było dla nas najważniejsze itp. To one też w kontekście naszego ćwiczenia posłużą za definicję naszych wzajemnych oczekiwań.
  • Każdy uczestnik wymyśla role dla innych (ale nie dla siebie!). Warto zaprezentować zespołowi kilka przykładów ról (poniżej).
  • Konfrontujemy role oraz wspólne oczekiwania podczas dyskusji oraz negocjacji. Jest to niezwykle istotny element całych warsztatów. Wszystkie wymyślone role muszą być jasne dla uczestników, każdy musi chcieć przyjąć daną rolę (Być może już w nią wchodzi? Być może chce się w tym kierunku rozwinąć?), możemy się wymieniać rolami, uzupełniać definicje itp. Istotna jest moderacja tej części warsztatu w kierunku:
    1. osiągnięcia konsensusu i dobrego zrozumienia ról oraz
    2. nie popadania w szczegółowe definiowane ról, które mogą ograniczyć zdolność zespołu do samoorganizacji.

Na zakończenie warsztatów powinniśmy otrzymać listę ról przypisanych do wszystkich członków zespołu. Lista ta pozwoli im budować swoją markę osobistą oraz pozwoli nam lepiej zarządzać wzajemnymi oczekiwaniami. Dodatkowo, lista może posłużyć jako tzw. „Project Credits” – poprojektowy artefakt wiszący w „hall of fame” na korytarzu w firmie. W naszym przypadku poszliśmy o krok dalej. Nasze role tak bardzo nam się spodobały, że nie mogłem się doczekać i powiesiłem je obok wejścia do naszego pokoju już teraz. Oto kilka przykładów ról (pogrubione role oznaczają te najważniejsze dla danego członka zespołu):

​​​Imię

Tytuł w firmie​

​Role

Kamil

(nieistotny)​​
  • Mojżesz Agile,
  • Strażnik Procesu oraz Doradca ds Procesu,
  • Pomocna Dłoń, oraz
  • Właściciel Spotkań, Mediator, Kapitan (kpt. Sowa), Specjalista do Spraw Niedeweloperskich, Organizator Pracy w Biurze

Natalia ​​

(nieistotny)​​
  • Nadzorca Jakości i Wymagań, oraz
  • Ewangelista Porządku, Strażnik Detali, Siewca Wiedzy Domenowej, Menadżer Testów Automatycznych, Tester Oprogramowania​

​Marcin ​

(nieistotny)​​
  • Obiektywny Obserwator,
  • Opiekun/Doradca Techniczny,
  • Całościowy Code Reviewer, oraz
  • Zarządca Chmury, Developer, Tester Oprogramowania, Build Master

I tak oto zostaFamily-Guy-4ACX30-Moses-Griffinłem Mojżeszem Agile :) dodam, że zespół miał całkiem sensowne uzasadnienie tego dlaczego chcą żebym przyjął tą rolę. Spodobało mi się to, chcę to robić i chcę żeby w tym właśnie kierunku budowała się moja marka osobista.

PS Póki co za krótko pracujemy razem żeby ocenić jaki wpływ definiowanie ról miało na zespół. Podchodząc do ćwiczenia już na etapie warsztatów zauważyłem kilka istotnych korzyści, m.in. to, że całym zespołem omówiliśmy nasze doświadczenia z pewnymi rolami, zaś jako lider lepiej zrozumiałem, czego się obawiają, gdzie chcę się rozwijać a czego nie lubią. Już sama ta korzyść jest wg mnie wystarczającym argumentem za przeprowadzeniem tego ćwiczenia.

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

The Culture Map, czyli o skutecznej komunikacji

Pracuję w firmie, która świadczy swoje usługi głównie klientom spoza naszego kraju. Dzięki temu miałem okazję pracować z ludźmi z różnych stron świata. Zdarzały się sytuacje, gdzie mimo szczerych chęci, nie potrafiliśmy się zrozumieć i błędnie interpretowaliśmy niektóre zdarzenia. Ze swojej strony starałem się stosować powszechnie znany mi praktyki związane z efektywną komunikacją i uwzględniać teorię Hofstede, ale jakoś nie zawsze przynosiło to pożądany efekt.

the_culture_map_cover

Ostatnio w moje ręce trafiła książka Erin Meyer „The Culture Map: Breaking Through the Invisible Boundaries of Global Business”.  Już po kilku pierwszych stronach czułem, że ktoś nie tylko doskonale rozumie problemy we wzajemnym zrozumieniu ludzi z różnych stron świata, ale wręcz ma wiele rozwiązań podpartych praktycznym doświadczeniem. Dla mnie osobiście ta książka uwidoczniła bardzo wyraźnie przyczyny błędów w wzajemnej percepcji i był to moment, w którym nagle zrozumiałem powody zaistniałych problemów. Zachęcam Was do lektury książki, a ze swojej strony postaram się przedstawić najbardziej istotne założenia.

Perspektywy

Erin Meyer w oparciu o swoje długoletnie doświadczenia doszła do wniosku, że różnice kulturowe można sprowadzić do odpowiednich skal w następujących obszarach:

  1. Komunikacja (bezpośrednia – ukryta) [oryg. Communicating: explicit vs. implicit]
  2. Ocenianie (bezpośredni feedback negatywny – ukryty feedback negatywny) [oryg. Evaluating: direct negative feedback vs. indirect negative feedback]
  3. Przekonywanie (dedukcyjnie – indukcyjnie) [oryg. Persuading: deductive vs. inductive]
  4. Przywództwo (egalitarne – hierarchiczne) [oryg. Leading: egalitarian vs. hierarchical]
  5. Podejmowanie decyzji (współpraca – nakazowe) [oryg. Deciding: consensual vs. top down]
  6. Zaufanie (zadania – relacje) [oryg. Trusting: task vs. relationship]
  7. Konfrontowanie (bezpośrednie – unikanie) [oryg. Disagreeing: confrontational vs. avoid confrontation]
  8. Planowanie (ustrukturyzowane – elastyczne) [oryg. Scheduling: structured vs. flexible]

 1. Komunikacja

W przypadku komunikacji bardzo istotna jest kontekstowość. Niska kontekstowość oznacza bardziej precyzyjny komunikat, mało niejednoznaczności. Amerykanie są tutaj zdecydowanie na skraju skali, co może wynikać chociażby z procesu powstawania państwa złożonego z imigrantów z różnych stron świata, gdzie sztuka wzajemnego porozumiewania się wymagała formułowania precyzyjnych komunikatów.

Z kolei kraje azjatyckie są na przeciwnej stronie osi i oznacza to, że wielu rzeczy trzeba się domyślać, wyczuwać i bazować na swojej intuicji i doświadczeniu (wiele tych samych słów ma różne znaczenia w zależności od kontekstu).

culture_map_1

 2. Ocenianie

Przekazywanie negatywnego feedbacku przybierać może bardzo różne formy – od niezwykle bezpośredniego komunikowania w Holandii do unikania takiego feedbacku w przypadku kultur azjatyckich (warto zauważyć, że różnica między Japonią a Chinami jest tutaj znacząca, co może nie być aż takie oczywiste patrząc tylko na skalę).

Amerykanie z kolei są narodem niezwykle bezpośrednim, jednak w przypadku feedbacku negatywnego bardzo mocno zmiękczają komunikat, co może prowadzić dość szybko do nieporozumień w zderzeniu z osobami z Francji czy Niemiec.

culture_map_2

 3. Przekonywanie

Sposoby podejścia do przekonywania drugiej strony do swoich racji, argumentowania swojego stanowiska możemy podzielić na te, które opierają się na dedukcji (wyprowadzanie logicznych wniosków z założeń uznanych za prawdziwe) oraz oparte na doświadczeniu (w oparciu o praktyczne doświadczenia tworzona jest teoria). Bardzo łatwo można podejścia te rozpoznać już w samych systemach szkolnictwa. To rozróżnienie jest ważne, gdyż w przypadku takich kultur jak amerykańska czy kanadyjska, należy przede wszystkim pokazać wyniki oparte o rzeczywiste doświadczenia, podczas gdy na przykład Niemcy oczekują wyjaśnienia teorii, przyjętych założeń, metod dochodzenia do wyników itp.

culture_map_3

 4. Przywództwo

Podczas studiów w Danii zauważyłem, że wszyscy starają się być wobec siebie równi, że oficjalna różnica między poszczególnymi osobami w ramach organizacji praktycznie nie istnieje. Było to zdecydowanie dalekie od dość powszechnie spotykanej w Polsce formuły hierarchicznej. Niemniej, od wielu lat pracuję w organizacji, która swoją strukturą celuje jednak bardziej w model duński niż tradycyjny polski. Być może z czasem w Polsce przesuniemy się bardziej w kierunku modelu egalitarnego.

Problemem, który zauważa Meyer jest połączenie różnych stylów. Przykładowo szef szwedzkiej firmy prowadzi oddział w Chinach i ma problem z dogadywaniem się ze swoimi ludźmi. Powód – przyjeżdża do pracy na rowerze, bo nie chce się wywyższać i nie dostrzega, że cierpi na tym prestiż całego zespołu, gdyż w chińskiej kulturze szef jest kimś ważnym i powinien się wyróżniać. W oczach tego zespołu szef działa celowo na jego szkodę.

culture_map_4

 5. Podejmowanie decyzji

W przypadku podejmowania decyzji warto zauważyć, iż nie jest to jednoznaczne z stylem przywództwa. Dowodem jest tutaj kultura japońska, gdzie pomimo silnej hierarchii decyzje podejmowane są na drodze wzajemnego porozumienia wszystkich ze wszystkimi (ringisho).

Jednocześnie dla takich krajów jak Japonia czy Szwecja do decyzji dochodzi się długo, ale jest ona ostateczna dla wszystkich stron. W przypadku UK czy USA sytuacja wygląda inaczej – decyzje podejmuje się szybciej, ale też uważa się za zaletę bycie elastycznym i zmienianie zdania jest czymś naturalnym.

culture_map_5

6. Zaufanie

Wszyscy się zgodzą, że zaufanie w biznesie to kluczowy element sukcesu i budowania wzajemnych relacji. Jednak sposoby budowania zaufania są dosyć różne. Część kultur opiera się na wynikach prac, realizacji zadań. Inne kultury opierają się na relacjach, kontaktach bezpośrednich. Bardzo często słyszymy „business is business”, tymczasem dla wielu kultur „business is personal”. W praktyce oznacza to, że nie zdobędziemy zaufania w krajach takich jak Japonia czy Chiny, jeśli wcześniej nie spędzimy ze sobą trochę czasu (często wręcz należy wypić razem alkohol…).

culture_map_6

 7. Konfrontowanie

Dla wielu kultur spieranie się, prowadzenie ożywionych dyskusji, wymiana zdań są czymś zupełnie naturalnym. Dla innych wprost przeciwnie. Skala ta jest bardzo podobna do skali feedbackowej, jednak warto odnotować różnice. Przykładowo w Szwecji, gdzie feedback negatywny jest bardzo bezpośrednio udzielany, w przypadku dyskusji unika się raczej konfrontacji.

culture_map_7

 8. Planowanie

Gdy wysyłam komuś zapytanie mailem, oczekuję, że albo odpowie w przeciągu doby, albo potwierdzi, że otrzymał maila i odpowie w określonym terminie. Gdy tak się nie dzieje, zaczynam się zastanawiać, czy coś się nie stało. Jestem pewnie osobą, która zdecydowanie widzi czas mocno liniowo. Jednak dla wielu kultur czas jest dużo bardziej elastyczny i warto mieć to na uwadze.

culture_map_8

Jak czytać skale?

Jeśli zdarzy nam się pracować w środowisku wielokulturowym, to warto sporządzić profil kulturowy zbiorczy, taki jak podany w przykładzie poniżej. Dzięki temu możemy szybko zauważyć, w czym jesteśmy podobni, a gdzie będziemy się różnić.

culture_map_9

O czym jeszcze pamiętać?

Same skale nie są binarne i należy mieć na uwadze, że dana kultura w ramach każdej ze skal jest w jakimś przedziale. Jednocześnie każdy człowiek jest inny i nie musi idealnie wpasowywać się w podane przez Meyer wyniki. To, na co jednak zdecydowanie warto zwrócić uwagę, to fakt, w jaki sposób dane kultura postrzega omówione aspekty. Czym innym jest negatywny feedback dla Holendra, a czym innym dla Kanadyjczyka.

Skuteczna komunikacja opiera się na identyfikowaniu i rozumieniu kontekstów kulturowych

Gdybyśmy opierali się tylko o nasze doświadczenia kulturowe, to definiując dobrego komunikatora celowalibyśmy w osobę, która potrafi precyzyjnie formułować komunikat i trafiać do wszystkich odbiorców. Jeśli jednak zestawimy takie podejście ze sposobem komunikowanie wśród narodów azjatyckich, gdzie dużo bardziej istotne jest „czytanie między wierszami” (reading the air), przesyłanie informacji w sposób mniej bezpośredni, to nasze umiejętności mogą zostać ocenione znacznie niżej. Możemy przyjąć, że dobry komunikator w dzisiejszym świecie to osoba, która potrafi się skutecznie komunikować w każdym kontekście kulturowym.

Thanks to Erin Meyer for letting me publish the charts from „The Culture Map„.


Drogi Czytelniku – jeśli dotarłeś do tego miejsca i zainteresował Cię ten tekst, to zachęcam do udostępniania go swoim znajomym. Możesz użyć poniższych ikon albo przesłać ten link. Dziękuję:)

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Agile Silesia #8

agile_silesia

10-go lutego w Katowicach odbyło się ósme spotkanie Agile Silesia. Mieliśmy okazję wysłuchać dwóch interesujących prelekcji. W roli prelegentów wystąpili Artur Nowak oraz Beata Nowakowska.

arturnowak

Artur sporą część swojego życia zawodowego spędził w branży motoryzacyjnej, z naciskiem na zakłady produkujące samochody. To doświadczenie pozwoliło mu poznać dogłębnie filozofię Lean, a jako że zajmował i wciąż zajmuje się także tworzeniem oprogramowania, to miał okazje porównać oba podejścia (Agile vs Lean).

Na wstępie Artur przypomniał wszystkim zwięźle historię Lean Manufacturing, a następnie w oparciu o konkretne metody stosowania Lean szukał podobieństw i przeciwieństw do Agile.

W swoich poszukiwaniach Artur zwrócił uwagę na rozróżnienie między cyklem a taktem. W produkcji celem jest takie dobranie cyklu, by trafiać w takt. Gdy cykl jest dłuższy, mamy opóźnienie (ktoś za długo wykonuje swoją pracę), gdy cykl jest krótszy, mamy przestój (nic nie robimy i czas jest marnowany). Podejście to Artur porównał do stosowania wykresów spalania w Scrumie, gdzie zespół także rysuje idealną krzywą wg której stara się spalać kolejne punkty. Przy tej okazji warto wspomnieć, że idea taktów także zostało przyjęte w świecie IT, chociażby do szacowania  opartego o metodę Monte Carlo.

Kolejną kwestią, którą Artur poruszył to temat jakości. W przypadku Lean mówimy o jakości integralnej (człowiek, maszyna, materiał, metoda). Zdaniem Artura w przypadku Agile nie możemy mówić o takiej jakości. W mojej ocenie istotnie produkcja samochodów różni się od tworzenia oprogramowania – w pierwszym przypadku mówimy o powtarzalnym procesie, w drugim o procesie ciągłego uczenia się. W obu jakość jest ważna, ale rzeczywiście oznacza jednak co innego.

 

Nie przyjmuj – nie produkuj – nie wysyłaj defektów

 

Przy okazji tematu jakości Artur wspomniał o systemie Andon – nie przyjmuj – nie produkuj – nie wysyłaj defektów. W skrócie – każdy ma dbać o jakość i jak tylko zauważymy odstępstwo od normy, to należy zgłosić to swojemu liderowi. Ten, mając doświadczenie, podejmuje decyzje i w ostateczności może sięgnąć po rozwiązanie krytyczne – zatrzymanie produkcji przez pociągnięcie linki Andon. Tutaj zwrócę tylko uwagę, że świat tworzenia oprogramowania to pojęcie także zaadoptował do swoich potrzeb (Andon lights stosowane w Scrumbanie).

Prezentacja Artura dostępna jest na slideshare.

 

Na koniec Artur wspomniał o swoim projekcie Mindwideweb – jeśli ktoś poszukuje aplikacji wspierającej procesy uczenia się / zapamiętywania, to warto zajrzeć.

Sama prezentacja zajęła trochę dłużej niż planowano, ale raczej nikomu to nie przeszkadzało, bo kto nie lubi rozmawiać o samochodach;)

 

bnowakowska

Beata jest Coachem oraz Scrum Masterem. W swojej pracy stara się łączyć obie te role i korzystać z kompetencji coachingowych dla zwiększania możliwości swojego zespołu.

Na wstępie Beata wyjaśniła pochodzenia słowa coach. Zainteresowanych odsyłam po szczegóły do wikipedii. Następnie opowiedziała o najważniejszych założeniach w pracy coacha. Określenie, które mi zapadło w pamięci i dobrze opisuje tę rolę to „wspieranie drugiej osoby w poskładaniu puzzli razem”. Osoba coachowana sama wypracowuje rozwiązanie, osiąga swój cel, a coach ma jej tylko pomóc ułożyć wszystkie elementy układanki.

Z ważnych założeń dla pracy coacha warto zapamiętać:

  • nie stosujemy parafrazy, zamiast tego echo (powtarzamy słowa klienta)
  • unikamy pytań zamkniętych (czy, dlaczego)
  • aa, ee, yhy – unikajmy tego

 

Celem coacha jest stworzenie odpowiedniej atmosfery, która sprzyja twórczemu myśleniu coachowanego

 

Beata wyjaśniła, że celem coacha jest stworzenie odpowiedniej atmosfery, która sprzyja twórczemu myśleniu coachowanego (być z klientem, wytworzyć zaufanie, kopiować zachowania klienta) oraz skupieniu swojej uwagi na tworzeniu jak największej ilości dobrych pytań.

Od siebie dodam, że jeśli macie możliwość korzystanie z coachingu, to warto spróbować. Coachowie to osoby naprawdę dobrze przygotowane do tej roli i ja osobiście cieszę się, że mam w swojej firmie możliwość korzystania z coachingu.

 

Słowem podsumowania

Uważam, że ósme spotkanie Agile Silesia było wartościowe i cieszę się, że kolejne osoby z naszego regionu chętnie dzielą się swoją wiedzą i doświadczeniami.

Prezentacja Artura przybliżyła mi ideę Lean w kontekście miejsca jej źródła, czyli samej produkcji. Mam jednocześnie wrażenie, że Artur nie miał okazji spotkać się z szerszym zastosowaniem Lean w świecie tworzenia oprogramowania i postrzega zwinne podejście tylko przez pryzmat pewnych, znanych mu doświadczeń.

Prezentacja Beaty przybliżyła definicję coachingu i zawierała kilka ważnych praktycznych porad.  Zabrakło mi natomiast bardziej precyzyjnego powiązania roli coacha i Scrum Mastera i odebrałem prezentację jako dwie, bardzo luźno ze sobą powiązane części.

Do zobaczenia na kolejnym spotkaniu!


Drogi Czytelniku – jeśli dotarłeś do tego miejsca i zainteresował Cię ten tekst, to zachęcam do udostępniania go swoim znajomym. Możesz użyć poniższych ikon albo przesłać ten link. Dziękuję:)

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone

Pomodoro, czyli zadania o smaku pomidora

Pomodoro to jedna z najprostszych technik zarządzania swoim czasem. Nazwa pochodzi od przyrządu odmierzającego czas (spotykanego często w kuchni – minutnik w kształcie pomidora).

Pomodoro
Technika ta służy poprawie efektywności wykonywania zadań (skupia się przede wszystkim na efektywnym realizowaniu wcześniej zaplanowanych zadań) – nie jest to kompletne rozwiązanie do zarządzania zadaniami w czasie, raczej jest to uzupełnienie dla technik typu GTD, Personal Kanban, Matryca Zarządzania Czasem Covey’a itp.

Pomodoro pozwala na poprawianie efektywności wykonywania zadań

Autorem techniki jest Włoch i stąd włoska nazwa pomidora. Prosta nazwa podkreśla proste i jasne zasady stosowane w tej technice. Można ją stosować w zasadzie od zaraz – wystarczy dostosować się do kilku reguł podanych poniżej.

  • Wybrać zadanie do wykonania – można stosować zasady zalecane przez autora Pomodoro (lista zadań do wykonania, posortowanie jej wg ważności). Można też stosować inne / własne techniki. Istotne jest, aby zadanie mieściło się w granicach wielkości Pomodoro.
  • Ustawić czasomierz na 25 minut – czyli tyle, ile trwa jedno Pomodoro. Przez ten czas w maksymalnie pełnym skupieniu będzie realizowane zadanie lub jego część (jeśli nie zdążymy zrealizować całego zadania).
  • Pracować nad zadaniem przez całe Pomodoro. Nie przerywaj sobie, ale też nie pozwól, by Ci przerywano. Czasomierz wskazuje Ci, ile jeszcze czasu pozostało.
  • Oznaczyć zadanie jako wykonane. Po upływie 25 minut oznacz zadanie jako wykonane. Niezależnie od tego, czy zostało zrealizowane już w całości, czy coś jeszcze pozostało do zrobienia.
  • Zrobić sobie 5 minut przerwy – po każdym Pomodoro masz 5 minut przerwy – nie rozmawiaj wówczas o zadaniach, nie czytaj maili itp. Odpocznij – przejdź się po biurze itp. Pamiętaj, że masz tylko 5 minut. Po przerwie zaczynasz kolejne Pomodoro – zgodnie z listą zadań – albo kończysz poprzednie zadanie, albo zaczynasz nowe.
  • Zrobić sobie dłuższą przerwę po czwartym Pomodoro – 15 do 30 minut obowiązkowej przerwy. To powinno wystarczyć na zaparzenie herbaty czy przygotowanie kawy. To także czas, kiedy możesz sprawdzać pocztę itp. Nie powinny to być zadania wymagające Twojego maksymalnego skupienia i uwagi – jeśli zatem czytanie poczty jest takim zadaniem, to powinno ono być na liście zadań do zrobienia, nie zadaniem na przerwę.

Do opisanej powyżej techniki mamy jeszcze takie zasady:

  • Pomodoro jest niepodzielne – każde Pomodoro trwa 25 minut.
  • Zadanie nie powinno wymagać więcej niż siedem Pomodoro. Jeśli tak jest, podziel jej na mniejsze.
  • Zadanie powinno zajmować co najmniej jedno Pomodoro. Jeśli tak nie jest, zbierz mniejsze zadania do jednego Pomodoro.
  • Każde kolejne Pomodoro pójdzie Ci lepiej:)

 

Czasomierze
Do odmierzania czasu można zastosować cokolwiek – kupić sobie stylowy odmierzacz w kształcie pomidora, zainstalować aplikacją na smartfona lub uruchomić czasomierz w przeglądarce. Kilka przykładów poniżej:

To chyba tyle, czas na moje 5 minut przerwy;)

 



Drogi Czytelniku – jeśli dotarłeś do tego miejsca i zainteresował Cię ten tekst, to zachęcam do udostępniania go swoim znajomym. Możesz użyć poniższych ikon albo przesłać ten link. Dziękuję:)

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestEmail this to someone