-
Moc etykiet
Dowiedziałem się ostatnio o dość zaskakujących badaniach, które dobitnie pokazują jaki wpływ na postrzeganie ma język.
Mianowicie pewien badacz zauważył, że w starożytnych dziełach nie ma słowa na określenie koloru niebieskiego – a w szczególności nigdzie nie ma wzmianek o tym, by niebo miało jakiś szczególny kolor. Jest to jeszcze ciekawsze, jeśli połączymy to z badaniem pewnego współcześnie istniejącego w Afryce plemienia, które w swoim języku też słowa na określenie niebieskiego nie ma. Jak pokazały eksperymenty (polegające na pokazywaniu na ekranie kwadracików o różnych kolorach i proszeniu o ich rozróżnianie) ludzie z tego plemienia po prostu niebieskiego nie widzą – a ściślej nie rozróżniają od zielonego. Na tej podstawie postawiono dość śmiałą tezę, że starożytne ludy, które zbudowały fundamenty naszej cywilizacji nie tylko nie umiały niebieskiego nazwać, ale wręcz tego koloru nie dostrzegały właśnie dlatego, że nie umiały go nazwać (przeczytaj cały artykuł na ten temat – warto).
Piszę o tym, bo jest to świetny przykład na to jak silnie nasze myślenie kształtuje język, z którego korzystamy. Choć nasze oczy odbierają obiektywnie te same fale elektromagnetyczne, to co w efekcie widzimy wypływa ze świadomości. To spójne z wiedzą o funkcjonowaniu mózgu – w istocie nie widzimy „obiektywnie”, oczami, obraz dopiero kreuje mózg. A to na jakiej podstawie to robi jest mocno ugruntowane kulturowo, w tym oczywiście także przez język – najsilniejszy nośnik skojarzeń i obiektów, które można „zobaczyć”.
Skoro tak dzieje się z tak zdawałoby się obiektywną i prostą rzeczą jak kolory, to w takim razie o ile silniejsze jest samodefiniowane się człowieka poprzez etykiety, pod którymi się postrzega. W tym kontekście takie etykiety jak „tester” czy „programista” (albo „starszy referent”) od razu określają co ich nosiciele robią – a czego nie. Głównym problemem owych etykiet nie jest nawet to, że powodują odruchowe wręcz zawężanie zakresu postrzegania i odpowiedzialności (a ściślej klasyfikowania co jest rzeczą, którą powinienem się zająć i za którą odpowiadam, a co nie), ale to, że w kontekście pracy, w którym działają, niejako spłaszczają człowieka do jednego wymiaru, jednej umiejętności. To z koleji prowadzi nie tylko do silosów ze wszystkimi problemami, jakie one tworzą, nie tylko do poszukiwania lokalnych optymalizacji efektywności (w istocie psujących efektywność całości) ale przede wszystkim do niepełnego wykorzystania możliwości ludzi, którzy tworzą organizację.
Wydawałoby się zatem, że najlepiej byłoby nie nadawać żadnych nazw – po prostu pozbyć się etykiet niczym źródła zła. Przecież w małych firmach (często obecnie znanych pod niekoniecznie poprawnie użytą ale modną nazwą „startup”), gdzie z założenia wszyscy robią to co umieją i co jest w danej chwili potrzebne tak właśnie jest, a stanowiska i związane z nimi etykiety służą głównie do prezentowania się firmy na zewnątrz.
Jednak etykiet nie tak łatwo się pozbyć. W większych organizacjach jak również przy wieloetapowych procesach występuje konieczność jakiegoś nazwania i uporządkowania (zorganizowania) ludzi wykonujących różne prace choćby po to tylko by wiedzieć z czym móc iść do kogo bez konieczności znania wszystkich osobiście. Nadto obiektywnie istnieją też różne specjalizacje i specyficzne umiejętności, których złożenie jest potrzebne by dostarczyć usługę czy zbudować produkt. Niewątpliwie ułatwia i porządkuje tak myślenie jak i komunikację gdy można uprościć opis organizacji do ról i ich interakcji bez konieczności analizowania i opisywanie wielowymiarowego bytu jakim jest człowiek pełniący każdą z tych ról.
Powstaje zatem swego rodzaju sprzeczność – etykiety zawężąją postrzeganie i mają wiele niefajnych skutków ubocznych, wszelako opisanie załogi liczącej paręset osób firmy określeniem „ludzie” nie jest zbyt przydatne. Jak z tej sprzeczności wyjść?
Jednym rozwiązaniem jest to, co proponuje Scrum – w kontekście konkretnego zespołu wszyscy to „deweloperzy”, a pełniona rola zmienia się zgodnie z możliwościami człowieka i potrzebami zespołu. Wszelako jest to jednak „lokalna optymalizacja” – jeśli coś rozwiązuje, to tylko w obrębie jednego zespołu i tylko w obrębie kompetencji i umiejętności bezpośrednio związanych z jego pracą.
Szersze podejście proponuje Holakracja, która wprowadza explicite rozdział pomiędzy rolami a ludźmi. W ujęciu Holakracji organizacja jest stworzona z ról, które mają określone odpowiedzialności i uprawnienia. Ludzie nie są rolami, a jedynie je „animują”. Nie ma zatem relacji jeden-do-jeden między rolą a człowiekiem. Jeden człowiek może animować wiele ról jednocześnie (np. ta sama osoba może jednocześnie animować rolę „programista” jak i rolę „marketer w mediach społecznościowych”) jak również wiele osób może animować jednocześnie jedną rolę (np. trzy osoby animujące rolę „sprzedawca”). Z założenia ról nie tworzy się „dla ludzi” (czyli mając na uwadze konkretną osobę), ale by zaspokoić potrzeby organizacji – nowa rola tworzona jest wtedy, kiedy uważa się, że rozwiąże ona jakąś bolączkę, a nie wtedy kiedy trzeba kogoś zatrudnić czy znaleźć mu miejsce. Dopiero kiedy jest rola zastanawiamy się kto mógłby ją „animować”.
Wdrożenie Holakracji to duże przedsięwzięcie (wdrożyć ją w pełni nie jest łatwo – bagaż formalizmów i konieczność całkowitej zmiany sposobu funkcjonowania powodują, że jest to trudny proces), ale można wykorzystać to podejście do kwestii ról bez zastosowania całości. Wystarczy po prostu przyjąć ten sposób myślenia, ogłaszając go załodze wraz z wyjaśnieniem, a następnie wprowadzić jakiś widoczny sposób przypisywania ludzi do ról, w którym nie trzymamy się relacji „człowiek == rola”.
Można się przy tym wspomóc praktyką „Project Credits” z Management 3.0, która wprowadza dwa równległe systemy etykiet. Jedne to klasyczne „job titles”, które są raczej stałe i których używa się przede wszystkim na zewnątrz po to, by ludziom nie znającym dobrze naszej organizacji łatwiej było zrozumieć czym się mniej-więcej zajmuje dana osoba (a więc z czym można do niej przyjść). Drugie („Project Credits”) to kontekstowe i zmienne nazwy opisujące to, co dana osoba aktualnie robi. Oczywiście, wewnątrz organizacji dużo ważniejsze są te drugie etykiety.
To tylko dwa przykłady – z pewością da się wymyślić jeszcze inne praktyki. Najważniejsze to zerwać z etykietowaniem ludzi trwale opisem ich roli w ten czy inny sposób.
-
Jak zetknąłem się z Agile
Z Agile zetknąłem się równo dziesięć lat temu, w roku 2006. Taka okrągła rocznica to dobra okazja, żeby podzielić się tą historią.
Aby o tym opowiedzieć muszę się jednak cofnąć do roku 2005. Wtedy właśnie zostałem menedżerem w nieistniejącej już firmie Air Bites Polska. Firma ta utworzona przez Swisscom (szwajcarski odpowiednik TP S.A. z tą różnicą, że nadal kontrolowany przez państwo Helwetów) była nowym ISP oferującym tani, prosty dostęp do Internetu. Był to zasadniczo startup, a ja odpowiadałem tam za stworzenie pionu technicznego. Od zera. Obejmowało to budowanie i konserwację sieci, podłączanie nowych klientów, bieżące operowanie siecią – i rozliczenia. By nie przedłużać tej historii skupię się tylko na tym ostatnim elemencie, ponieważ system bilingowy pisaliśmy sobie sami, także od zera.
Zaczęło się to od zatrudnienia pierwszego programisty, Adama (zresztą świetnego gościa, który obecnie po paroletnim pobycie w Google i wzięciu udziału w rejsie żeglarskim dookoła świata kreuje technikę w pewnym londyńskim startupie), który położył podwaliny pod system. Powoli rekrutowałem kolejnych aż doszliśmy do zespołu liczącego 5 czy 6 osób (było to 10 lat temu, nie pamiętam już dokładnie) w skład którego poza programistami wchodziła także testerka która dbała również o dokumentację. Jak zespół ten pracował?
Ano, ponieważ miałem pełnię władzy nad obszarem techniki i dużo swobody (żadnych narzuconych procesów i standardów) zorganizowałem pracę w sposób, który był dla mnie najbardziej naturalny i normalny:
- prowadziłem w narzędziu zwanym OmniOutliner listę funkcjonalności, które powinny się w systemie znaleźć w najbliższym czasie,
- raz na miesiąc spotykałem się z zespołem i dyskutowaliśmy o tym co dodamy do systemu w tym miesiącu – lista była przy tych dyskusjach wyświetlana z rzutnika na ścianę i dynamicznie zmieniana/edytowana w razie potrzeby,
- potem zespół dyskutował jeszcze dodatkowo jak to zrobi, w późniejszym okresie przyklejali do ściany w swoim pokoju karteczki z zadaniami,
- z inicjatywy Adama zespół codziennie się spotykał i omawiał co będzie robił, mieli także uzgodnione standardy kodowania i testów, część testów – zwłaszcza API – była zautomatyzowana,
- na bieżąco był dostępny system testowy zasilany wprost z repozytorium (wtedy w nowoczesnym narzędziu pt. Subversion), gdzie często zaglądałem patrząc co się pozmieniało,
- pod koniec miesiąca spotykaliśmy się, zespół pokazywał co zrobił, po czym robiliśmy wydanie – i dzień po wydaniu proces się powtarzał.
Tak to działało, kiedy to pewnego dnia w 2006 roku Adam przyniósł mi tą książkę i powiedział, że koniecznie muszę ją przeczytać. Tak też zrobiłem i wtedy odkryłem, że to co robiliśmy w zasadzie ma nazwę – jest to mianowicie Scrum. Brakowało nam tak naprawdę trzech rzeczy:
- sztywnej długości sprintu (czasem wydawaliśmy wcześniej a czasem później o parę dni),
- formalnie określonego kryterium ukończenia (Definition of Done),
- retrospekcji.
Oczywiście natychmiast te elementy wprowadziliśmy i można powiedzieć, że od razu, bez wielkich bóli i problemów pracowaliśmy już w pełnym Scrumie. Dość szybko też okazało się, że miesięczny sprint jest stanowczo zbyt długi – i skróciliśmy sprinty do dwóch tygodni, co znacznie poprawiło nam relacje z biznesem. Potem na bazie tego zespołu powstało Code Sprinters, gdzie tradycje pracy w ten sposób były kontynuowane w pracy dla zewnętrznych klientów – ale to już inna historia.
Dlaczego zdecydowałem się podzielić historią mojego osobistego zetknięcia z Agile na blogu?
Po pierwsze dlatego, że jak wiem z doświadczenia jest ona dość niezwykła – dla większości ludzi, z którymi spotykam się w mojej pracy Agile (Scrum czy Kanban) było odkryciem idącym w poprzek tego co wcześniej znali i co robiono u nich pracy. Tymczasem dla mnie to było na zasadzie: „o rany, to to ma już nazwę?” – nazwanie, uzupełnienie tego co już stosowałem, w czym już pracowałem.
Po drugie dlatego, że to doświadczenie – jak i kolejne lata pracy z zespołami Code Sprinters budującymi oprogramowanie dla klientów – dały mi jedną rzecz, której wielu nawet praktyków Agile nie ma: doświadczenie pracy w tak zwanym „pełnym” albo „książkowym” Scrumie.Przydaje się to kiedy pojawiają pytania z gatunku „ale czy to gdzieś może tak działać?”. Wiem, że może, bo sam tego doświadczyłem, co więcej, to dla mnie naturalny i normalny sposób pracy. Jest oczywiście wiele czynników, które spowodowały, że było to dla nas możliwe, wśród których warto wyróżnić ten oto, że organizacja była tak zrobiona od samego początku nie musieliśmy zatem mozolnie wychodzić z dysfunkcji i walczyć z zaszłościami. Niemniej – da się – i fajnie wiedzieć to z własnego życia, a nie z książek czy konferencji.
Ale jeszcze bardziej przydaje się to przy „leczeniu” ułomnego Agile, nieudanych „wdrożeń”, pomaganiu zespołom i firmom z problemami. Nie idzie nawet o to, żeby wszystkich doprowadzić do takiego idealnego stanu – bo to z różnych powodów nie zawsze jest możliwe – ale o to, by mieć go jako punkt odniesienia i przypomnienie, że to jest jednak możliwe.
Każdemu życzę takiego doświadczenia – zetknięcia ze „zdrowym Agile”, zdrową kulturą – a już zwłaszcza tym, którzy myślą o byciu Agile Coachami czy trenerami.
-
Czemu pracuję z korpo?
Ostatnio kolega Agile Coach zapytał mnie czemu przy moim sceptycyzmie wobec koncepcji „transformacji Agile” w korporacjach wciąż szkolę i doradzam w tychże korporacjach.
Robię tak czterech powodów:
- po pierwsze rozróżniam „bycie Agile” od stosowania metod Agile – w korpo da się zastosować metody Agile (np. Scrum czy Kanban w teamach, Nexus albo LeSS przy większej skali itp.) i uzyskać w ten sposób mniejszą lub większą poprawę (w tym mam na myśli zarówno poprawę wyników biznesowych czy wskaźników produktowych jak i poprawę jakości życia tych, którzy tam pracują a ściślej tej jego części, którą spędzają w pracy),
- po drugie mam dużo szacunku dla ludzi, którzy mimo wszystko próbują zmieniać duże organizacje (co zawsze podkreślam) i w związku z tym ich w tym wspieram – zwłaszcza kiedy mnie o to poproszą; nawet jeśli nie mam wiary w to, że ich wysiłek przyniesie długofalową głęboką zmianę w ich organizacjach to przynajmniej może przynieść (i najczęściej przynosi) pewne konkretne efekty i korzyści w ich zespołach a czasem i większych grupach,
- po trzecie nie uważam, że zjadłem wszystkie rozumy i jestem otwarty na przypadek, który przekona mnie, że nie mam racji,
- po czwarte „nie potrzebują lekarza zdrowi, lecz ci, którzy się źle mają”. I tu mała metafora: przychodzi do lekarza facet chory na płuca, który tak poza tym pali. Wiadomo, że póki pali wyleczyć się go całkiem nie da. Ale trochę mu pomóc, wydłużyć życie, podnieść jego komfort i owszem. Leczyć czy pryncypialnie odmówić? Ja wybieram to pierwsze.
Wciąż uważam, że nie da się przerobić korpo na „zwinną firmę” (co wielu wciąż obiecuje) metodą transformowania (a więc przekształcania) istniejących struktur i procesów. Da się w ten sposób uzyskać pewne usprawnienia (i to jest coś warte), ale nie stworzyć nową formę organizacji, nową jej wersję. By tego dokonać trzeba ją zbudować od zera – albo jako startup albo jako „nowotwór” obok firmy-matki, który ją w końcu „zje” (to np. poleca John Kotter). W każdy przypadku – czy to by uzyskać pewne usprawnienia czy to by zbudować coś nowego – pomocna jest wiedza. Tej wiedzy dostarczam jak umiem najlepiej.
Tak na marginesie „Agile” jest w ogóle za małym konceptem, żeby na nim zbudować nowe organizacje. Za małym, bo skoncentrowanym na oprogramowaniu – a przynajmniej produktach – a tu trzeba objąć więcej i pochylić się głównie nad organizacją jako taką a nie tylko niektórymi procesami, samą organizację poddać empirycznej ewolucji. Do tego zmierza Holakracja i inne podobne podejścia. Być może to byłoby w stanie zmienić istniejące organizacje od środka. Ale to temat na kolejny post/artykuł.