Zagrożenia w Scrumie

Trudne pytanie.

“Jakie zagrożenia w działaniu Scruma powoduje praca w modelu asynchronicznym i jak się przed nimi bronić?”

Z tym pytaniem zmierzyli się doświadczeni w bojach Scrum Masterzy i Scrum Masterka.

Co sądzą o pracy zdalnej?
Jak wygląda praca, w której Twój partner śpi, kiedy u Ciebie jest południe a Ty potrzebujesz jego odpowiedzi natychmiast?

Przekonajmy się!

Damian Borowski

Kierując się wartościami moralnymi, dążę do rozwoju siebie, innych ludzi oraz społeczeństwa.

Damian to mój niemal osobisty mentor w drodze do zostania Scrum Masterem.

Znajdziesz mnie TUTAJ

Uważam, że model asynchroniczny może powodować zagrożenie dla Scruma w sytuacji, gdy w zespole nie ma dobrej komunikacji.
Można temu zaradzić przede wszystkim prowadząc wartościowe Daily, czyli codzienne 15-minutowe spotkanie synchronizacyjne.
Z moich doświadczeń wynika, że sprawdza się takie, które:

1. jest skoncentrowane na celu danego Sprintu,
2. ma różnorodne formaty, aby ciągle podtrzymywać ciekawość zespołu,
3. przede wszystkim służy Developerom. 

Świetnym narzędziem, które może pobudzać komunikację, a jednocześnie skupiać ludzi na celu, są sesje Refinementu, kiedy to zespół może dyskutować na temat konkretnych wyzwań. Wystarczy udostępnić ekran i zapytać: – jakie widzicie tu problemy? – jakie są korzyści dla produktu z faktu realizacji tego User Story? – gdzie widzicie ryzyka? A potem poprosić pierwszą osobę z zespołu, aby się wypowiedziała i by nominowała do tego samego kolejną.
Jedna taka rundka na start, a rozumienie User Story będzie o niebo lepsze 🙂

Często w zespołach zdarza się, że niektórzy jego członkowie pracują zbyt samodzielnie i to może powodować:

1. Brak dystrybucji wiedzy na temat produktu w zespole.
2. Brak rozwoju wszystkich członków zespołu.
3. Zwiększone ryzyko popełniania błędów przez samodzielnego “kowboja”.

Jak temu zaradzić?
Moim zdaniem warto rozważyć wprowadzenie WiP Limitów, czyli limitów zadań, które zespół robi w danej kolumnie swojego boarda (np. w kolumnie “In Progress” mogą znajdować się maksymalnie 3 “itemy”).
Gdy WiP Limit jest przekroczony, dana kolumna się podświetli i poinformuje zespół, żeby skoncentrował swoje działania gdzie indziej.
Często będzie to oznaczało, że zespół będzie pracował w parach, żeby praca ruszyła dalej.  A na samym końcu polecam serdecznie przeprowadzenie paru sesji eksperymentalnych z formatem warsztatu EventStorming, który służy do modelowania procesów software’owych, gdyż bardzo pobudza on współpracę.

Myślę, że jeśli choć połowa z proponowanych tu eksperymentów znalazłaby dobry grunt w zespole, praca asynchroniczna nie powinna stanowić problemu 🙂

Mariusz Chrapko

Autor Podcastu “Menedżer Plus”, oraz “Zwinnego Newslettera”

Znajdziesz mnie TUTAJ
A link do zapisu na newsletter Mariusza znajdziesz TUTAJ (Uwaga! Afiliacja!)

Zanim odpowiem na to pytanie, zacznę od tego, że nigdy nie byłem zwolennikiem rozwiązań, które miały wychylenie tylko w jedną stronę. Przeciwieństwa w naszym życiu zawsze się jakoś równoważą i dopiero z tego wynika coś dobrego.

Na przykład oszczędność jest czymś pomiędzy rozrzutnością, a skąpstwem.
Odwaga – między tchórzostwem, a lekkomyślnością.
Podobnie jest z pracą asynchroniczną. Nie uważam, żeby praca asynchroniczna była modelem, które w Scrumie powinniśmy za wszelką cenę unikać. No bo przecież ważny jest zespół, trzeba pielęgnować relacje, zaufania i tak dalej.

To wszystko prawda, jednak nie wszystkie aktywności w zespołach scrumowych wymagają synchroniczności. Pandemia bardzo dobrze nam to pokazała. Komunikacja synchroniczna to komunikacja, która zachodzi w czasie rzeczywistym, zdalnie lub twarzą w twarz.
Ma sporo zalet. Widzimy naszego rozmówcę, możemy odczytać jego mowę ciała, mimikę, gesty. Mamy natychmiastową odpowiedź, nie musimy czekać. Ułatwia nam szybsze porozumiewanie się, a do tego wszystkiego buduje i zacieśnia więzi między rozmówcami.
No, ale z drugiej strony może też nam utrudniać życie. No, bo te wszystkie spotkania, telefony, webinary, statusy… zabierają nam mnóstwo czasu, który moglibyśmy inaczej zagospodarować. Komunikacja asynchroniczna jest czymś zgoła przeciwnym. Dzięki niej możemy się skupić. Mamy czas na przemyślenie odpowiedzi. Nie ma też problemu, jeżeli pracujemy w różnych strefach czasowych. Ale na pewno nie jest dobra, jeżeli chcemy popracować nad budowaniem więzi w zespole. Człowiek jest zwierzęciem społecznym i, póki co, nic tego nie zmieni. Spotkania twarzą w twarz zawsze mają większą siłę sprawczą, jeżeli chodzi o tworzenie relacji w zespole – budowanie zaufania, wzmacnianie zaangażowania, samoorganizacji. Poza tym, w komunikacji twarzą w twarz, szybciej możemy zareagować na różnego rodzaju nieporozumienia, które na przykład w mailach, czy czatach zdarzają się bardzo często. Zanim sobie wszystko wyjaśnimy, to na ogół mija sporo czasu.

Komunikacja asynchroniczna nie jest też dobra, jeżeli musimy szybko zareagować. Sam wiele razy doświadczyłem takiej sytuacji, kiedy pracowałem z osobami tylko i wyłącznie w modelu asynchronicznym. Pali się, jest awaria, a ty musisz czekać, aż ktoś znajdzie czas, żeby odpisać, zareagować.  Dlatego dobrym rozwiązaniem jest właśnie hybryda. Ustalenie, co powinniśmy robić synchronicznie, a co nie.
Na przykład ja osobiście wolę, jeżeli retrospektywa zespołu odbywa się w modelu synchronicznym, mimo że dzisiaj wszystkie narzędzia elektroniczne umożliwiają nam robienie tego zdalnie, co zresztą jest powszechnie praktykowane. Dynamika pracy zespołowej, budowanie relacji i zaufania wymagają jednak synchroniczności.

Pytanie tylko, jak możemy to w naszym zespole zapewnić. I to jest warte zakontraktowania z zespołem.

Krzysztof Detlaf

W sumie to nawet nie wiem skąd ten gość się tutaj wziął 😉

Product Owner w CodeTwo
(to ta firma, w której samemu składasz sobie biurko z płyty OSB, bo zajmują się pierdołami i nagrywają dziwne filmiki zamiast pracować)

Znajdziesz mnie TUTAJ

Scrum, jako metodyka wytwarzania oprogramowania opiera się na pracy zespołu, który działa w sposób iteracyjny i inkrementalny.
Prowadzenie pracy w modelu asynchronicznym może wprowadzić szereg zagrożeń o różnych poziomach ryzyka dla naszego projektu. Poniżej przedstawiam kilka najważniejszych według mnie, wraz z krótkimi przykładowymi strategiami jak można sobie z nimi poradzić:

1. Brak synchronizacji między członkami zespołu – może to prowadzić do braku synchronizacji w wykonywanych zadaniach. Zwłaszcza gdy członkowie zespołu mogą pracować w różnych strefach czasowych. Może to skutkować tym, że pewne zadania zostaną wykonane w sposób nieprawidłowy, niezgodny z oczekiwaniami lub nie zostają ukończone.

Jak się przed tym bronić: należy zapewnić regularne spotkania zespołu, podczas których każdy członek będzie mógł przedstawić postęp swojej pracy.
Dobrym pomysłem jest także wprowadzenie narzędzi do monitorowania postępów pracy, takich jak tablice kanban, dzięki czemu każdy z członków będzie miał wgląd w postępy pracy innych członków zespołu.

2. Trudności w komunikacji – niestety w przypadku pracy asynchronicznej trudności w komunikacji między sobą są bardzo oczywistym i według mnie najbardziej powszechnym problemem. Może to prowadzić do sytuacji, w których ktoś wykonuje zadanie, którego już nie trzeba wykonywać lub nie wie, że ktoś inny już je zrobił, lub błędnie zrozumiał założenia.

Jak się przed tym bronić: należy wprowadzić wyraźne kanały komunikacji, takie jak narzędzia do przesyłania wiadomości, e-maile lub regularne wideokonferencje. Należy również określić wyraźnie, kto jest odpowiedzialny za jakie zadania, aby uniknąć sytuacji, w których kilka osób wykonuje to samo zadanie oraz w jasny i przejrzysty sposób przedstawić i zdefiniować wymagania.

3. Niejasne wymagania – w przypadku braku regularnej komunikacji między członkami zespołu, wymagania mogą stać się niejasne, co może prowadzić do nieporozumień w trakcie prac nad projektem.

Aby uniknąć tego zagrożenia, należy zapewnić regularne spotkania zespołu oraz umożliwić bieżącą wymianę informacji między członkami zespołu.
Rodzaj spotkań, ich częstotliwość zależy od konkretnych sytuacji, jednakże warto założyć, że coś mogło zostać niewyjaśnione i lepiej dopytać dwa razy (double check).  

Można by wymienić wiele innych zagrożeń oraz zaproponować kolejne pomysły i strategie dotyczące radzenia sobie z ryzykiem. Praca w trybie asynchronicznym wielokrotnie stanowiła dla mnie wyzwanie, szczególnie w przypadku współpracy z klientami lub członkami zespołu, z którymi dzieliłem nawet 10 godzin różnicy czasu.
Warto stale rozwijać swoje umiejętności, możliwości oraz pracować nad pomysłami, stosując nowe rozwiązania i dążąc do usprawnienia działań, które już są skuteczne.

Zawsze stawiam sobie pytanie: “Jak mogę działać jeszcze lepiej?”.

Marcin “Aks” Grochowina

Więcej Aksa, blog wytrzyma. 🤡

Co ja poradzę, że ten gość po prostu da się lubić. I jeszcze jest świetny w swoim fachu – tak mówią.

Znajdziesz mnie TUTAJ
Tak naprawdę znajdziesz Aksa jeszcze w 15 miejscach w internecie, ale daruję Ci całą listę linków.

Myśląc o pracy asynchronicznej często z niepokojem podchodzę do aspektu związanego z komunikacją. Zwłaszcza, gdy współpraca zespołu w stu procentach opiera się wyłącznie na asynchronicznej formie działania.

Scrum jest zestawem praktyk i procesów, których zadaniem jest wspieranie ludzi w ich interakcjach. Zarówno tych wewnątrz bezpośrednio współpracującego ze sobą zespołu, jak i z jego otoczeniem.
Członkowie zgranego zespołu, który rozumie reguły gry rozumieją, że komunikacja opiera się nie tylko na „nadawaniu” komunikatu. Ale również na odbieraniu i przetwarzaniu otrzymanych informacji. Bo to właśnie dzięki temu przetwarzaniu otrzymywanych informacji, możemy dokonać inspekcji – zweryfikować, czy miejsce w którym się znajdujemy jest tym, w którym chcieliśmy się znaleźć. A jeśli nie, to zaadaptować zmiany, które pozwolą nam skorygować kurs we właściwym kierunku.
Jeśli w naszej komunikacji zabraknie tego aspektu przetwarzania odbieranych informacji, to zaburzona zostanie przejrzystość. Bez której w zasadzie wszystkie pozostałe procesy tracą sens. Bo co nam po Daily, na którym nie jesteśmy w stanie stwierdzić czy ostatnie 24 godziny zbliżyły nas do osiągnięcia Celu Sprintu?
Co nam po Review, na którym nie do końca wiemy co dostarczamy lub – co gorsza – nie wiem jakiej jest to jakości?
Co nam po backlogu, jeśli brak nam pewności czy napewno wszyscy rozumiemy jego elementy w taki sam sposób? Czyli… robimy, żeby robić. Odprawiamy „ceremonie”, w oczekiwaniu na cuda. Albo praktykujemy, ale nie do końca rozumiemy po co.
Bierzemy udział w zbiorowym kulcie. Kulcie cargo.

Oczywiście powyższy scenariusz jest mocno przerysowany. (Czy aby napewno? ;)). I wcale nie musi wystąpić w każdym zespole pracującym w modelu asynchronicznym. A co zrobić, żeby zminimalizować ryzyko wystąpienia takich problemów?

Zacząć od zbudowania zaufania w zespole. Dbać o otwartość i odwagę w wyrażaniu swoich opinii, nawet jeśli są one przeciwstawne w stosunku do tych wyrażanych przez inne osoby. Budować poczucie tożsamości z zespołem poprzez realizację wspólnych celów, które są przed nami stawiane co Sprint. Bycie czujnym na jakość wykonywanych przez nas prac i reagować, gdy coś odbiega od naszych standardów. I dbać o koncentrację i skupienie na stawianych przed zespołem celach.

Z pewnością pomoże spójny system wartości. Na szczęście ten przychodzi w Scrumie od razu w pakiecie 😉 Warto zastanowić się czym dla nas te wartości są. Za pomocą jakich zachowań wcielamy je w życie. A jakimi działaniami im zaprzeczamy. Dlaczego warto to zrobić? Bo mając wspólną płaszczyznę porozumienia, łatwiej nam identyfikować odstępstwa, wyciągać wnioski i wcielać je w życie.
Budujemy przejrzystość. Która stwarza przestrzeń do inspekcji i adaptacji.

Grzegorz Marciniak

Twórca społeczności House of Talents + Agile/Scrum Community onsite

Najbliższe eventy -> TUTAJ

To on daje mi kopa do udzielania się i prowadzenia własnego kanału dotyczącego poszukiwań pracy przez Scrum Masterów.

Znajdziesz mnie TUTAJ

– Grzegorzu, powiedz proszę jakie zagrożenia w działaniu Scruma powoduje praca w modelu asynchronicznym i jak się przed nimi bronić?

– Daily Scrum.

– Dziękuję.

Marzena Zaziąbł

Tworzy “Zwinny warsztat”
Agile Coach 🎯 Facilitatorka ⏱ Mentorka 💡 Trenerka

Ciekawie opisuje pracę Scrum Masterki na swoim instagramie.

Znajdziesz mnie TUTAJ

Przez asynchroniczny model pracy rozumiem swobodę w zarządzaniu swoim czasem. Komunikacja między członkami zespołu odbywa się niezależnie od miejsca i czasu. Co za tym idzie nie ma obowiązku uczestniczenia w spotkaniach zespołowych.

Każde spotkanie Scrumowe ma swój cel, który wspiera empiryzm i jego trzy elementy: przejrzystość, inspekcję i adaptację. Jeżeli członkowie zespołu nie mają spotkań, to nie stosują Scruma.

A co się wydarzy, gdybyśmy chcieli osiągać cele spotkań Scrumowych w komunikacji asynchronicznej np. na czacie? 😀

Miałam okazję widzieć Daily Scrum’a „pisanego”. Zespół utworzył dedykowany kanał i o stałej porze wszyscy dzielili się postępami i problemami. Informacje na czacie szybko przybrał formę statusów. Powoli zniknęły dyskusje, nie było rozwiązywania problemów i finalnie nie było pytań. Członkowie zespołu zaczęli skupiać się na własnych zadaniach i nie szczególnie interesowali się pracą innych osób.

Podobnie z Planowaniem. Pracowałam z zespołem, który był rozproszony w 3 strefach czasowych (Bangalore, Kraków, Nowy Jork). Wspólne dyskusje w mailach przeciągały się w nieskończoność. Wyłoniła się osoba, która chciała pomóc w komunikacji między lokalizacjami. Definiowała Cel Sprintu i rozpisywała wstępnie zadania. Skutek był taki, że członkowie zespołu zaczęli pracować w samotności lub podgrupach. Skupiali się na celach indywidualnych, nie zespołowym. Niechętnie zbierali feedback podczas planowania swoich zadań. Zaangażowanie spadło. O samo-organizującym się zespole nie było mowy.

Ciekawym doświadczeniem było też Sprint Review w formie asynchronicznej. Zespół nagrywał filmik ze zmianami, który wysyłany był do kluczowych interesariuszy i klientów. Każdy miał możliwość zadania pytania, wysłania spostrzeżeń lub umówienia się na spotkanie z Product Ownerem. Proces zbierania feedbacku był czasochłonny, rozwleczony i uwarunkowany od priorytetów pracy każdej z osób. Zespół i klienci byli dla siebie „anonimowi”. Członkowie zespołu nie czuli prawdziwych potrzeb, nie wiedzieli jak odbierana jest ich praca. Nie czuli jej celu.

Jeszcze nie doświadczyłam „asynchronicznej” retrospektywy (uf uf).

Z moich powyższych przykładów widać, że według mnie głównym zagrożeniem dla działania Scruma, jest przeniesienie wydarzeń Scrumowych na komunikację asynchroniczną. Nie rób tego!

Takie postępowanie spowoduje nie tylko przedłużające się dyskusje, czy dłuższe dostarczanie zadań, ale przede wszystkim odizolowanie się i problem z zaangażowaniem.

Wbrew pozorom codzienne 15 minutowe spotkanie ma też aspekt społeczny. Widzimy siebie nawzajem, rozmawiamy i budujemy zaufanie. Jeżeli tego nie mamy i nie czujemy się bezpiecznie, to niechętnie będziemy prosić o pomoc, czy angażować się w aktywności zespołowe.

Pytanie do Ciebie.

A Ty jak odpowiesz na to pytanie?
Napisz w komentarzu!

0 0 votes
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x