-
Gdy masz tylko młotek….
Pracując jako doradca i ekspert od metod zwinnych nieustannie spotykam się pewnym nieporozumieniem, które najkrócej streścić można w jednym zdaniu: „Agile to Scrum”. Innymi słowy polega ono na z gruntu błednym przekonaniu, że tak zwana „transformacja Agile” (czyli zmiana organizacji w nowoczesną, zwinną, sprawnie zarządzaną) polega na… wdrożeniu Scruma. Sprowadza to duży temat jakim jest Agile i w ogóle nowoczesne zarządzanie do jednej tylko metodyki pracy zespołowej, która choć bardzo dobra nie jest ani jedyną metodą Agile ani nie załatwia wszystkich problemów (zwłaszcza na skalę organizacji).
Nieporozumienie to wydaje się dość niewinne – ot, typowe niezrozumienie tematu przez osoby, dla których jest nowy. Niestety, przekonanie, że „Agile == Scrum” jest na tyle powszechne, że prowadzi do dwóch niepożądanych zjawisk, które do tego wzajemnie się napędzają.
Pierwszym są „wdrożenia Agile” polegające na odgórnym zadekretowaniu Scruma jako metodyki czy procesu, który ma obowiązywać wszystkie zespoły. Zazwyczaj początkiem takiej sytuacji jest kiedy ktoś mający władzę – menedżer działu IT, czasem prezes – zostaje „zainfekowany” fałszywym uproszczeniem, że „Agile to Scrum” czy to przez niekompetentnego konsultanta czy to wskutek lektury jakiegoś powierzchownego artykułu.
Dlaczego takie odgórne narzucenie Scruma jest złe? Scrum jest tylko jedną z wielu metod i praktyk Agile. Nie jest z pewnością metodą dla wszystkich zespołów, bo wymaga spełnienia pewnych warunków by w ogóle działać a co dopiero działać dobrze. Są to m.in. takie rzeczy jak wspólnota pracy (członkowie zespołu nie wykonują indywiudalnie od A do Z osobnych prac ale tworzą wspólnie produkt, dla którego potrzebne są kompetencje ich wszystkich razem i na raz) czy wyraźne cele (sprintu i produktu). Generalizując Scrum jest najlepszy dla tworzenia nowych produktów, przechodzących fazę szybkiego rozwoju funkcjonalnego, przy pomocy zaangażowanych zespołów profesjonalistów, w firmach, których kultura zbudowana jest wokół pięciu wspierających Scrum wartości. Niestety, w wielu organizacjach tej szerzej wiedzy o Scrumie brak. Brak także wiedzy o innych metodach Agile, czasem nawet wręcz brak świadomości ich istnienia.
Zatem zamiast narzucać dekretem Scruma należy raczej ustalić cele wprowadzania metod zwinnych, zapoznać się z ich teorią i różnymi dostępnymi opcjami po czym wybierać dla każdego zespołu te metody, które pasują do niego – i tego co robi. A także spojrzeć na organizację szerzej, zająć się takimi rzeczami jak cele, metryki, kultura itp.
Drugi problem często występujący razem z pierwszym jest tzw. „mechanistyczny Scrum”, a więc „wdrożenie Scruma” polegające li tylko na przemianowaniu ról (np. z Project Managera na Product Ownera) i przymuszeniu zespołów do odbywania przepisanych w metodzie spotkań. Typowym (choć nie jedynym) symptomem takiej sytuacji jest uczynienie oficjalnym standardem organizacyjnym łączenia roli Scrum Mastera i developera w zespole oraz brak dbałości o odpowiednie przeszkolenie tych Scrum Masterów (że nie wspomnę o zespołach).
W efekcie uzyskuje się niewiele korzyści z metody – jeśli w ogóle jakieś. Ponieważ nikt nie rozumie tak naprawdę po co są te spotkania i cała reszta, a rzecz została narzucona bez sprawdzenia czy dla danego zespołu ma sens to zamiast zwinnych wydajnych zespołów uzyskujemy ludzi, którzy bez przekonania – a potem z rosnącą niechęcią – odgrywają nakazany przez kierownictwo teatrzyk. „Mechanistyczny Scrum” nagminnie towarzyszy odgórnie zadekretowanym zuniformizowanym „wdrożeniom Scrum”, bo ma dokładnie taką samą przyczynę – brak głębszej wiedzy i zrozumienia choćby samej metody (a więc tego dlaczego Scrum jest taki, jaki jest, dlaczego składa sie z takich a nie innych elementów, czemu służy i gdzie działa najlepiej), że nie wspomnę o Agile jako szerzym zjawisku.
Najgorsze jest w tym jest jednak nawet nie to, że efekty takiego wprowadzenia Scruma są mierne – dużo gorsze jest to, że nikt nie zdaje sobie sprawy z tego, że to, z czym mają do czynienia ma się nijak nie tylko do Agile ale nawet do Scruma. W efekcie organizacja produkuje całe zastępy ludzi, którzy są święcie przekonani, że pracują w Agile i świetnie wiedzą na czym polega Scrum bo przecież pracowali w nim (czasem kilka lat) – którzy tak na prawdę nie mają ani o Agile ani o Scrum pojęcia. Ta nieuświadomiona ignorancja jest niezwykle trudna do wyleczenia – najczęściej zdarza się to dopiero kiedy delikwent trafi wreszcie do miejsca, w którym Scrum czy jakaś inna metoda Agile jest naprawdę dobrze stosowana. Z tego powodu organizacja z mechanistycznym, zadekretowanym Scrumem jest czymś w rodzaju rozsadnika zarazy. Wychodzą z niej ludzie, którzy następnie w innych organizacjach opowiadają że „Scrum nie działa” lub co gorsza uważając się za doświadczonych reklamują się jako konsultanci od Scruma (bo nic innego nie znają – jak w tytułowym dowcipie o człowieku, który miał tylko młotek więc wszystko wyglądało mu jak gwóźdź), którzy w kolejnych organizacjach „wdrażają Scruma” w sposób, który znają z doświadczenia, co produkuje kolejnych zrażonych – i kolejnych zarażających.
Walczyć z tym fenomenem można w jednyny sposób, a mianowicie przez rzetelną wiedzę nie tylko o Scrumie, nie tylko o Agile, ale w ogóle o nowoczesnym zarządzaniu. I to staram się robić m.in. w Code Sprinters, a także na tym blogu, w moich książkach i tak dalej. Metoda to żmudna, bo wiedza ta jest mniej „seksi” od uproszczeń w rodzaju „wdróżmy Scruma i będzie Agile”, ale za to skuteczna na dłuższą metę.
-
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.