Przemyślenia Techniki

Najstarsze i najlepsze narzędzie wspierające pracę zespołów

Narzędzia pracy zespołu

Narzędzia pracy zespołu

Pracowałem ostatnio z dwoma zespołami, w których zmienił się skład osobowy. Pierwszy zespół został pomniejszony o kilka osób, przy czym trzon zespołu pozostał bez zmian. Drugi zespół został tak naprawdę stworzony „od zera”, a ludzie tworzący ten zespół nie pracowali ze sobą wcześniej.

Dla jednego oraz drugiego zespołu zmiany te były punktem zwrotnym, który wymusił na nich chwilę refleksji, pozwolił spojrzeć w przeszłość, jak i zastanowić się nad przyszłą formą współpracy.

Pomyślałem, że to dobry moment, aby przeprowadzić proste ćwiczenie i porozmawiać o oczekiwaniach wobec konkretnych postaci w zespole. Pomogły nam w tym trzy pytania:

  • Jakie są wasze oczekiwania wobec Product Ownera?
  • Jakie są wasze oczekiwania wobec Scrum Mastera?
  • Jakie są wasze oczekiwania wobec Zespołu Deweloperskiego? (czyli w większości wobec siebie samych)

W obu przypadkach dosyć sprawnie zebraliśmy oczekiwania, omówiliśmy je oraz zapisaliśmy w postaci listy. Obydwa zespoły miały nieco inne pomysły, które wynikały między innymi z doświadczeń z przeszłości – jeśli coś nie działało wcześniej, to teraz chcieliby, aby działało to poprawnie.

Przykładowo, oczekiwanie wobec Product Ownera „musi być decyzyjny”, może świadczyć o tym, że poprzednio zespół doświadczył pracy z osobą, która nie miała ostatniego słowa w kwestii rozwoju produktu.

Tak stworzone listy mogą być świetnym materiałem wspomagającym rozwój zespołu. Z jednej strony, dla osób pełniących konkretną rolę (Product Owner, Scrum Master) jest to drogowskaz, który mówi im o potrzebach reszty teamu. Pozwala rozwijać brakujące umiejętności lub upewnić się, że pewne postawy są doceniane przez zespół.

Z drugiej strony jest to lista, do której można się odwołać w kryzysowych sytuacjach i zastanowić się, czy spełniamy zebrane wcześniej oczekiwania, a także sprawdzić, czy któreś z oczekiwań uległo zmianie.

Dostrzegam w tym ćwiczeniu niewielkie ryzyko – pewne oczekiwania wobec ról mogą być bądź nie do spełnienia w krótkim czasie, bądź nieadekwatne wobec konkretnej roli. Sądzę jednak, że nie ma to ostatecznie dużego znaczenia. Zespół po pewnym czasie sam do tego dojdzie i w razie potrzeby dokona adaptacji.

OK, wystarczy już pisania o samym ćwiczeniu. Największa jego wartość to – wbrew pozorom – nie lista ze spisanymi oczekiwaniami, a podsunięcie zespołowi sprawdzonego narzędzia, które w przyszłości pozwoli na rozwiązywanie problemów dowolnego kalibru.

To narzędzie to szczera i otwarta komunikacja.

Fotografia użyta na licencji Creative Commons od użytkownika juanpol.

Moje najbliższe warsztaty

Warsztat „Labirynty Scruma” — Warszawa — 23-24 września 2019: podczas 2-dniowego, autorskiego warsztat na bazie mojej książki, przepracuję z Tobą najczęstsze pułapki w Scrumie oraz wskażę sprawdzone sposoby, jak sobie z nimi radzić.

Zapisz się na warsztat >>
Jacek Wieczorek
Jestem Agile Coachem i praktykiem podejścia agile. Napisałem książkę "Labirynty Scruma" o sprawdzonych sposobach na najczęstsze pułapki w Scrumie. Pomagam przekształcać organizacje w miejsca, w których efektywnie tworzone są wartościowe produkty. Prowadzę bloga agilecoaching.pl, współtworzę podcast Porządny Agile oraz portal Agile247. Na co dzień pomagam klientom działając jako konsultant w firmie 202 Procent, którą współtworzę z pasjonatami zwinności.
Mogą Cię zainteresować poniższe wpisy
Premiera podcastu „Porządny Agile”
Teoretyzowanie oraz spekulacja w tworzeniu oprogramowania
6 komentarzy
  • Patrycja Lis 30,2015 at 13:14

    Hej,
    Chcę podobne ćwiczenie zrobić na retro. Zastanawiam się czy warto rozdzielić oczekiwania np. inny kolor karteczek na oczekiwania zespołu wobec SM a inny PO wobec SM? Myślisz, że warto tak zrobić?

    • Jacek Wieczorek Lis 30,2015 at 20:37

      Cześć – myślę, że takie rozwiązanie mogłoby wpłynąć na czytelność prezentowanych danych, nie spodziewałbym się jednak innych znaczących zmian. Kolor kartki to drobiazg.

  • Jacek Wieczorek Sty 7,2013 at 21:36

    Super – jestem ciekawy Twoich obserwacji po ćwiczeniu. Koniecznie daj znać.

  • Bogdan Sty 7,2013 at 08:55

    Dzięki Jacek za szczegółowy opis! Mam zamiar wypróbować Twoje ćwiczenie na jednej z retrospektyw.

  • Jacek Wieczorek Sty 6,2013 at 19:42

    Cześć Bogdan, dzięki za ciekawe pytanie.

    W obydwu zespołach przeprowadziliśmy to ćwiczenie nieco inaczej.

    W pierwszym zespole na początku pokazałem zawieszony na ścianie arkusz papieru, który podzielony był na 3 kolumny (Scrum Master, Product Owner, Zespół Deweloperski). Tytuł tej tabeli, który napisałem pisakiem na samej górze brzmiał „Dream Team”. Poprosiłem zespół, żeby każdy samodzielnie i w ciszy zastanowił się, a następnie wypisał na oddzielnych, samoprzylepnych kartkach oczekiwania wobec konkretnych ról, tak aby stworzyć wspomniany Dream Team. Zespół miał kilka minut na to ćwiczenie, a kto wcześniej skończył, ten podchodził do arkusza i przyklejał swoje oczekiwania w odpowiednie kolumny. Zespół od razu generował kartki dla wszystkich trzech ról. Poprosiłem też, aby – jeśli widzą taką możliwość – od razu grupować kartki oraz eliminować zdublowane pomysły. Kiedy wszyscy skończyli, chętna osoba odczytała po kolei wszystkie kartki i jeśli coś było nie jasne, autor takiej kartki w kilku słowach tłumaczył, co miał na myśli. Nie było sytuacji, żeby kartki wzajemnie się wykluczały – gdyby pojawiła się taka sytuacji, zachęciłbym zespół do przedstawienia obydwu perspektyw i wzajemnego zrozumienia, z czego może to wynikać. Kiedy osiągnęliśmy wspólne zrozumienie kartek, zaprosiłem do przeprowadzenia drugiej części ćwiczenia.

    Przygotowałem w międzyczasie kolejny arkusz, którego celem było określenie, które z przygotowanych wcześniej oczekiwań są aktualnie spełnione, a które nie. Nie miałem jednak gotowego pomysłu jak to zrobić, ponieważ pomysł, aby odnieść się na „wykresie” narodził mi się w trakcie prowadzenia ćwiczenia. Bardzo fajny pomysł padł od zespołu, a mianowicie abyśmy rozłożyli nasze oczekiwania wobec ról na osi, która od lewej strony była opisana „nie mamy tego”, a po skrajnej prawej stronie „mamy to”. Każda rola (SM, PO, Zespół Deweloperski) otrzymał swoją oddzielną oś. Stąd zarówno SM, PO jak i Zespół Deweloperski uzyskał obraz, jak Zespół Scrumowy jako całość widzi każdą z ról. Poprosiłem, aby rozmieścili wcześniej przygotowane kartki na osiach. Zespół przyklejał karki, dyskutował, sortował, zamieniał miejscami, a gdy skończył się timebox, każdą kartkę omówiliśmy (dokładniej, aniżeli na początku ćwiczenia) w kontekście jej umiejscowienia na osi. Zastanawialiśmy się, z czego wynika takie, a nie inne rozmieszczenie, oraz myśleliśmy jak wzmocnić słabsze cechy oraz z czego wynikają te silniejsze.

    Natomiast w drugim zespole, zadałem te trzy pytania pod koniec ich spotkania zapoznawczego (coś w stylu kick-off meeting). Po każdym pytaniu pojawiały się oczekiwania, które po omówieniu przez zespół, zapisywałem na kartce. Ostatecznie powstały cztery kartki – oczekiwania wobec Product Ownera, Scrum Mastera, Zespołu Deweloperskiego oraz oczekiwania wobec mojej roli, czyli ich zewnętrznego coacha. Nie zdecydowałem się na przeprowadzenie drugiej części ćwiczenia, ponieważ – tak jak pisałem w powyższym wpisie – był to kompletnie nowy zespół i uznałem, że trudno było by im było ocenić, co „mają” a czego „nie mają”. Zapewne wrócimy do tego ćwiczenia w przyszłości.

    Jeżeli coś napisałem niedostatecznie jasno – daj proszę znać.

  • Bogdan Sty 4,2013 at 11:07

    Hej

    Ciekawe ćwiczenie. Będę wdzięczny za więcej technicznych wskazówek, jak takie spotkanie przeprowadzić. Np. czy lista powstawała zespołowo (tzn. każdy podawał na głos swoją propozycję, a jedna osoba zapisywała) czy też może najpierw każdy osobiście w ciszy pisał, a potem porównaliście, co kto zapisał? Czy opisywaliście każdą z ról po kolei czy jednocześnie? Czy była sytuacja, że np. jakieś dwa punkty wykluczały się nawzajem i co z tym zrobiono? Itp.

Zostaw swój komentarz

Twój komentarz*

Twoje imię*
Twoja strona*

This site uses Akismet to reduce spam. Learn how your comment data is processed.