Dziel i rządź

Często wielu kierowników czy managerów różnego poziomu, w różnych organizacjach, staje przed wielką decyzją do podjęcia: “Jak podzielić ludzi na zespoły?”. Sprawa tworzenia zespołów jest skomplikowana. W grę wchodzi duża liczba czynników takich jak aktualne relacje, kompetencje miękkie czy poziom umiejętności. Wszystko to, pomnożone przez liczbę specjalizacji dziedzinowych, podniesione do potęgi aktualnej wewnętrznej opinii osoby dokonującej podziału na temat każdego podwładnego.

Na dany problem nie można zareagować inaczej niż “Challenge accepted!” i wziąć się do roboty. Przy pierwszych lepszych zagwozdkach pytając się “po cichaczu” innych (najczęściej “tych lepszych”) z kim to by nie było im łatwiej być w zespole.

Część tych ludzi robi to bardzo świadomie, dbając o zrównoważenie grupy charakterami i poziomem energii w grupie. Część z nich zdaje sobie sprawę z tego, że prędzej czy później powstaną w zespole konflikty, które konstruktywnie rozwiązane, pomogą im pójść dalej. Niestety, część z nich będzie pojawiające się konflikty odbierać jako swoje osobiste porażki i być może posunie się do ostrych reakcji typu odsunięcie zespołu od źródła problemu. Ja sam niedawno stanąłem przed niemałym (dla mnie) wyzwaniem ułożenia 4 zespołów z 30-osobowej grupy ludzi, która wcześniej pracowała w silosach kompetencyjnych (celowo nie nazywam ich zespołami, o czym możesz przeczytać w moim poprzednim artykule). Piszę ten post, żeby podzielić się z Wami moimi bezpośrednimi doświadczeniami i wnioskami, tak abyście i Wy mogli przy takiej okazji tu zajrzeć i zobaczyć jak to można zrobić oraz jak się do tego odpowiednio przygotować. Ciekawostką jest też, że dokonaliśmy tego w Tooploox z zespołem mocno rozproszonym (czyli w przestrzeni i czasie – członkowie zespołów nie byli pogrupowani na przykład w dwóch lokalizacjach, tylko solidnie rozproszeni po Polsce i USA)

Pierwotny układ

W momencie, w którym wraz z PO i klientem, na podstawie m.in. informacji zwrotnych od ludzi, podjęliśmy decyzję o zlikwidowaniu silosów kompetencyjnych istniało ich 5:

  • Back-end: 9 osób
  • Front-end: 5 osób
  • Mobile: 8 osób
  • Data Science: 4 osoby
  • Product Development: 4 osoby

Razem 30 osób. Nie będę w tej chwili poruszał tematyki samych problemów jakie stwarzał dany układ grupowy. Jest to bardzo ciekawy temat, na który z chęcią porozmawiam przy jakimś piwie, zanim zmuszę się do napisania o tym osobnego posta. Nadmienię jednak, że aby doszło do pewnego wydarzenia zwanego Release, ilość niepotrzebnej komunikacji pomiędzy tymi grupami kompetencyjnymi sięgała minimum 50% ich czasu pracy sumarycznie (wliczając w to stracone godziny na pisanie kodu, który jednak okazał się być nieprzydatny). Ponieważ odkąd po raz pierwszy w życiu usłyszałem o tym, że warto po ludzi po prostu wpakować do pomieszczenia, powiedzieć im żeby się podzielili i zostawić w spokoju na 1,5 godziny (dzięki Ci, Tomku Włodarku!), głęboko w sercu i umyśle wiedziałem, że jest to skuteczna metoda. W sercu i umyśle, ponieważ taką okazję miałem dopiero po 3 latach od poznania tej teorii. Ponieważ wszyscy interesariusze, którzy mieli wpływ na to, w jaki sposób podzielą się zespoły obawiali się tak liberalnej metody, zacząłem myśleć nad jakąś alternatywą, która pozwoli im zachować poczucie bezpieczeństwa, a nie ograniczy swobody ludzi, których bezpośrednio dotyczy cały temat – czyli członków przyszłych zespołów. Sam proces tworzenia zespołów, który miałem przyjemność poprowadzić i zaobserwować był dla mnie niesamowicie ekscytujący. Nie obyło się bez problemów – oczywiście wspomnę o nich, bez tego uważałbym ten post za bezwartościowy.

Metoda

Metoda sama w sobie jest dosyć prosta, polega na przyrostowym budowaniu coraz większych grup ludzi, zaczynając od par i iteracyjnym sprawdzaniu, czy dane grupy spełniają ramy nadane przez interesariuszy.

Kolejne kroki to:

  1. Ustalenie ram działania
  2. Przygotowanie środowiska
  3. Przygotowanie ludzi
  4. Podział
    1. Określenie kompetencji
    2. Łączenie w grupy
    3. Tworzenie zespołów
  5. Zakończenie i zbieranie informacji zwrotnej

Poniżej dokładnie opisuję przebieg całej metody

Ustal ramy

Spróbuj postawić się w roli wszystkich interesariuszy. W moim przypadku byli to:

  • Klient (2 osoby reprezentujące)
  • Product Owner
  • Właściciele Tooploox’a (software house, która zatrudnia ludzi dla klienta)
  • Ludzie, którzy będą dokonywać samopodziału
  • Ja sam

Owszem, niektóre z osób, które wymieniłem, uważały samopodział za coś nierealnego  – że jeśli się ludzi nie pokieruje w dobrą stronę, to sami nie będą potrafili dobrze wybrać. Ważne, żeby uszanować i nie wartościować ich zdania na ten temat. Mają prawo tak uważać, naszym zadaniem jest dać im poczucie bezpieczeństwa tego zabiegu, a nie wmawiać im że są w błędzie! Jedyny sposób na danie poczucia bezpieczeństwa to dokładny opis całego zdarzenia lub pokazanie im tego wpisu.

Na podstawie rozmów z każdą ze stron ustaliłem poniższe ramy. W nawiasach umieszczam od kogo wychodziła dana rama:

  1. Jedna osoba może być przynależna tylko i wyłącznie do jednego zespołu (ja)
  2. Osoby o wysokim stopniu w swojej kompetencji powinni podzielić się możliwie najrówniej na wszystkie zespoły (Klient, Właściciele)
  3. Każdy zespół powinien być w stanie rozwiązać każde zagadnienie z Backloga Produktu (Product Owner, ja i częściowo Klient)
  4. Żaden zespół nie powinien mieć więcej, niż 9 osób. W przypadku odstępstwa musi być to odpowiednio uargumentowane i zaakceptowane przez wszystkich (Klient, Product Owner, Właściciele, ja)
  5. Jeśli jakaś osoba pracuje zdalnie (szczególnie w innej strefie czasowej), nie może być jedyną kompetencja w zespole. Najlepiej gdyby jej lokalny odpowiednik na co dzień przebywał w siedzibie firmy (Ludzie)
  6. Jeśli okaże się, że jakikolwiek zespół nie ma wszystkich potrzebnych kompetencji do wykonywania zadań, powstaje zależność pomiędzy zespołami, która musi zostać uwzględniona podczas każdej sesji planowania Sprintu (Product Owner, ja)

Pomyśl o FAQ i wyślij wszystkim wcześniej

Zanim w ogóle przystąpiłem do działania, popatrzyłem czy w sieci nie ma żadnych pomocnych informacji na ten temat. Znalazłem bardzo fajne materiały od Nomad 8 (swoją drogą możecie ich użyć jako inspiracje lub gotowce do Waszych działań – ja akurat zainspirowałem się ich schematem. Nie mogłem go wykonać ze względu na rozproszenie teamu). Najcenniejszą dla mnie rzeczą (bo sam o tym nie pomyślałem) było FAQ. Zwykłe FAQ złożone z kilku pytań, które na pewno padną. Takie oto FAQ ułożyłem wzorując się na przykładach:

Narzędzia

Rozproszenie zespołu, mocno ogranicza uczestnictwo w jakichkolwiek grupowych wydarzeniach, które mogą potencjalnie wykorzystać sumę, lub więcej niż sumę, inteligencji grupy. Osobiście uważam, że jeśli jedna osoba z zespołu jest w tym samym pomieszczeniu, ale oddzielona fizycznie od reszty grupy – jest to już zespół rozproszony. Są narzędzia, które potrafią zmniejszyć czynnik izolacji i mimo, że za każdym razem, gdy ich używam czuję mocny ból mózgu, to gdyby ich nie było, prawdopodobnie bym sobie nie poradził. Do sprawnego przeprowadzenia tego ćwiczenia użyłem:

  1. Google Hangouts
  2. Realtimeboard
  3. Slack
  4. Kalendarz

Ważną uwagą w kontekście podejmowania decyzji o zatrudnieniu zespołów rozproszonych może być to, że przygotowanie wszystkiego na tip-top w tym kontekście jest kluczowe i stąd bardzo kosztowne. Załóżmy, że przygotowujący to wydarzenie Scrum Master zarabia 120 PLN brutto za godzinę pracy, to przygotowanie wszystkiego od początku do końca kosztuje minimum 24 godziny pracy, czyli prawie 3000 PLN – mam nadzieję, że mój artykuł znacznie pomoże Ci w obniżeniu tych kosztów. To, co normalnie powiedziałbyś do grupy w jednym pomieszczeniu, jako zadanie do wykonania, musi mieć swoją reprezentację we wszystkich potrzebnych narzędziach oraz być umieszczone na jasnym planie działania. Inaczej wszyscy się totalnie pogubią. Pamiętaj o jednym – nawet jak się super postarasz, ludzie za pierwszym razem i tak się pogubią – przygotuj się na to.

Realtimeboard

Realtimeboard to kolaboratywne narzędzie imitujące tablicę. Spośród wielu, które próbowałem wydało się najbardziej sensowne, jest również najdroższym narzędziem tego typu na które udało mi się natrafić. Narzędzie jest sceną główną całego podziału – im lepiej się do tego przygotujesz, tym lepiej wszystko wyjdzie.

Przygotuj narzędzia, zaproś wszystkich i do dzieła!

W zaproszeniu umieść cel i dokładną agendę. Jeśli osoby nie uczestniczące w samym procesie, ale wpływające na decyzje z nim związane “chcą popatrzeć” – śmiało, niech obserwują. Pamiętaj by wcześniej ich obecność zakontraktować z uczestnikami. Ja o tym nie pomyślałem – wyszło z tego trochę drobnych problemów 🙂 W kontrakcie zawrzyj, że interesariusze mogą jedynie obserwować.

Poniżej opisany scenariusz jest przygotowany dla ilości osób, z którą miałem do czynienia – jeśli ilość członków zespołu jest drastycznie inna – musisz swój plan dostosować i z chęcią Ci w tym pomogę.

Określenie kompetencji

  1. Zapraszamy uczestników do podzielenia się losowo w 4-5 grup.
  2. Każda grupa otrzymuje link do Hangouts oraz swój kanał Slack lub jakiś dokument do kolaborowania.
  3. Zapraszasz ich na sesje, której celem jest określenie umiejętności potrzebnych do realizowania każdego elementu Backlogu Produktu w formie prostej listy kompetencji (timebox max. 30 minut).
  4. Podczas sesji wchodzisz regularnie na Hangouts i pomagasz grupom (fajnie, gdybyś miał kogoś do pomocy).
  5. Po sesji umieszczacie wszystkie listy kompetencji na jednej tablicy (Realtimeboard) i zaczynasz moderować, aby uzyskać jedną wspólną listę będącą połączeniem wszystkich pozostałych. U mnie wynik był taki:
  6. Zauważ, że wynik to w zasadzie macierz kompetencji, z którą możesz pracować później.
  7. Zarządź 10  minut przerwy (opcjonalnie).
  8. Poproś ludzi o przypisanie sobie wypisanych kompetencji i określenie ich poziomu. U mnie wyszło to tak, że ludzie się zorganizowali do ulepszenia schematu, który im podałem. Końcowy efekt był taki, że dodali sobie swój ogólny poziom kompetencji oraz to co planowałem – podział wg konkretnych kompetencji.
  9. Jesteś w połowie zadania – zarządź 30 minut przerwy, wszyscy na pewno są już zmęczeni

Podział właściwy

  1. Poproś ludzi o dobranie się w pary – zrobią to używając Realtimeboard poprzez przesuwanie swoich karteczek po wcześniej przygotowanych polach.
  2. “Wolne rodniki” prosimy o dołączenie do grupy tam, gdzie pasują wg. ram podziału.
  3. Sprawdzamy czy wszystko się zgadza jeśli chodzi o ramy. Jeśli nie, szukamy zamiany.
  4. Jeśli wszystko jest zgodnie z ramami, prosimy pary, aby połączyły się w czwórki:
  5. Powtarzamy punkt 3.
  6. Prosimy o połączenie czwórek w ósemki.
  7. Powtarzamy punkt 3.
  8. Patrzymy, czy ze stworzonych ósemek powstał samowystarczalny zespół. Jeśli tak to świetnie, a jeśli nie, to rozglądamy się za możliwymi działaniami. Słuchamy feedbacku od członków zespołu i odpowiednio reagujemy. Każdą zmianę robimy pojedynczo.
  9. Pytamy się czy każdy czuje się komfortowo w danym układzie.
  10. Odpalamy szampana i bijemy brawo.

Zakończenie

Zostaje tylko pilne zaopiekowanie się nowo powstałymi zespołami, zachęcenie do stworzenia nazwy, spisanie kontraktów – wszystko, co czeka każdy nowy zespół. Koniecznie udokumentuj wynik ćwiczenia. Nie zapomnij wspomnieć o tym, że skład zespołu nie jest wykuty w kamieniu jak przykazania, jednak ramy określone przez wszystkich zainteresowanych są cały czas aktualne. Dodatkowo jeśli ma nastąpić jakakolwiek zamiana lub przejście – obydwa zespoły muszą na to wyrazić zgodę.

Oczywiście, dobrze jest również po samej operacji zebrać indywidualnie informację zwrotną od każdego uczestnika spotkania i przyjrzeć się temu co można ulepszyć w samym wydarzeniu.

Przemyślenia końcowe oraz napotkane problemy

Całość zajęła nam około 3 godzin. Ludzie byli po tym bardzo wycieńczeni, nie mówiąc o mnie – stres związany z tym eksperymentem był bardzo duży. Każde zadanie angażujące cały zespół jest bardzo kosztowne i podchodzę to tego z wielką starannością. Powtórka tego ćwiczenia w krótkim czasie jest w mojej ocenie nierealna, także jeśli coś źle pójdzie u Ciebie – zaakceptuj wyniki i odczekaj trochę czasu, aż wszyscy ochłoną zanim wyjaśnisz wszystkie problemy.

Co poszło u mnie nie tak i na co powinieneś zwrócić uwagę:

  • Wszyscy ludzie powinni bardzo dobrze znać Backlog Produktu i jeśli to jest nowy Backlog – wcześniej go odpowiednio wyklarować (refinement).

U mnie zdarzyło się tak, że zmiany w Backlogu były dokonywane nawet na dzień przed ćwiczeniem i miało to swoisty wpływ na wynik podziału

  • Bądź asertywny, trzymaj się kontraktów.

Podczas jakichkolwiek dyskusji przechodź do ram spotkania lub ewentualnie wcześniej zadaj maksymalnie kilka otwartych pytań przekazujących kontrolę grupie, a nie pogłębiaj ich. Rób to oczywiście w łagodny sposób. Nie przejmuj kontroli nad podziałem. U mnie panika i zmęczenie pod koniec skończyły się stworzeniem czterech interdyscyplinarnych zespołów, w tym jednego wysoko wyspecjalizowanego.

  • Za każdym razem upewnij się indywidualnie z każdą grupą, czy dobrze zrozumiała cel zadania.
  • Wcześniej upewnij się czy każdy jest gotowy do podziału interdyscyplinarnego.

U mnie, na sam koniec, jak powstały już zespoły, pojawił się u niektórych strach i przez to mały chaos – do dzisiaj spłacamy długi powstałe w wyniku tego zdarzenia.

  • Bardzo dobrze opisz wszystko wcześniej, kto ma gdzie kliknąć, gdzie co znaleźć – inaczej ludzie się pogubią.

Reszta poszła bardzo sprawnie, wystawiłem sobie bite 3 na 5.  Z informacji zwrotnych jakie otrzymałem od ludzi:

  • Podobało im się wspólne układanie kompetencji.
  • Użycie Realtimeboard bardzo pomogło.
  • Nie do końca klarownie przekazałem wszystkie informacje wcześniej. Kilkoro ludzi się trochę pogubiło i niestety nikt mi podczas samego ćwiczenia tego nie zgłosił – Ty również na to nie licz.
  • Nikt nie odczuwał dyskomfortu w związku z zespołem do którego trafił.
  • Interesariusze byli bardzo zadowoleni, mimo że nie ukrywali wczesniejszych obaw co do całego przedsięwzięcia.

Z pewnością doświadczyłem jak bardzo obciążające jest pracowanie z zespołami rozproszonymi. Każde nieporozumienie kosztuje kilkukrotnie więcej, niż z zespołem, z którym działamy w jednym miejscu. Jest tak, ponieważ:

  • Możesz się o nieporozumieniu nie dowiedzieć – przestrzeń i internet jest ogromną barierą do zgłaszania uwag oraz utrudnieniem w obserwacji.
  • To co zauważyłbyś w chwilę na jednej sali, jest nierealne do zauważenia przez komunikator.
  • Ludzie na pewno nie wchodzą na odpowiedni poziom zaangażowania grupowego.
  • Każdy zdaje sobie sprawę z trudności zadania i nie chce przerywać i psuć przebiegu.
  • Wyjaśnienie każdego nieporozumienia zajmuje więcej czasu, niż gdyby się to działo lokalnie.

Jeśli masz zamiar kiedykolwiek przeprowadzać coś podobnego, napisz do mnie, a z chęcią Ci pomogę i udzielę dokładniejszych rad. Powodzenia!

Scrum Expert

Lider transformacji, specjalizujący się w organizacjach do 100 osób. Naturalnie zwinny, w sytuacjach wymagających natychmiastowej decyzji jest niezastąpiony!