Scrum w zespołach rozproszonych

Punkty widzenia

Scrum w zespołach rozproszonych

Zwinne Organizacje | Podcast o agile | odc. 7

Praca zdalna w skali całych organizacji, to rozproszenie zespołów, których członkowie na co dzień pracowali blisko siebie. Włącz podcast i dowiedz się, jak implementować Scruma w takich warunkach.

Pandemia sprawiła, że wiele firm z dnia na dzień musiała przestawić się na pracę zdalną w zespołach rozproszonych. O tym, jak implementować metodyki zwinne w takich zespołach opowiada Paweł Tomkiel w siódmym odcinku podcastu.

Transkrypcja podcastu

Od marca 2020 zespoły rozproszone stały się bardziej popularne. Czy takie zespoły mają szanse być tak samo zwinne?

Słuchasz podcastu Deloitte „Zwinne organizacje”, gdzie wraz z naszymi gośćmi dzielimy się najlepszymi praktykami wdrażania metodyk zwinnych w pojedynczych zespołach, jak i całych organizacjach. Notatki do tego i innych odcinków znajdziesz na naszym blogu Zwinne organizacje

Cześć, nazywam się Paweł Tomkiel i jestem agile coachem w Deloitte Digital. Witam Cię w siódmym odcinku podcastu. Dzisiaj zajmiemy się tym, jak zespoły rozproszone mogą używać Scruma, czyli najpopularniejszego frameworku z metodyk zwinnych. Dla jasności, przez zespół rozproszony rozumiem taki, który nie siedzi razem w jednym pokoju. Najczęściej są to zespoły, które współpracują za pomocą technologii i różnych narzędzi cyfrowych.

 

Krótka powtórka ze Scruma

Scrum przewijał się już w poprzednich odcinkach naszych podcastów. W skrócie jest frameworkiem zwinnym, metodami pracy, które możemy wdrożyć w naszych zespołach i organizacji. Scrum skupia się przede wszystkim na dostarczaniu produktu przez to, że buduje krossfunkcjonalne, małe zespoły specjalne. Jeden zespół ma komplet umiejętności i kompetencji do rozwoju jakiegoś produktu, najczęściej oprogramowania. Scrum jest najbardziej rozpowszechnionym frameworkiem. Składa się z kilku rzeczy.

Przede wszystkim jest jasny podział ról tego, kto za co odpowiada. Rolą pierwszą są członkowie zespołu, którzy wykonują pracę, mają potrzebne kompetencje, żeby rozwinąć jakiś produkt. Ale kto decyduje o tym, jak praca ma być wykonana? Od tego jest druga rola, czyli Product Owner, który dba o to, żeby zespół znał priorytety, współpracował z klientami końcowymi, otrzymywał od nich informacje zwrotne, miał rozeznanie w tym, jak produkt powinien się rozwijać. Zadaniem Product Ownera jest maksymalizacja wartości, którą produkuje zespół. Jest też trzecia rola w Scrumie i jest to Scrum Master. Scrum Master jest służebnym przywódcą zespołu i dba o to, żeby usuwać wszystkie przeszkody z drogi zespołu. Scrum Master nie mówi zespołowi, jak praca ma być wykonywana, choć może, jeżeli zespół jeszcze buduje w sobie takie kompetencje.

Celem tych działań jest budowanie zaangażowania zespołu, aby brał odpowiedzialność za swoją pracę i za produkt.

W Scrumie są używane konkretne artefakty. Takim sztandarowym przykładem może być backlog produktu – czyli lista funkcjonalności, zmian w produkcie, które należy wprowadzić. Backlog pokazuje zespołowi priorytety, roadmapę, wizję produktu i jego rozwoju. Ale może się ciągle zmieniać – jest adaptowalny do warunków i do potrzeb klientów końcowych, które się zmieniają. W Scrumie są również eventy – konkretne spotkania o konkretnym celu.

„Zwinne organizacje”
Skuteczna pigułka wiedzy o agile

Nie przegap najnowszych treści

Scrum w zespołach rozproszonych

 

Scrum opiera się na współpracy zespołu. Zespół jest zintegrowany, wspólnie pracuje, wspólnie rozwiązuje zadania i trzyma się razem. Dlatego w zespołach rozproszonych głównym wyzwaniem jest zadbanie o zgranie zespołu. Jest tutaj mnóstwo praktyk, jak zdalnie zespół może się ze sobą integrować, wymienię tylko kilka, np. są organizacje, które codziennie na piętnaście, dwadzieścia minut parują losowo członków różnych zespołów w spotkania jeden na jeden, żeby firma się poznawała. Są konkretne przygotowane pytania, na które można odpowiedzieć. Jest to krótka integracja, odpowiednik spotkania przy kawie w kuchni.

Dobrą praktyką jest też trzymanie dedykowanego kanału czy czata do rozmowy pozasłużbowej. W ten sposób ludzie mogą się poznawać, dzielić informacjami, dzielić artykułami, nie mówię, że memami, chociaż to jest chyba najczęściej wykorzystywany kanał do tego. Celem jest bycie bliżej, nie tylko na gruncie służbowym. Odpowiednikiem spotkań w kuchni i wspólnego picia porannej kawy może być otwarty kanał lub spotkanie na wideokonferencji (Teamsach, Zoomie czy jakimś innym narzędziu). Sami to praktykowaliśmy w naszym zespole Deloitte, gdzie o konkretnych godzinach każdy mógł wejść do konkretnego spotkania i zobaczyć, kogo tam zastanie. Tam czekały już inne osoby z kawą, można było porozmawiać chwilę o pracy lub o czymś prywatnym przez chwilę, żeby się poczuć częścią zespołu. Nawiązując do tego, również w naszym zespole, co jakiś czas, wspólnie spędzamy piątkowe popołudnie, gdzie podsumowujemy to co się dzieje w całym zespole, ale jednocześnie możemy się wymienić tym, co się dzieje u każdego z nas i zobaczyć się, zanim nie wrócimy na dobre do biura.

Jak się skutecznie komunikować w Scrumie?

 

Przechodząc do kolejnego punktu, specyficznie w kontekście Scruma – eventy, które trzeba zmienić ze zwykłego spotkania w wideokonferencję. To nie jest trudne, tylko trzeba pamiętać o kilku rzeczach. Na spotkaniach scrumowych – jeżeli są w formie telekonferencji – bardzo ważne jest aktywne uczestnictwo wszystkich. Do uzyskania takiego zaangażowania z pewnością pomaga włączona kamera, która daje możliwość zobaczenia tej drugiej osoby. Niestety, nie możemy się oszukać, dużo komunikacji przepływa pozawerbalnie. Jeżeli nie widzimy się, to może dużo częściej dochodzić do konfliktów lub nieporozumień. Kamera, szczególnie w tak małym zespole, który musi być ze sobą zintegrowany, jest bardzo ważna na spotkaniach. W kwestii dobrych praktyk przeprowadzania spotkań odsyłam Cię również do piątego odcinka podcastu, gdzie rozmawialiśmy o tym, jak nie spędzać całego dnia na spotkaniach.

Ostatnia rzecz, o którą trzeba zadbać w Scrumie w zespołach rozproszonych, jest korzystanie z odpowiednich technologii. Zespoły rozproszone nie mogą wydajnie pracować, jeżeli nie mają do tego odpowiednich narzędzi. Zespół rozproszony działa przez Internet i musi mieć narzędzia odpowiednie do pracy przez Internet. To będą narzędzia do utrzymywania backlogu, do zarządzania zadaniami, do zarządzania sprintami, konkretne aplikacje, które pozwalają wykonywać to, co zespół mógłby normalnie zrobić stojąc przy białej tablicy razem w jednym pokoju.

Są też aplikacje, które imitują taką białą tablicę, na której wszyscy mogą wspólnie w jednym czasie tworzyć, pisać, rysować, przyklejać karteczki – to też jest możliwe w formie zdalnej.

Jeden pro-tip ode mnie.

Jeżeli miałbym Cię zostawić z jedną myślą po tym odcinku podcastu to byłaby to sugestia, że mail powinien służyć tylko do komunikacji zewnętrznej.

Jeżeli wykonujesz pracę operacyjną, przeprowadzasz dyskusje, komunikujesz się głównie przez maila w pracy w swoim zespole, to być może u Ciebie się to sprawdza. Ale nie spotkałem jeszcze zespołu, w którym mail sprawdzałby się lepiej niż wszystkie inne narzędzia. W poczcie e-mail jest rozwarstwienie wątków, brak kontroli nad odbiorcami (ona może się zmieniać praktycznie przy każdej odpowiedzi), brak kontroli wykonania poszczególnych zadań, które zostały komuś przypisane, brak sprawdzenia tego, co się wydarzyło dalej z konkretnym mailem. Powoduje to tylko narzut komunikacyjny. Korzystając z narzędzia np. do zarządzania zadaniami, do zarządzania decyzjami, możemy porządkować dyskusje per zadanie, per decyzja. Możemy też konkretnie przypisywać do konkretnego zadania, konkretnej decyzji, listę osób, które powinny o tym wiedzieć i to wykonać. Narzędzie bardzo to usprawnia. Mail nie powinien służyć do takiej komunikacji wewnętrznej.

Jestem świadom, że nie wyczerpuję tematu Scruma w zespołach rozproszonych, więc będę wdzięczny, jeżeli się do mnie odezwiecie, prześlecie swoje pytania, czy podzielicie obserwacjami z pracy w Scrumie w zespołach rozproszonych, i spróbujemy to poruszyć też w kolejnych odcinkach. Tymczasem bardzo dziękuję Ci za wysłuchanie, odsyłam Cię do trzech poprzednich odcinków, do odcinka 2, gdzie mówiliśmy o tym, że Scrum Master to nie Project Manager, do odcinka 3, gdzie powiedzieliśmy sobie, że Product Owner to też nie jest Project Manager i do odcinka 5, w którym opowiadałem jak nie spędzać całego dnia na spotkaniach.

Jeżeli ta treść Ci się podobała, to będziemy wdzięczni, jeżeli podzielisz się nią w swoich kanałach społecznościowych, zapraszam Cię również na naszego bloga, Zwinne organizacje na stronie Deloitte.com. Dziękuję Ci za wysłuchanie i do usłyszenia w kolejnym odcinku! 

Subskrybuj podcast o agile "Zwinne organizacje"

Otrzymuj powiadomienia o nowych odcinkach:
iTunes   Android   RSS   eMail   Spotify

Potrzebujesz wsparcia w swojej organizacji? Chętnie pomożemy!

Widzimy, że produkty cyfrowe można tworzyć o wiele szybciej i taniej, jeśli ludzie będą zorganizowani wokół produktów, a nie wokół wydzielonych funkcji. Wymaga to dużej zmiany, w której pomagamy naszym Klientom. Zachęcamy do kontaktu.

Czy ta strona była pomocna?