Odcinek 49. Jeśli potrzebujemy zespołu, to jak go zbudować?
W poprzednim odcinku wyjaśniłem, że Metoda Kanban to coś, co możemy zastosować do organizacji i usprawnienia pracy nie tylko w zepołach, ale i pojedynczych specjalistów czy całych projektów. A co, jeśli potrzebujemy właśnie zespołu? Jak go zbudować, jak unikać częstych błędów, szczególnie przy pracy zdalnej czy hybrydowej? Odpowiedzi szukam razem z Jimem Bensonem, twórcą koncepcji Personal Kanban, który niedawno wydał nową książkę zatytułowaną „The Collaboration Equation” („Równanie Współpracy”). Co podpowiadają doświadczenia Jima? Zapraszam do wysłuchania odcinka z wywiadem!
Jeśli jeszcze nie wysłuchałe/-aś całości tego odcinka i zastanawiasz się, na czym polega owo magiczne równanie współpracy, to już spieszę wyjaśnieniem…
„Individuals in teams create value.”
Jednostki w zespołach tworzą wartość.
Dla jasności dodam, że ten odcinek podcastu to żadne lokowanie produktu. Podejrzewam, że niewiele osób (niestety) sięgnie po samą książkę autora, ale chcę napisać, dlaczego zaprosiłem go do tego odcinka.
Po poprzednim odcinku poświęconym temu, czy do „robienia Kanbanu” potrzebujemy zespołu pojawiły się od Was komentarze, że uciekłem trochę od tematu, na który liczyliście. Tak się zbiegło w czasie, że planując kolejne odcinki zobaczyłem informacje o premierze książki Jima, o której mówił jeszcze przy okazji wywiadu w odcinku o Personal Kanban. W ciemno wydałem na tę pozycję 2 stówki i zaczytałem się w jeden wieczór. Tematy – nazwijmy to jasno – patologii onboardingu ludzi do zespołów, pracy w izolacji i promowania takiego podejścia, to niestety okrutna rzeczywistość wielu firm, z którymi przychodzi mi pracować. Samotność w walce (niepotrzebnej walce!) z zadaniem i warstwa interakcji spłycona tylko do absolutnego minimum podszytego strachem. Pomyślałem więc, że ta książka The Collaboration Equation (link nieafiliacyjny) to dobry starter do rozmowy. A miałem w głowie jeszcze coś. Kilka miesięcy temu w wywiadzie z Jimem, który usłyszałem w innym podcaście moją uwagę zwróciła pewna jego obserwacja. Otóż…
Kogo uznajemy za profesjonalistę (ang. a professional)?
Mam niepodważalne przekonanie, że pierwszym wymiarem profesjonalizmu lub po polsku zawodowstwa jest zakres umiejętności i doświadczenia. Gdy mówimy o roli technicznej w IT, to takiego profesjonalistę określa lista znanych języków programowania, ich zastosowania w projektach komercyjnych, do tego może znajomość frameworków i innych narzędzi.
Nie ma tu niestety (w krzywdzącym uogólnieniu) nic o tym, czy nie popadamy w tzw. efekt aureoli (halo effect). To że ktoś sprawnie posługuje się Javą, Figmą czy zna na frameworkach zwinnych nie powinno powodować, że projektujemy sobie, że tak samo sprawny będzie w kwestii współpracy, komunikacji itp.
Prowadzi to często to sytuacji, gdy nie mamy do czynienia z profesjonalistą, ale po prostu fachowcem kontraktorem – dajcie mi konkretne zadanie, nawet najbardziej złożone i ja je zrobię, po tym jak skończę, będę czekał na następne. Dalej i wcześniej niech się dzieje co chce.
Dzisiejsza praca i pewnie również tzw. zawody przyszłości wymagają pracy nie tylko w grupie, ale i w zespołach, a w budowaniu tych ostatnich jesteśmy jako cywilizacja po prostu bardzo, bardzo słabi.
Współdziałanie (cooperation) czy współpraca (collaboration)? Hmm?
Język potrafi mocno wpłynąć na to, co wyobrażamy sobie w głowie. Gdy mówimy słowo „współpraca”, to mamy w naszych mózgach jakieś (abstrakcyjne) znaczenie tego słowa. Inni w naszym gronie współpracowników również. Okazuje się jednak, że nasza rodzima piękna polszczyzna może nas posłać w złą stronę.
Otóż w języku angielskim słowo „cooperation” oznacza współdziałanie w celu realizacji swoich zadań, często połączonych z jednym celem. Po angielsku mogłoby to brzmieć tak: to work with other people by achieving one’s own goals as part of a common goal (źródło).
To może oznaczać niestety brak prawdziwej zespołowości, bo ja pracuję tu z Wami nad jakimś projektem, w jakimś zespole Scrumowym czy wykorzystując Kanban, po to by moje zadanie były zrobione. Serio? O to nam chodzi myśląc o współpracy?
Pomimo iż jak widzicie Tłumacz Google (kto nie używa go za często, niech pierwszy rzuci plikiem „cookie”) tak samo tłumaczy na język polski angielski termin collaboration, który oznacza bliższą temu, czego szukamy współpracę nad jednym wspólnym celem.
Wydajne, efektywne zespoły..
Idąc dalej, jeśli rozumiemy, że chcemy budować udane produkty, lubiane i polecane usługi, to okazuje się, że dzieje się to zwykle za sprawą wydajnych, efektywnych zespołów, a nie grup indywidualistów. Jim podaje w książce (rozmawiamy też o tym w wywiadzie) przykład czegoś w rodzaju call center czy help desku. W takim kontekście słyszę często, że tam nie ma sensu zespołowości, bo każdy realizuje swoje, pojedyncze, niezależne zadania. Serio? Gdy przychodzimy do takiej organizacji istotnie okazuje się, że wiele pojedynczych ticketów jest rozwiązywanych „raz, dwa”, ale pozostawia zwykle bolesne dla klientów i pracowników stosiki zadań rozgrzebanych, niedokończonych, przeterminowanych.
Dlaczego tak się dzieje? Dlatego, że praca nad nimi wymaga… No właśnie – prawdziwej współpracy, wymiany informacji, przekazania doświadczenia przez kogoś, kto wie jak go rozwiązać, ale kto zgodnie z Prawem Murphyego, akurat na ten ticket nie trafił.
Rozmowa z Jimem Bensonem, a tym bardziej jego książka poruszają wiele tematów dysfunkcji, ale również konkretnych metod radzenia sobie z tym jak ich unikać. Przykłady?
- Jeśli pozostawiamy nowego pracownika w zespole z zadaniem bez właściwego zaopiekowania (pair work, buddy, transparencja pracy – a tu wchodzi w grę Kanban, WIP Age, Obeya Rooms), to właściwie budujemy (często w sposób nieuświadomiony) kulturę – pracuj sam, szukaj rozwiązania sam, dopóki Cię o to nie zapytamy (budowanie strachu i porażki).
- Jeśli musimy lub jeszcze lepiej chcemy, być w biurze, wspólnej przestrzeni określoną liczbę dni, to niech nie będą to dni losowe, inne dla każdego, ale dni przeznaczone na takie aktywności, które będą czerpały największą korzyść i niosły największą korzyść dla osób w zespole np. planowanie, retrospektywy itp.
Jest tam tego jeszcze więcej. A Ty jak budujesz zespół?