Scrum Master jako nawigator konfliktu

Praca z konfliktem stanowi jedno z większych wyzwań nie tylko dla początkujących, ale nawet doświadczonych Scrum Masterów i Agile Coachów, którzy  nie jedno w swej praktyce widzieli i doświadczyli. Podczas meetupów, konferencji, open space-ów organizowanych w środowiskach praktykujących zwinność, obserwuję nieustanne zainteresowanie i zapotrzebowanie na pozyskiwanie wiedzy i sposobów radzenia sobie z sytuacjami konfliktowymi. Również podczas sesji indywidualnych jednym z wiodących tematów coachingu jest potrzeba przyjęcia konstruktywnej postawy wobec pojawiających się konfliktów. Bo to łatwo powiedzieć, że konflikt ma swój twórczy potencjał. Jednak dużo trudniej jest wytrzymać towarzyszące mu emocje i dotrwać do momentu, w którym pojawiają się nowe rozwiązania zadowalające uczestniczące strony.
Konflikt jest integralna częścią pracy zespołowej, a także doświadczamy go na poziomie indywidualnym. Ileż to razy bowiem prowadzimy wewnętrzny dialog z wewnętrznym krytykiem, kiedy próbujemy podjąć jakąś znaczącą decyzję czy ryzykowne działanie. Dlatego naturalne jest, że wielu z nas chciałoby dostać gotowe przepisy na rozwiązanie typowych nieporozumień czy napięć. Niestety, ze względu na wielowymiarowość tego zjawiska nie jest możliwe stworzenie katalogu narzędzi, które zawsze zadziałają. Za każdym razem trzeba uwzględnić różnorodność uczestniczących w konflikcie osób oraz szerszy kontekst w jakim zaistniał konflikt. A także uwzględnić swój własny, często nie zamierzony, wkład w tworzeniu sytuacji konfliktowej.

Dlatego za celowe uważam uczenie się na podstawie konkretnych sytuacji, które umożliwiają poznanie i zrozumienie mechanizmów stojących za daną sytuacja konfliktową. Takie podejście jest dosyć praktyczne i umożliwia zastosowanie w ten sposób nabytej wiedzy i umiejętności w różnych sytuacjach.  Będę więc pisać o konflikcie w oparciu o sytuacje, w których pomagałam znaleźć rozwiązanie.

Na początek wybrałam sytuację konfliktu, którego pierwotne źródło pochodziło z odmiennej interpretacji danych. A konkretnie, interpretacji zapisu ze Scrum Guide’a dotyczącego obowiązków Product Ownera. Osią sporu była interpretacja zapisu dotyczącego odpowiedzialności Product Ownera za zarządzanie backlogiem.

Opis sytuacji z perspektywy Scrum Mastera

Zespół deweloperski zgłosił Scrum Masterowi zarzut wobec PO dotyczący zarządzania backlogiem. A konkretnie zespół uważał, że wykonuje pracę, która należy do Product Ownera. Oczekiwaniem zespołu było, aby Scrum Master interweniował w tej sprawie. Sytuacja ta miała miejsce na początku sprintu i według zespołu, nie rozwiązanie jej mogło skutkować dostarczeniem niskiej wartości biznesowej z powodu nieprawidłowego doboru zadań (zdaniem zespołu deweloperskego). Scrum Master ustalił fakty, które miały być punktem odniesienie do przekazania informacji zwrotnej PO. Jednocześnie ze względu na duże obciążenie pracą Scrum Mastera i Product Ownera, nie mogli oni spotkać się osobiście tego samego ani następnego dnia. W tej sytuacji SM podjął decyzję o przedyskutowaniu problemu za pośrednictwem maila i komunikatora. W korespondencji z PO, Scrum Master powoływał się na zapis ze Scrum Guide, co do zakresu odpowiedzialności za backlog. Należy też zwrócić uwagę, że w korespondencji pojawiło się sformułowanie „powinieneś…” w odniesieniu do Product Ownera. Tego typu sformułowanie jest jedną z barier komunikacyjnych, które mogą powodować uruchomienie mechanizmów obronnych osoby, do której są skierowane te słowa.

Przy najbliższym osobistym spotkaniu Scrum Mastera oraz Product Ownera, ten drugi, publicznie (w obecności osób z poza zespołu scrumowego) zarzucił Scrum Masterowi brak kompetencji oraz znajomości Scrum Guide. Oprócz tego, że sytuacja ta miała miejsce w obecności osób trzecich, to jednocześnie forma wypowiedzi była odebrana przez Scrum Mastera oraz osoby będące świadkami sytuacji, jako agresywna.

W efekcie ujawnił się spór kompetencyjny pomiędzy PO i SM, który zaistniał na płaszczyźnie interpersonalnej. Konsekwencją sytuacji było zaburzenie, wcześniej dobrej, relacji pomiędzy PO a SM. Napięcie, które pojawiło się w relacji, przeniosło się również na atmosferę w zespole, który zauważył zmianę zachowania obydwu osób.

Struktura konfliktu

Scrum Master podczas sesji z coachem analizował zaistniałą sytuację pod kątem swoich zachowań oraz towarzyszących emocji. Ponieważ komunikacja z PO była zaburzona, SM skoncentrował się na pracy z własnej perspektywy i poszukiwał obszaru, na który miał wpływ oraz sposobu zareagowania na agresywną formę zachowania Product Ownera. Podczas sesji coachingowej ujawniły się dwa poziomy konfliktu.

Jeden z nich to poziom konfliktu interpersonalnego, któremu towarzyszyły błędy komunikacyjne oraz nie stosowanie zasad konstruktywnego feedbacku z obydwu stron. Drugi poziom to poziom intrapersonalny, który dotyczył konfliktu wewnętrznego Scrum Mastera. Oczywiście ze względu na poufność nie będę wchodzić w szczegóły tego konfliktu, natomiast mogę powiedzieć co się wydarzyło w efekcie przepracowania wewnętrznego ograniczenia podczas sesji. Przede wszystkim pierwsza zauważalna zmiana nastąpiła na poziomie energii prezentowanej przez Scrum Mastera. Na początku sesji SM prezentował postawę emocjonalną, choć jednocześnie nieco wycofaną. Zgłaszał brak możliwości zareagowania na zaistniałą sytuację z obawy przed eskalacją konfliktu. Na koniec sesji poziom energii SM był wysoki, co można było zaobserwować w prezentowanej postawie, nastroju oraz gotowości do działania. W rezultacie Scrum Master zadbał o stworzenie okazji i warunków, aby dać informację zwrotną Product Ownerowi. Informacja zwrotna została przekazana przy użyciu konstrukcji, zwanej w komunikacji „Komunikatem JA”. Odnosi się on do opisu sytuacji oraz emocjom jakie temu towarzyszą po stronie osoby stosującej ten komunikat. Rozmowa z PO obniżyła poziom napięcia pomiędzy stronami i pozwoliła na oczyszczenie atmosfery. Jednak relacja nie powróciła do stanu z przed zaistnienia konfliktu.

Czego uczył konflikt?

Praca Scrum Mastera nie zakończyła się jednak, na tym. Kolejna sesja dotyczyła wzięcia odpowiedzialności za swoją część, która mogła być przyczyną zaistnienia sporu oraz wypracowanie planu działania na przyszłość. Po przeanalizowaniu faktów, Scrum Master zauważył swoje błędy oraz powody, które za tym stały.

Po pierwsze, pośredniczenie w komunikacji pomiędzy zespołem a Product Ownerem. Chociaż w ocenie SM zespół, jest zespołem dojrzałym, to jednak podczas planowania, nie zareagował na dobór zadań, tylko później oczekiwał interwencji Scrum Mastera. Tu pojawia się zagadnienie, które dla wielu Scrum Masterów może stanowić wyzwanie. Ponieważ jednym z zadań SM jest usuwanie przeszkód, wielu z nich bierze na siebie zbyt dużą odpowiedzialność i chętnie robią za zespół coś, co nie do końca do nich należy. Można zaryzykować stwierdzenie, że w opisywanym zespole scrumowym nie była realizowana co najmniej jedna z wartości scruma jaką jest otwartość. Skoro zespół nie rozmawia otwarcie z Product Ownerem tylko potrzebuje pośrednictwa SM, może to oznaczać potrzebę pracy z zespołem scrumowym jako całością.  I taki właśnie wniosek sformułował Scrum Master, jako działanie na przyszłość.  Jednocześnie sytuacja ta ujawniła potrzebę osobistej pracy SM, dotyczącej stawiania granic i prezentowania asertywnej postawy wobec zespołu. Brak asertywności w tej sytuacji rozpoczął serię następujących po sobie błędnych interwencji.

Drugim w kolejności aspektem, na który zwrócił uwagę Scrum Master, był sposób komunikacji jaki wybrał. Jeden z wniosków dotyczył formy komunikacji. Scrum Master zdecydował się na korespondencję ponieważ uległ presji oczekiwań zespołu – a właściwie własnej interpretacji tych oczekiwań –  i uznał, że sprawę należy załatwić natychmiast. Z perspektywy czasu odpowiadając na pytanie coacha, co mógłby zrobić inaczej, odpowiedział zdecydowanie, że przekazałby oczekiwania zespołu w trakcie osobistego spotkania z Product Ownerem. W trakcie rozmowy zwróciłby również uwagę na dobór komunikatów, tak, aby miały one charakter konstruktywnej informacji zwrotnej, odnosząc się do ustalonych faktów oraz wynikających z nich konsekwencji. Unikałby również sformułowań jakie zostały użyte w mailu sugerujące powinności PO.

Podsumowując sytuację z perspektywy Scrum Mastera, możemy zidentyfikować źródła powstałej sytuacji konfliktowej co pozwala na dobór narzędzi i umiejętności potrzebnych do zapobiegania bądź opanowania rozwoju konfliktu. Należy podkreślić, że przeprowadzamy analizę tylko i wyłącznie z perspektywy Scrum Mastera. Pierwotnych źródeł możemy więc upatrywać w:

  1. Różnicy interpretacji zapisów Scrum Guide
  2. Błędnej diagnozie zespołu jako zespołu dojrzałego
  3. Braku asertywności Scrum Mastera

W efekcie Scrum Master uległ presji (rzeczywistej lub wyimaginowanej) i wziął na siebie odpowiedzialność za komunikację pomiędzy zespołem a Product Ownerem. Kolejne następujące wydarzenia, jak np. wybór formy komunikacji, były już tylko skutkiem wcześniej popełnionych błędów.  Chociaż odbudowanie relacji pomiędzy Product Ownerem i Scrum Masterem może jeszcze trochę potrwać, to niewątpliwie z perspektywy Srum Mastera sytuacja ta stała się przyczynkiem do wglądu i inspiracją do własnego rozwoju oraz kierunku pracy z zespołem.

Dodatkowa refleksja dotyczyła różnic w interpretacji zapisów Scrum Guide. Wydawało by się, że zespoły pracujące w scrumie opierają się na tych samych zapisach i często (błędnie) zakładamy, że wszyscy, w taki sam sposób interpretujemy definicje i opisane reguły. W praktyce okazuje się, że dopiero zderzenie z konkretną sytuacją pokazuje różnice interpretacyjne. Zapewne można byłoby poświęcić x godzin na wspólną interpretację Scrum Guide’a, co oczywiście jest ani realistyczne, ani potrzebne. Co w takim razie w zamian? Może ustalenie trybu postępowania, na wypadek wystąpienia takich różnic. Bo niemalże jest pewne, że wcześniej czy później takie nastąpią.

„Oswoić i zrozumieć konflikt” – warsztaty umiejętności rozwiązywania konfliktów w Warszawie i Krakowie

Zapoznaj się z programem szkolenia