Łukasz Michno
Maciej Wilmiński
Z pamiętnika młodych młynarzy
ver 0.5.
(…)
Czucie i wiara silniej mówi do mnie
Niż mędrca szkiełko i oko.
Adam Mickiewicz „Romantyczność”
WSTĘP (Autor: Maciej Wilmiński)
Scrum powoli staje się wszechobecny w działach wytwarzania oprogramowania, również w naszym kraju. Próbują wdrażać go zarówno największe firmy, jak i start-upy. Niewątpliwie nadchodzi dobry czas dla tejże metodyki, czego dowodem jest też spora liczba udanych wdrożeń i pozytywnych transformacji, dzięki którym firmy tworzą lepsze oprogramowanie i dostarczają je szybciej, a programiści nie tracą włosów, wzroku i nerwów od szesnastogodzinnego dnia pracy z weekendami włącznie. Ba, wydają się wręcz zaskakująco zadowoleni ze swojej pracy.
Moje obserwacje wskazują jednakże, że często wprowadzanie Scruma jest robione na szybko, bez specjalnego przemyślenia tematu, oczekiwanych celów czy niezbędnych zmian. Podobnie zresztą widzi sprawy Łukasz. Nieraz odnosimy wrażenie, że dzieje się to ze względu na swoistą modę, hałas wokół metodyk agile’owych czy jak to się teraz modnie mówi wśród młodych wykształconych hipsterów/lemingów z wielkich ośrodków – „hype”. Wszakże nie wypada w „tych czasach” pracować waterfallowo, bo przyznanie się do pracy w firmie, która to stosuje to wstyd i poważne faux pas.
Zatem – dzieje się. Bez dobrego zgłębienia tematu, bez zrozumienia istoty tej metodyki, jej założeń i zasad. Zespoły dwuosobowe ale i takie z dwudziestu pięcioma programistami na pokładzie. Scrum Master również w roli Product Ownera. Brak przeglądów i retrospektyw. Przeglądy bez Product Ownera. Planowanie wykonywane wyłącznie przez sam zespół na podstawie pokaźnego dokumentu z rozpisanymi co do piksela umiejscowieniami przycisków interfejsu. Z góry narzucone zarówno terminy, jak i nienegocjowalny zakres funkcjonalności, który ma być do tego czasu dostarczony. Zadania przydzielane poszczególnym członkom zespołu przez duet: Product Owner i Scrum Master. Zmieniające się co sprint składy zespołów. Zespół, którego członkowie pracują w czterech różnych salach. Nikła wiedza o zasadach metodyki nie tylko ze strony deweloperów i Product Ownerów, ale i Scrum Masterów! Tak, nie brak takich, którzy taką zaszczytną rolę pełnią, a nie wiedzą czym są cele sprintu i pielęgnacja backloga, a ich lekiem na przedłużające się prace jest… wydłużenie sprintu o kilka dodatkowych dni czy po prostu odwołanie przeglądu. Tak, to wszystko znamy nie tylko z opowiadań programistów, ale i widzieliśmy na własne oczy. Ba, nieraz dane nam było spotkać Scrum Masterów, którzy trafili na to stanowisko na zasadzie: „od jutra jesteś Scrum Masterem”, albo „od poniedziałku Scrum, zajmij się tym”. A potem zdziwienie, że to nie działa, że jest jeszcze gorzej niż było. Że nie jest to panaceum na ranę, a wręcz sól sypana na nią całymi garściami. Cóż – „łatwy do zrozumienia”, ale – „trudny do opanowania”. To nie są czcze słowa.
Stąd i coraz częstsze i coraz głośniejsze opinie wśród programistycznego cechu, że „ten Scrum to się nie sprawdza”, że jest to „zawracanie głowy/d*** i odciąganie od właściwej pracy”, „że to moda, która lada chwila minie”. Coraz więcej negatywnych emocji i wyrażanych ex cathedra opinii, że to bzdura, nierealna mrzonka. Cóż, jeśli chodzi o Scruma wyraźnie trwa okres „burzy i naporu”, ale jak śpiewali rodzimi klasycy A po nocy przychodzi dzień/A po burzy spokój. Sami jesteśmy ciekawi jak to się wszystko rozwinie, ciesząc się, że jesteśmy tu i teraz. Hic Sunt Leones! W tym ekscytującym momencie, kiedy wszystko nabiera rozpędu i przynosi zmianę. A jak mówi chińskie przysłowie, na które już mogliście się na naszej stronie natknąć: Gdy wieją wichry zmian, jedni budują mury, inni budują wiatraki. Zbudujmy więc nasz.
To, czego nam na początku naszej pracy w roli Scrum Masterów brakowało to wiedza, jak suche fakty ze Scrum Guide’a i informacje czerpane ze szkolenia przekuć na praktyczną, codzienną pracę w rzeczywistym świecie, z rzeczywistymi zespołami. Z odczuwalnymi naciskami, realnymi do szpiku kości budżetami i wszechobecną presją. Wiedzy wokoło nie brakuje, propagandy sukcesu również – oj ileż znaleźliśmy stron, gdzie więcej było zdjęć i informacji o danym adepcie Scruma, aniżeli jakichkolwiek praktycznych porad. Wśród masy książek, internetowej wszechnicy, brakowało miejsca (tak, tak, „nie umiecie szukać”, wiemy), gdzie można poczytać o realnych problemach, przykładach, innymi słowy sytuacjach „z życia wziętych”. A do tego zostało to podane w sposób uporządkowany, prezentując całościowy obraz sytuacji. Scrum Guide często bowiem deprymuje nachalnie wręcz marketingowym językiem, amerykańskie podejście do sukcesu i kariery bije z każdego zdania. Nie każdy jest w stanie się w tym odnaleźć. Co gorsza niektórzy też usilnie trzymają się każdego słowa ze Scrum Guide’a, chcąc być świętszym od papieża
Stąd dla mnie wielką pomocą była na pewno opisywana już u nas książka Henrika Kniberga. I stąd też swego czasu zakiełkowała myśl, żeby samemu stworzyć taki przewodnik, pokazać jak my działaliśmy, jakie popełnialiśmy błędy, a co nam się udało. I jak działamy bogatsi o te doświadczenia, czego się nauczyliśmy. Mamy doświadczenia z różnych zespołów i różnych projektów. A zarazem trochę inne spojrzenia na pewne sprawy, co w moim mniemaniu tylko i wyłącznie zwiększa atuty tegoż poradnika. Poradnika, który pisany jest przede wszystkim z myślą o Scrum Masterach, ale który myślę będzie niezwykle wartościową pozycją dla tych, którzy znaleźli się w Scrumie w zupełnie innej roli, czy po prostu z zaciekawieniem rozpoznają grunt.
Czytając go pamiętajcie, że naczelną zasadą Scruma jest inspekcja i adaptacja. Że to, co piszemy to tylko nasze spojrzenia i nasze wskazówki, które sprawdziły się w danej sytuacji, danym miejscu i danym czasie. Że nie są to gotowe przepisy i pomysły. Ale przecież to co chyba najbardziej fascynujące w Scrumie, to właśnie to, że zawsze jest miejsce na własne pomysły i inwencje. Że rolą Scrum Mastera nie jest pilnowanie, aby przypadkiem nie wykroczyć ani centymetr o objawione słowo z Przewodnika po Scrumie, a bazując na nim zbudować sukces własnej organizacji. To doprawdy fascynująca praca!
Nasz poradnik powstaje iteracyjnie, jak to w Scrumie bywa. Nie zdecydowaliśmy się publikować od razu całości, buńczucznie twierdząc, że już kilka pierwszych rozdziałów, a nawet tenże wstęp niosą dla Was odbiorców, konkretną wartość. Jesteśmy dopiero u progu, stąd miejmy nadzieję, że ten szumny wstęp nie zawiedzie oczekiwań i tempo naszych prac. Zaglądajcie do nas często.
CO NA POCZĄTEK
Sięgnijcie po Przewodnik po Scrumie i przeczytajcie go, a potem miejcie pod ręką, bo nieraz będziemy się do niego odwoływać i uwypuklać jego konkretne elementy. Koniecznie zapoznajcie się też z Manifestem Agile, zróbcie to jednak dokładnie. Większość skupia się wyłącznie na tym „co po lewej”, myśląc, że to po prawej można całkowicie ignorować. Więcej lektur początkowych nie trzeba. Zaczynajmy!
Ludzie, którzy brali udział przy tworzeniu fundamentów metodyk zwinnych, wierzyli, że dobre oprogramowanie może powstawać jedynie w oparciu o zaangażowane osoby, które potrafią pracować w zespole i przekładają to nad egoistyczne „Ja”. Tak, jak pisaliśmy w jednym z wpisów, Scrum to gra zespołowa i aby pracować dobrze w tej metodyce, należy poświęcić czas na odpowiednie wyedukowanie zespołu.Właśnie – zespołu. Ich sformowanie jest koniecznym i fundamentalnym krokiem dla reorganizacji pracy w kierunku Scruma. Szeroki opis wszystkich aspektów tego tematu to z pewnością materiał na sporą książkę. Poniżej postaram się przekazać najważniejsze z nich, przy okazji wplatając w to doświadczenia, które przyczyniły się do tego, że udało nam się tworzyć zespoły, które odnosiły sukces.
Zasadnicze i najważniejsze pytanie, na które musisz odpowiedzieć to: wokół czego chcesz organizować zespoły Scrumowe? Nad czym mają one pracować?
Optymalną sytuacją jest, gdy zespół może być odpowiedzialny za produkt. Jeden produkt. Może być to produkt, który sprzedaje firma, jeden z serwisów www czy też jakiś system. Dla zobrazowania, przyjmijmy, że masz zorganizować zespoły w firmie, która prowadzi kilka serwisów www – jeden o tematyce motoryzacyjnej, drugi o nieruchomościach, a trzeci to system aukcyjny. Punktem wyjścia będą zatem te trzy serwisy, to wokół nich będziesz skupiał np. trzy zespoły, które zajmą się na stałe rozwojem i utrzymaniem poszczególnych serwisów. Pamiętaj wszakże, że nie tylko jeden z nich może pracować nad jednym produktem, może być ich kilka. Analogicznie można podzielić je wedle konkretnych systemów – CRM, CMS, system wewnętrzny, system zewnętrzny etc.
Co zrobić jeśli macie jeden produkt/projekt? Warto postarać się stworzyć zespoły, które będą odpowiedzialne za jeden z jego komponentów. Na przykład: rozwój wyszukiwarki, system proponowania podobnych artykułów, panel klienta. W takim modelu działają zespoły między innymi w Spotify. Zachęcam do zapoznania się z materiałem H. Kniberga, który traktuje m.in. na ten temat. (patrz: Spotify Engineering Culture). Oczywiście, na początku podejście, gdzie podmiotem są komponenty może być trudne ze względu na architekturę systemu, która nie umożliwi wyodrębnienia w miarę możliwości niezależnych modułów, nad którymi można pracować niezależnie. Z czasem jednak refaktoryzacja systemu na taki model przyniesie same korzyści, choćby w postaci wdrożeń, które nie będą wpływały na resztę systemu. Ale gorący współcześnie temat przejścia z architektury monolitycznej na mikroserwisy, odłóżmy na razie na bok.
Drugim sposobem jest tradycyjne podejście projektowe. Tworzymy w miarę możliwości stałe zespoły, którym przydzielamy projekty. Te projekty się zmieniają wedle planu (roadmapy czy portfela projektów), a my możemy odpowiednio zaplanować rozwój zespołu – starając się zlecać mu projekty podobne tematycznie/technologicznie lub wręcz przeciwnie, zmieniając często dziedziny, w których porusza się zespół. O ile pierwsze podejście przyniesie nam poszerzenie wiedzy i umiejętności zespołu w danej dziedzinie, to drugie – rotacja i zróżnicowanie projektów – przyniosą brak rutyny i znużenia.
Zwróć uwagę też na to, że nie zawsze zespół zajmujący się produktem, od razu będzie mógł się zajmować jego konserwacją i naprawą, choćby ze względu na to, że system nie jest rozwijany od początku i ma już swoje naleciałości, a organizacja nie rozumie potrzeby zarządzania długiem technologicznym. Czasami do tego wszystkiego będzie potrzebny zespół utrzymaniowy, instytucja o tyle kontrowersyjna, co rozpowszechniona w wielu organizacjach. Jeżeli powołasz do życia taką jednostkę, to do niej będą spływały wszelkie tickety/zgłoszenia z wykrytymi błędami. Z jednej strony, może to przynieść pozytywne efekty, odciążając zespół, który rozwija projekt czy produkt, z drugiej strony utrzymanie kodu, którego się nie pisało może czasami zająć więcej czasu i bywa dość frustrujące. Właśnie czynnik czysto ludzki jest tu szczególnie istotny, prawdziwą sztuką jest tak zorganizować i prowadzić zespół utrzymaniowy, żeby pracownicy chcieli w nim funkcjonować. Żeby nie był tylko szkołą życia dla rozpoczynających pracę i przechowalnią dla najsłabszych deweloperów. W takich zespołach istnieje duża chęć przejścia do zespołu projektowego (co jest odbierane jako awans), rzadko ktoś z własnej woli chce w nim pracować na stałe.
Z moich obserwacji wynika, że lepiej unikać tworzenia takich zespołów, a błędy kierować do konkretnego zespołu, odpowiadającego za dany obszar systemu. Zespół któremu zdarzyło się popełnić błąd wkłada o wiele więcej zaangażowania w jego usunięcie, ponadto od razu widzi realne efekty i jakość swojej pracy, mając nowy wkład do samodoskonalenia swoich działań. Inną zaletą wyprowadzania błędów po stronie zespołów pracujących przy projekcie jest to, że one decydują o krytyczności błędu i wraz z Product Ownerem decydują o tym kiedy podjąć pracę nad jego usunięciem, na przykład zgodnie z popularną zasadą: krytyczne – robimy natychmiast, ważne – do backloga, mało istotne – pomijamy albo łudzimy się, że kiedyś je wykonamy wrzucając do specjalnie stworzonego “worka” na tego typu zadania.
Jak duże powinny być zespoły? Na początek trochę teorii. Pamiętaj, że masą krytyczną do wystartowania zespołu są trzy osoby, a maksymalną w granicach jedenastu. Jest to podyktowane możliwością i jakością komunikacji oraz dążeniem do zwinności. Większe zespoły potrzebują już koordynacji i zarządzania, coraz mniej w nich miejsca i szans na efektywną komunikację i samoorganizację. Wedle Scrum Guide „Samoorganizujące się zespoły samodzielnie decydują, w jaki sposób najlepiej wykonywać pracę, nie są przy tym w żaden sposób kierowane przez osoby spoza zespołu.” W zespole mniejszym niż trzyosobowy, ciężko z kolei o szerokie kompetencje, które umożliwią realizację zadań. Dodatkowo nie zaistnieje element samoorganizacji, po prostu dwie osoby podzielą się zadaniami, mniej lub bardziej po połowie. Nie jesteśmy w stanie uzyskać odpowiednich profitów z działań Scrumowych, które stanowić będą wyłącznie niepotrzebny narzut.
Zespół deweloperski powinien zachować zasadę „jedności miejsca i akcji”. Przez to sformułowanie mam na myśli sytuację, w której wszyscy siedzą w jednym pokoju i zajmują się jednym projektem. Dlaczego w jednym pokoju? Bo po prostu sprzyja to komunikacji i budowaniu zespołowości. Większość spraw/pytań można załatwić od ręki, bezpośrednio rozmawiając. Tworzy się też wspólnota celu. Dlaczego „jedność akcji” (przez nią rozumiem to, że każdy w zespole zajmuje się jednym i tym samym projektem)? Po pierwsze, aby uniknąć “zmiany kontekstu” (jeśli nie wiesz czym jest proponuję mini-grę ). Nic bardziej nie wybija z pracy niż nagłe przejście w zupełnie odrębny temat. Analiza, szukanie rozwiązania, wgryzanie się w kod, testowanie jest procesem skomplikowanym i wymaga czasu. Skakanie po zagadnieniach jest mało efektywne i tracimy przez to ogrom czasu.
Zespoły Scrumowe powinny być wskorśfunkcjonalne interdyscyplinarne (cross-functional). To znaczy, że powinny być w stanie zrealizować zadania z backloga niemalże w całości samodzielnie. Niemalże, bo czasami wymagane będzie wsparcie eksperta, o czym poniżej. Potrzebujemy zespołu, który zrealizuje całość.
Omówmy to na przykładzie zespołu stworzonego na potrzeby napisania aplikacji mobilnej. Czy wystarczą nam do tego sami programiści Java lub Objective-C? Co z tego, że będą w stanie oprogramować funkcjonalności skoro nie będzie do tego przemyślanego UX/frontendu? Czy dla Klienta kod wraz z dokumentacją będzie miał wartość? Uzupełnimy więc nasz zespół Frontend Developera, ale czy to wystarczy? Mając funkcjonalności i frontend potrzebujemy mieć potwierdzenie, że całość działa zgodnie z założeniami i tutaj niezbędny będzie tester, który napisze scenariusze testowe czy też testy automatyczne. Reasumując musimy stworzyć autonomiczny organizm, który wspierany rolą eksperta będzie w stanie realizować zlecane wymagania.
Scrum nie zabrania korzystania z pomocy z zewnątrz w momencie, kiedy nie jest to stała kompetencja potrzebna w zespole. Przykładowo, jeśli zespół składa się z programistów Python oraz testera, a potrzebuje środowiska do pracy (produkcyjne,deweloperskie etc.) może na czas zadania/projektu wciągnąć w swoje struktury specjalistę od systemów backendowych, który uruchomi i skonfiguruje potrzebny im do pracy serwer. Rolę eksperta może pełnić dowolna osoba, która jest wymagana do ukończenia jakiegoś zadania. Taką rolę może pełnić na przykład architekt oprogramowania, który będzie dbał, aby koncepcja rozwiązań we wszystkich zespołach była spójna. Ekspert nie jest stałym członkiem zespołu, opuszcza jego szeregi po wykonanym zadaniu.Należy pamiętać, że taka osoba często nie jest dedykowana dla jednego zespołu. Może pracować z kilkoma lub kilkunastoma. Na pewno jest dobrze poinformować go z wyprzedzeniem o tym, że będzie konieczność skorzystania z jego wiedzy i dostosować się do jego możliwości oraz dostępności.
Zespoły powinny być wyważone pod kątem umiejętności, ale i doświadczenia Nie powinno być sytuacji, gdy jeden z nich składa się z osób nowo przyjętych do organizacji pracowników, podczas gdy drugi będzie się składał z samych “senior deweloperów”. Doświadczenie powinno być po równo dystrybuowane w zespołach ponieważ bardzo wpływa na interdyscyplinarność zespołów.
Jak jednak fizycznie utworzyć Zespoły Scrumowe? Z moich obserwacji wynika, że najlepiej pozwolić dobrać się samodzielnie ludziom. Autorytarna decyzja może spowodować, że niektóre z cykli życia zespołu (o których w dalszej części) mogą się wydłużyć, szczególnie ścieranie i normalizowanie, ale o tym opowiemy w dalszych wpisach. Jak zmotywować jednostki żeby dobrały się w efektywne zespoły? Koncepcja jest bardzo prosta. Będziemy potrzebowali do tego tablicy zmazywalnej/flipcharta i karteczek “post it”. Każdy z deweloperów wypisuje na karteczce swoje imię, natomiast na tablicy w wierszach wpisujemy nazwy projektów/zespołów. Oczywiście zanim przystąpimy do działania, musimy je dokładnie omówić – jakie są wymagania, co dokładnie będzie tam realizowane.
Stawiane są dwa wymagania odnośnie dobierania się osób w zespoły:
- zespół ma być interdyscyplinarny, czyli posiadać wszystkich i wszystko co konieczne, aby na koniec sprintu oddać działający przyrost,
- zespoły mają być dobrane przed upływem określonego czasu.
Narzut czasu (swoją drogą przekonacie się jak w trakcie używania Scruma ważne są timeboxy) powoduje, że ludzie zaczynają się organizować zamiast siedzieć bezczynnie i spoglądać na siebie. Jest to pewnego rodzaju forma perswazji, ponieważ wszyscy wiedzą, że za chwilę przyjdzie ktoś, kto będzie oczekiwał rezultatu. W trakcie spotkania każdy z deweloperów podchodzi i przykleja kartkę ze swoim imieniem do danego zespołu. Czasami wymagało to kilku iteracji, aby wszyscy byli zgodni, ale efekt był zawsze ten sam. Ludzie dobrani nie tylko pod kątem umiejętności technicznych, ale także pod kątem podobnych poglądów i sposobów komunikowania się. Możemy też dopuścić stworzenie kilku alternatywnych propozycji i uszeregowanie ich przez deweloperów wedle ich własnych preferencji.
Drugim sposobem jest autorytarne dobranie ludzi w zespołu. Dotychczasowi przełożeni znają bardzo dobrze kompetencje swoich pracowników i najbliższe (a często i dalekosiężne plany firmy), co stawia ich w uprzywilejowanej sytuacji pod kątem skonstruowania odpowiednich zespołów. Posiadając szerszą perspektywę potrafią jeszcze skuteczniej dobrać odpowiednich ludzi do odpowiednich zadań. Dodatkowo ich doświadczenie w firmie jest zazwyczaj większe, dzięki czemu mogą dostrzegać zagrożenia, których w pierwszej wersji tworzenia zespołów nikt nie zobaczy.
W trakcie formowania zespołów warto także pamiętać o miękkich kompetencjach jego członków. Tutaj także należy dokładnie przeanalizować charaktery i sposoby pracy poszczególnych osób, bo będą miały one wpływ na pracę zespołu jako całości. Moim zdaniem te kompetencje także powinny być niejako przemieszane, aby, dla przykładu, nie stworzyć zespołu przysłowiowych gaduł, któremu będzie ciężko skupić się na wykonywanej pracy lub zespołu w którym nikt nie będzie się odzywał co spowoduje spore problemy w komunikacji.
Gdy mamy zebrany zespół, zacznie on funkcjonować w pewnym cyklu zauważonym przez Bruca Tuckmana.
Zakłada on 4 etapy w których zespół się tworzy i umacnia.
Źrodło: http://www.tbicommunications.com/
W tym momencie skupimy się jedynie na pierwszym elemencie, czyli formowaniu. Na tym etapie będzie jeszcze bardzo mało zespołowości, będzie to grupa osób, która będzie zachowywała się w bardzo indywidualny sposób. Jest on jednak niezmiernie ważny bo to w tym momencie każdy z jego członów będzie się poznawał, wymieniał informacjami, nie tylko pracowniczymi, nawiążą się znajomości, a być może nawet przyjaźnie. Z drugiej strony mogą się pojawić konflikty, które pozostawione same sobie mogą zrazić na wstępie ludzi do siebie. Nie martw się, są to normalne procesy, które występują w praktycznie każdym zespole. Pamiętaj, powołując zespół, miej w głowie, że powinien on być stały. Jest to wymagane nie tylko ze względu na miękkie kompetencję, ale także niezbędne do wypracowania stałego tempa i sposobu pracy. Rotacje w zespole powinny mieć miejsce jedynie w szczególnych przypadkach i dotyczyć jednostek. Bardzo ważne jest nadanie kierunku i celu do którego ma dążyć zespół, będzie to rzecz, która uwspólnia wysiłki i zacieśni współpracę, na ten moment jeszcze jednostek, które w przyszłości stworzą dobry zespół. Powinieneś także dążyć do tego, żeby członkowie zespołu wykształcili tak zwane “umiejętności typu T”, czyli posiadali wąską specjalizację, ale szerokie horyzonty, chęć i umiejętność wyjścia poza “swój ogródek”.
Tworzenie zespołów to bardzo wrażliwy temat, który ma olbrzymi wpływ na to jak będzie przebiegało wdrożenie zwinnego podejścia w organizacji. Jest on także bardzo złożony, gdyż wymaga uwzględnienia wielu zmiennych takich jak wiedza, doświadczenie, nastawienie do zmiany sposobu pracy, typu charakteru każdego z pracowników, możliwości organizacji oraz typu prowadzonych projektów. Pamiętaj, że budowa zespołów ma kluczowe znaczenie. Powinno to być bardzo dobrze przemyślene, przedyskutowane. Owszem, naczelną zasadą Scruma jest „inspekcja i adaptacja”. Ale częste zmiany składu zespołów przyniosą tylko problemy – z niezadowoleniem pracowników na czele. Wszak dażysz do zbudowania stabilnego i przewidywalnego środowiska pracy.
W tej części samouczka opowiemy o nowej i nietypowej roli jaką przynosi ze sobą Scrum, a jaką jest Scrum Master. Postaramy się przybliżyć czym na co dzień zajmuje się osoba na tym stanowisku, opiszemy jaki jest obszar jej obowiązków i dlaczego Przewodnik po Scrumie określa ją jako służebne przywództwo (servant leadership).Scrum Master – czyli osoba odpowiedzialna za prawidłowe rozumienie i przestrzeganie zasad Scrum. Spogląda niczym Światowid, którego cztery twarze są zwrócone w cztery kierunki świata. Pierwszy z kierunków to wsparcie zespołów deweloperskich, drugi – praca z Product Ownerem, trzeci – szerzenie i wspieranie organizacji w procesie transformacji, ostatni kierunek to własny, nieustanny rozwój.
Na początek skupmy się na tym pierwszym, czyli zespole deweloperskim. Po pierwsze spotkania, czyli Daily Scrum, planowanie sprintu, doskonalenie backloga, przegląd sprintu i retrospektywa. Scrum Master powinien zadbać nie tylko o to, aby się one odbywały, ale także były prawidłowo rozumiane, żeby przynosiły odpowiednią wartość. Przykład: zespół podczas Daily Scrum zamiast synchronizować swoje działania traktuje to spotkanie jako statusowe i zdaje “raport” dla Scrum Mastera. To typowy antywzorzec, na który powinien zareagować Scrum Master, nie czekając do retrospektywy. Za taki przykład może również sytuacja , kiedy zespół nie wykorzystuje zupełnie czasu dostępnego na doskonalenie backloga, zamiast tego przenosi tęą czynośćna planowanie sprintu i zamiast skupić się na zaplanowaniu sprintu estymuje, priorytetyzuje i rozbija zadania na mniejsze. Konsekwencją może być zbyt mała czasu na zaplanowanie pracy na najbliższy czas.
Nieodzowną częścią tej roli będzie ochrona zespołu przed wszelkimi problemami z zewnątrz. Za przykład może posłużyć nam taka sytuacja: w zespole jest osoba, która jako jedyna z liniowych pracowników ma dostęp do bazy danych, w efekcie czego notorycznie odciągana jest od zadań zespołowych, aby “ad hoc” na żądanie kierownictwa pobierać dane potrzebne do różnego rodzaju raportów. W efekcie jego praca jest nieprzewidywalna, ciężka do zaplanowania, co znacząco obniża prędkość zespołu. W tym wypadku Scrum Master powinien stanowczo rozprawić się z takim procederem – może być to trudne, aczkolwiek przy odpowiedniej argumentacji możliwe. Za drugi przykład może nam posłużyć “wrzucanie” tematów do zamkniętego backlogu sprintu. Może to robić Product Owner lub któryś z interesariuszy projektu bezpośrednio. Scrum Master powinien wytłumaczyć, że grozi to brakiem realizacji zaplanowanego zadania, a w konsekwencji brakiem osiągnięcia celu sprintu.
Generalnie, osoba pracująca jako Scrum Master z pewnością musi obserwować cały czas zespół i wyciągać wnioski co można usprawnić. Skupia się nie tylko na narzędziach, ale też zachowaniach i sposobie komunikacji w zespole. Wychwytuje antywzorce i na bieżąco rozwiązuje ewentualne konflikty, które dość często występują w pierwszych stadiach pracy w zespole.Pomaga zespołowi deweloperskiemu w zrozumieniu wartości biznesowej płynącej z backloga. Dba o to, aby deweloperzy mieli cały czas w głowie, że nie tworzą oprogramowania dla siebie i na swoje potrzeby, ale dla klientów. Dodatkowo może wspomagać architekta oprogramowania poprzez podrzucanie różnych usprawnień technicznych, pomysłów pracy z kodem (programowanie ekstremalne, test driven development, behavioral driven development, etc.).
Powinien także zachęcać zespół do wspierania Product Ownera przy pracy z backlogiem. Dzięki temu będzie on w stanie zrozumieć wizję produktu, a tym samym dobierać odpowiednie narzędzia , które pozwolą ją zrealizować. Żeby to zrobić trzeba dużo eksperymentować (pisaliśmy o tym w jednym z artykułów), ale robić to umiejętnie i wyciągać z tego wnioski. Dobrze przygotowane, udoskonalane środowisko pracy oraz narzędzia pracy wesprą wdrażanie historyjek użytkownikach umieszczonych w backlogu sprintu. Da to przewidywalność na której powinno zależeć wszystkim.
Dodatkowo Scrum Master musi mieć się cały czas na baczności, aby nie zostać zepchnięty przez zespół do roli sekretarki, osoby odpowiedzialnej za wystawianie spotkań i naganianie na nie ludzi, czy przenoszeniem zadań z wersji cyfrowej na analogową tablicę. Podobnym antywzorcem jest postrzeganie Scrum Mastera jako lidera zespołu, który jest odpowiedzialny za zarządzanie czasem pracy, urlopami czy okresowymi rozmowami z pracownikami.
Drugi kierunek – praca z Product Ownerem. Przede wszystkim Scrum Master powinien osobie zaczynającej prace w tej roli, dobrze wytłumaczyć jaki jest jej zakres obowiązków, jej uprawnienia, oczekiwania, jakie są możliwości w kontekście współpracy z zespołem i zarządzania backlogiem produktu. Należy dbać o to, aby Scrum był prawidłowo rozumiany także przez Product Ownera, który powinien rozumieć co daje ten proces i jak może go wykorzystać do ulepszenia efektów swojej pracy. Product Owner jest wspierany poprzez pomoc w tworzeniu backloga i w prawidłowym formułowaniu wymagań.
W pewnym sensie Scrum Master stanowi przeciwwagę dla tej roli, co nie znaczy, że jest po stronie zespołu deweloperskiego. Jest on neutralny. Zazwyczaj proporcję są takie, że Właściciel Produktu chcę więcej, szybciej, natomiast obowiązkiem Scrum Mastera będzie zrównoważenie tempa i ilości wykonywanych zadań do możliwości zespołu.
Trzecim kierunkiem świata, w którym spogląda Scrum Master jest organizacja. Zazwyczaj jest to tak zwana “praca u podstaw”, wsparcie zmiany, pokazywanie jakie korzyści dla firmy płyną z przejścia z klasycznego modelu prowadzenia projektów na zwinny. Nieodzowne jest przede wszystkim pokazanie nowego podziału ról (tłumaczenie dlaczego nie ma już menedżerów produktówych, czy projektowych) i zakresu kompetencji jakie niesie ze sobą Scrum. Są różne sposoby pracy na tym szczeblu. Moją ulubioną są warsztaty, które poprzez symulację pokazują “namacalne” profity. Do moich ulubionych form mogę zaliczyć Scrum Simulation with Lego czy Zamek dla milionera. W ten sposób można pokazać osobom niezwiązanym na co dzień z IT w jaki sposób pracują zespoły, co się zmieniło i dlaczego. Ciekawym wyzwaniem jest też wytłumaczenie nowej jednostki estymat – story pointów,, które na początku nic nikomu nie mówią bo nie odpowiadają wprost na pytanie “na kiedy to będzie?”. Często też wspieram się filmem stworzonym przez H. Kniberga Agile Product Ownership in a nutshell. 15 minut. materiału z świetną narracją.
Scrum Master jest w organizacji agentem zmiany, a zmiany niosą z sobą często poczucie dyskomfortu, konieczność wyjścia poza strefę komfortu, szczególnie u osób, które mają dłuższy staż pracy i widziały już niejedno, w związku z tym są gotowe kolejny raz “przeczekać złe czasy”. Podejście tej osoby do przeprowadzenia ludzi przez zmianę będzie kluczowe ponieważ to od niej w dużej mierze będzie zależał sukces transformacji.
Z powyższego opisu widzimy jak wiele zadań stoi przed Scrum Masterem i że jest to rola wymagająca specyficznych umiejętności i wiedzy. Najważniejsza zasada – Scrum Master – musi doskonale znać, a przede wszystkim czuć i rozumieć zasady Scruma, w przeciwnym razie od razu jesteśmy skazani na klęskę. Skąd wziąć taką osobę?
Pierwsza opcja – rekrutacja wewnętrzna. Musimy wytypować w firmie osobę z odpowiednim autorytetem i nastawieniem. Dlaczego autorytet ma znaczenie? Ponieważ Scrum Master nigdy nie może wyjść z pozycji siły i nakazać zrobienia czegoś. Organizacja powinna liczyć się z jego zdaniem ze względu na jego doświadczenie, osiągnięcia i wiedzę. Odpowiednie cechy charakteru, autorytet i właściwe nastawienie są tu kluczowe, wiedzę zawsze możemy wzbogacić korzystając ze szkoleń, których jest sporo na rynku. Plusem wybrania osoby zatrudnionej już w organizacji będzie świetna znajomość jej kultury organizacyjnej, sposobu jej funkcjonowania oraz tworzonych produktów. Haczyk tkwi w tym, że potrzebna jest osoba, która będzie odpowiednio nastawiona do zmiany, przekonana do Scruma.
Z doświadczenia mogę powiedzieć, że dość często wybierane są osoby z IT, ale nie jest to regułą. Polecam obejrzeć prelekcję Roberta C. Martina zatytułowaną The Land that Scrum Forgot, która pokazuje co w Scrumie jest ważne, czyli kod dobrej jakości, który pozwala pracować efektywnie, bez zaciągania długu technicznego. Często obieraną drogą jest przekwalifikowanie Project Managera przy czym trzeba pamiętać, że rola Scrum Mastera wymaga zupełnie innego podejścia i silnie rozwiniętych kompetencji miękkich.Osoba, która będzie pracować na tym stanowisku powinna być cierpliwa i zdeterminowana ponieważ każda zmiana niesie z sobą opór. Zdecydowanie warto wybrać kogoś, kto nie jest uwikłany w firmowe grupy wzajemnej adoracji. Scrum Master powinien być niezależny, niepodlegający wpływom i presji otoczenia.
Z drugiej strony zatrudnienie osoby z zewnątrz, która posiada doświadczenie jako Scrum Master pozwoli spojrzeć na świeżo na cały proces szeroko rozumianego wytwarzania oprogramowania i skorzystać ze zdobytej przez niego już wiedzy, natomiast minie jakiś czas zanim ta osoba zaznajomi się choćby z portfolio produktów oferowanych przez organizację.
Rekrutacja może rodzić także problemy natury technicznej, jest to dość stosunkowo nowe stanowisko i ciężko znaleźć rzeczywiście dobrego Scrum Mastera.
Niezależnie od tego czy jest to kandydat z wewnątrz czy z zewnętrznej rekrutacji jeśli ktoś może się pochwalić w CV cechami, o których pisaliśmy wyżej, dopytaj o sytuację w których były one ostatnio wykorzystywane. Z pewnością potwierdzeniem umiejętności będzie certyfikat Professional Scrum Master I lub Certified Scrum Master ale pamiętajmy, że sprawdza on jedynie teoretyczną wiedzę poprzez test w Internecie.
Okej, ale czym na co dzień zajmuje się Scrum Master?
- dba o to, że Scrum jest znany i prawidłowo rozumiany zarówno przez zespół scrumowy, jak i organizację,
- moderuje spotkania Scrumowe (dba o ich sens i merytoryczny przebieg, w razie konieczności aktywnie reaguje),
- pomaga w rozumieniu i osiąganiu celów sprintu,
- zapewnia odpowiedni balans pomiędzy potrzebami interesariuszy i Product Ownera, a możliwościami zespołu,
- usuwa przeszkody stojące na drodze do osiągnięcia celu sprintu,
- wspiera osiąganie transparentności na poziomie zarówno zespołu jak i organizacji,
- dąży do tworzenia efektywnych zespołów deweloperskich,
- pomaga zespołom deweloperskim w rozumieniu celów biznesowych,
- wspiera budowanie zespołów deweloperskich i dba o ich autonomię (wedle jednego z założeń Agile Manifesto – twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie),
- pomaga zespołom w wyciąganiu wniosków na podstawie ich doświadczeń,
- szkoli nowych pracowników z zakresu Agile/Scrum.
Jaki powinien być Scrum Master?
Odpowiedzialny. Nie, nie chodzi tu o odpowiedzialność za sukces rynkowy produktu ponieważ ma on o wiele więcej składowych. Chodzi o odpowiedzialność za stworzenie zespołu, który będzie bardzo wydajny i który wykorzysta wszystkie atuty jakie daje Scrum. Jego celem będzie także stworzenie odpowiedniego środowiska w którym zespół będzie mógł pracować niezakłócony problemami z zewnątrz. Bardzo dobrym odniesieniem będzie porównanie tej roli do trenera drużyny sportowej, bądź jak pisze M. Cohn w “Succeeding with Agile” (recenzja tej książki pojawiła się na naszych stronach) do dyrygenta orkiestry. Cechą wspólną tych profesji jest zgrywanie indywiduów w sprawnie działający zespół. Tak jak trener podczas meczu czy dyrygent w trakcie koncertu, tak Scrum Master w trakcie trwania sprintu jest odpowiedzialny za przekazywanie wskazówek dla zespołu, wsparcie w osiągnięciu celu sprintu. Kontynuując, tak jak trener, z jednej strony pracuje on indywidualnie z każdym z zawodników, stara się, aby każdy z nich osiągnął jak najwyższy poziom, z drugiej strony stara się bez przerwy ich zgrywać tak, aby stworzyli jak najlepszą drużynę.
Skromny. Kariery na tym stanowisku nie zrobi osoba, która stawia siebie w centrum. Egocentryczne nastawienie samca alfa jest tu raczej skazane na porażkę. “Ja” powinno być zepchnięte na drugi plan. Przede wszystkim liczy się pomoc rozumiana w różnoraki sposób. Pomoc w nabraniu pewności siebie zespołu i jego poszczególnych członków, w zrozumieniu wartości biznesowej wypływającej z wymagań , w komunikacji międzyzespołowej itp. Ta rola raczej kojarzy mi się z pozostawaniem w cieniu, byciem transparentnym, skrupulatnym obserwatorem z pozytywnym nastawieniem.
Potrafiący współpracować. Jednym z zadań Scrum Mastera jest stworzenie odpowiedniego środowiska pracy – można śmiało powiedzieć, że chodzi o poczucie bezpieczeństwa, gdzie z popełnionego błędu będzie wyciągnięta odpowiednia nauka, a nie pojawią się drwiny i wytykanie palcem. Powinien zachęcać swoją postawą do aktywnego włączania się w różne tematy wynikające z codziennej pracy, zachęcać do udziału w merytorycznej dyskusji popartej argumentami. Powinien rozróżniać przypadki w których komunikacja przebiega prawidłowo od tych, które staje się marnotrawstwem i prowadzi do zniechęcania podejmowania inicjatyw w przyszłości.
Wpływowy. Ta cecha jest niezbędną od samego początku i nie chodzi tu o wychodzenie z pozycji siły. Wręcz przeciwnie – trzeba podejść do sprawy “na miękko” – chcę coś zmienić, aby było lepiej, sprawniej. Chodzi o swojego rodzaju zarażanie ideą, budowanie zaangażowania i poczucia wspólnego celu. Jest to niezwykle przydatna cecha, która pomaga w byciu agentem zmiany, której często ludzie zwyczaje się boją.
Zaangażowany. Bez tego bardzo trudno być Scrum Masterem. Powinien aktywnie poszukiwać przeszkód w realizacji celu sprintu i pomóc zespołowi je wyeliminować, starać się działać prewencyjnie. Nie dawać się zbywać i dążyć do wyjaśnienia/rozwiązania każdej ze spraw, które napotkał bądź, które zostały mu powierzone przez zespół. Nie powinien się poddawać negatywnym opiniom i firmowym malkontentom. Zdecydowanie pomaga nastawienie “da się”, brak obaw w eksperymentowaniu i głowa otwarta na pomysły.
Posiadający wiedzę specjalistyczną, ale nie musi być to wiedza techniczna (o czym pisaliśmy w jednym z wpisów)., Scrum Master bezwzględnie powinien rozumieć jak przebiega proces produkcji kodu, ale równie dobrze może posiadać wiedzę domenową z danej branży, produktu lub umiejętności, które są przydatne w pracy z zespołem np. trener/coach.
W mojej opinii praca jako Scrum Master jest pracą na cały etat, mimo, że sam przewodnik po Scrumie nie zabrania osobie w tej rolipełnić równocześnie roli dewelopera. Organizacje czasami nie potrafią zrozumieć, że praca na tym stanowisku wymaga wysokiego skupienia. Dzieląc etaty 50/50 będziesz dobrym Scrum Masterem i dobrym deweloperem, ale nigdy nie będziesz tak dobry jakbyś mógł być oddając się tylko jednej z tej ról. Powszechnym procederem jest także zatrudnianie jednej osoby do kilku zespołów Scrumowych. Tutaj podobnie, traci się sporo czasu na przełączanie pomiędzy kontekstami i ciężko skupić się na jednym zespole od A do Z. Poza tym wymagana jest codzienna obserwacja zespołu ponieważ jest to podstawą pracy Scrum Mastera. Dzięki temu można diagnozować z jakimi problemami może się spotkać zespół i usuwać je zanim ktokolwiek się od nich odbije. Wynikiem obserwacji będzie także aktywna postawa jeśli chodzi o wprowadzanie zmian oraz ulepszeń w zespole. Sama ilość codziennych zadań sprawia, że tak naprawdę nie ma czasu się na nic innego, jeśli ktoś myśli inaczej sprowadzą tę rolę do organizatora i moderatora spotkań. Przysłowiowego woźnego.
Reasumując praca jako Scrum Master wymaga niewyczerpanych pokładów energii i otwartej głowy ponieważ problemy z którymi będzie sobie musiał radzić są często nietuzinkowe. Tak jak pisaliśmy wcześniej w artykule “Nietechniczny” Scrum Master, osoba na tym stanowisku powinna się charakteryzować rozwiniętym kompetencjami miękkimi, chęciami rozwijania ich, pozytywnym nastawieniem dla którego zlepek słów “nie da się” jest jedynie zaproszeniem do dyskusji oraz opisanymi powyżej cechami charakteru.
O wielkości zespołu pisaliśmy już we wcześniejszych wpisach, ale przypomnijmy, że w jego skład powinno wchodzić od 3 do 9 osób i, o czym nie traktuje już Przewodnik po Scrumie, powinien on być zlokalizowany w jednym pokoju. Jeśli pokój nie może być dedykowany jednemu zespołowi, możemy sobie z tym poradzić organizując Agile Area”, czyli miejsce gdzie zespół może się spotkać choćby na Daily Scrum i nie przeszkadzając innym osobom w pokoju odbyć spotkanie. Możemy także skorzystać z wolnostojących ścianek, aby fizycznie oddzielić zespoły od siebie.
Umiejscowienie zespołu w jednym miejscu wpływa pozytywnie na synchronizację informacji, dzielenie się wiedzą, ale i także na tempo realizowanych zadań. Nie ma oczekiwania, niepotrzebnego chodzenia i związanego z tym marnostrawstwa czasu. Dzięki temu, że wszyscy są razem, każdy osłuchuje się z tematami, choćby nawet jako pozornie nie uczestniczący w dyskusji. Informację krążą w powietrzu, wytwarzają się potrzebne kanały komunikacji. Sprawy zamiast mailowo zostają przekazywane bezpośrednio , dzięki czemu mamy szybszy obieg informacji, skróconą pętlę informacji zwrotnej. Dzięki temu buduje się zgrany, nie mający problemów z komunikacją zespół.
Dylematem pozostaje czy Product Owner powinien przebywać cały czas z zespołem. Z pewnością musi on mieć zapewnione miejsce w pokoju obok Zespołu Deweloperskiego i Scrum Mastera, ale czy powinien być tam na stałe? Jeżeli zdecydujemy się na taki ruch, z pewnością doświadczymy pewnych niedogodności. Obecność Product Ownera może powodować dyskomfort dla deweloperów i prowadzić do prób nie mówienia o problemach stojących przed nimi. Drugą z nich może być odczuwanie presji przez Zespół Deweloperski, który nie będzie miał przestrzeni do swobodnej wymiany zdań zwłaszcza jeżeli chodzi o technikalia co w dłuższej perspektywie jest bardzo szkodliwe. Każdy powinien mieć zapewnione miejsce dla siebie, a utrzymanie pewnego napięcia pomiędzy biznesem, a IT będzie zdrowe.Natomiast jeśli cały zespół zna się na tyle dobrze, że mógł by kraść razem przysłowiowe konie, to nie ma większych przeciwwskazań, aby jednak siedzieli razem. Jeśli tak nie jest, zdrowszym rozwiązaniem będzie ograniczone czasowo przebywanie Product Ownera. Spowoduje to równowagę i prawidłowo “rozłożone” siły pomiędzy światem biznesu, a IT.
Jednym z ważniejszych elementów wyposażenia pokoju zespołu Scrumowego są tablice suchościeralne, czyli popularne “whiteboardy” bądź pisalne ściany. W moich zespołach wykorzystywaliśmy je na różne sposoby. Czasami dekomponowaliśmy na nich zadania z backloga, rozpisywaliśmy zadania do analizy, projektowaliśmy architekturę, wpisywaliśmy, które historie użytkownika były realizowane w danym sprincie z informacją o prędkości zespołu na koniec sprintu, oznaczaliśmy zależności. Z drugiej strony, zawsze było na nich miejsce gdzie były ogólnodostępne informacje, np. kto w najbliższym sprincie ma zaplanowaną nieobecność co pozwalało na dobranie zakresu prac uwzględniającego stan osobowy. Tablice służyły także do retrospektyw, gdzie zapisywaliśmy informacje co chcemy utrzymać, co zmienić, co nam pomaga, a co przeszkadza w osiągnięciu celów sprintów. Informacji tych nie ścieraliśmy z prostego względu – była na nich historia zespołu, przez co przeszedł, jakie tematy wracały i jakich sposobów próbowaliśmy na znalezienie optymalnego tempa pracy. Często korzystali też z nich deweloperzy po to, aby rozpisać sobie algorytmy, wizualizować zależności w kodzie. Czasami o wiele łatwiej jest nam coś zrozumieć jak po prostu to zobaczymy.
Nieoceniony jest także projektor bądź po prostu telewizor. Dzięki nim można wspólnie pracować czy to nad backlogiem produktu czy analizować wybrany fragment kodu.
Pewnym tematem tabu jest usadowienie deweloperów w pokoju. Od kiedy pamiętam budziło ono wiele kontrowersji i było wyznacznikiem “statutu” w firmie. Młodzi przy wejściu z monitorami w stronę wchodzących, stare wygi w kątach pokoju. Moim zdaniem wdrażanie Scruma jest dobrą okazją żeby zrewidować takie podejście. Jedną z opcji jest wymuszenie ustawienia biurek i krzeseł w taki sposób, aby każdy miał zbliżone warunki pracy i nie miał możliwości ucieczki w ciemny kąt pokoju. Z drugiej strony możemy postawić na samoorganizację i pozostawić to w gwoli samych deweloperów, choć wydaje mi się, że mimo wszystko powinien to być nadzorowany proces ze względu na to, że pracownicy młodsi stażem mogą zostać stłamszeni przez “starą gwardię”. Usadowienie w pokoju powinno wpływać pozytywnie na transparentność, nie powinno być miejsca w którym można niepostrzeżenie przebumelować cały dzień i oglądać kod, tfu, znaczy Joe Monstera.
W miejscu pracy zespołu powinno być także wydzielone miejsce na “szybkie” spotkania. Wspomniana “Agile Area” przyda się nie tylko, gdy w pokoju mamy wiele zespołów. Mam na myśli sytuację, gdzie nie chcemy angażować w dyskusję całego zespołu i potrzebujemy kawałek przestrzeni gdzie będzie można porozmawiać. Idealnie nada się do tego nieduża kanapa i jakiś stolik w ustronnym miejscu.
Narzędzia
Jak wszyscy wiemy Scrum dąży do redukcji ilości spotkań i w zasadzie w samym frameworku przewidziane jest pięć (Planowanie Sprintu, Daily Scrum, Pielęgnacja Backloga, Planowanie Sprintu, Przegląd Sprintu oraz Retrospektywa Sprintu), ale czasami zespoły potrzebują przestrzeni, aby omówić jakąś kwestię w szerszym gronie, np. wydanie produktu, kwestie związane z architekturą, które będą wpływały na inne zespoły deweloperskie, itp. w związku z czym organizacja powinna zapewnić im efektywne miejsce spotkań.
Rozwiązaniem, które często wykorzystuję jest utrzymywanie analogowej wersji Backloga Sprintu, choć nie zawsze jest to konieczne bo zamiast niej możemy powiesić monitor, który będzie wyświetlał nam go z dedykowanej do tego aplikacji, o ile takową posiadamy, ale o tym później. Osobiście bardzo lubię analogową wersję backlogu sprintu, czyli taką na tablicy, z utworzonymi kolumnami ze statusami i przyklejonymi karteczkami samoprzylepnymi. Moim zdaniem taka tablica pełni także formę edukacyjną dla zespołów, które rozpoczynają swoje prace w Scrumie. Pozwala zobaczyć na własne oczy przepływ pracy, jak dokładnie w zespole jest zorganizowany proces wytwarzania oprogramowania, jak dokładnie działają metryki. Jeżeli decydujemy się na wersję elektroniczną, to musimy pamiętać żeby zapewnić interakcję z nią tak, aby podczas Daily Scrumów czy Pielęgnacji Backloga można było zapewnić nanoszenie odpowiednich poprawek. Może być to ekran dotykowy albo po prostu komputer z klawiaturą i myszą. Warto pamiętać, aby także w jakiś sposób oznaczyć, kto wykonuje dane wymaganie np. poprzez awatar. Oczywiście wersja elektroniczna, podobnie jak analogowa powinna być dostępna cały czas nie tylko dla zespołu, ale i wszystkich zainteresowanych, także poza firmą jeżeli taka jest potrzeba. Dzięki elektronicznej tablicy dostaniemy różne profity, m.in. dokładną historię co się działo z zadaniem np. w jakich statusach przebywało, czy wróciło z poprawek do deweloperki, czy było zrobione review, etc. Jeśli aplikacja z której korzystamy oferuje raporty będziemy mieli zapewne ich cały zestaw, a nie tylko jeden, jak to jest w przypadku tablicy analogowej.
Wybranie elektronicznej tablicy wiąże się także z wyborem aplikacji w której będziemy prowadzić projekt, do najpopularniejszych, płatnych rozwiązań możemy zaliczyć Jirę (kiedyś z pluginem Agile, dziś jest to integralna jej część), Microsoft Planner, Pivotal Tracker, Rally. Popularne jest także Trello, z którego możemy korzystać za darmo(choć posiada także 2 wersje płatne – Gold oraz Business Class), Asana czy Taiga.io. Rynek jest nasycony wieloma aplikacjami i z pewnością każdy dobierze coś dla siebie niezależnie od tego czy pracuje w Scrumie, Kanbanie czy innym zwinnym podejściu. Warto przemyśleć kto i w jaki sposób ma z niej korzystać. Czy zależy nam tylko na narzędziu dla Zespołu Scrumowego, które będzie skupiało się na zadaniach potrzebnych do zbudowania produktu, czy może chcemy coś bardziej rozbudowanego, gdzie będzie dostęp do portfolio projektów, wysublimowanych statystyk i raportów.
Reasumując, należy podkreślić, że miejsce pracy zdecydowanie wpływa nie tylko na morale zespołu, ale i także na tempo jego pracy. Odpowiednio dobrane narzędzia i prawidłowo przygotowane miejsce pracy będzie wspierało zespół w jego drodze do zwinności i dojrzałości. Pamiętajmy, że narzędzia są po to, aby wspierać i ułatwiać procesy, a nie tworzyć dodatkowy narzut. Ze starannością podejdźmy także do czasu jaki Product Owner spędza z zespołem. Z jednej strony nie powinien być z boku procesu tworzenia produktu, ale z drugiej nie może ciągle wisieć nad zespołem śrubując tempo i sugerując drogi na skróty. Kolejnym wyzwaniem może okazać się to, że środowisko w którym rozpoczynał pracę zespół może już nie być dla niego wsparciem za jakiś czas. Należy trzymać rękę na pulsie i … zwinnie reagować na wszelkie zmiany, nie tylko te związane bezpośrednio z produktem.