Sygnatariusze Manifestu Agile ponad narzędzia i procesy stawiają ludzi i interakcje między nimi; jest to jednym z filarów zwinnego podejścia do tworzenia produktów (przy czym w Manifeście z racji stworzenia go przez osoby pracujące w branży IT, mowa jest o oprogramowaniu). W wywodzącym się z ruchu Agile i potrzeby empiryzmu Scrumie nacisk kładziony jest na przejrzystość, bo tylko wtedy możliwe jest działanie pętli inspekcji-adaptacji.

Ponieważ przedstawienie stanu spraw w formie graficznej, a więc wizualizacja, ułatwia przyswajanie informacji, Zespoły Scrum obrastają tablicami i wykresami, obklejają się kolorowymi karteczkami i obwieszają flipchartami. Ilość takich radiatorów informacji zależy od dojrzałości i potrzeb Zespołu, jeden z nich wszakże pojawia się niemal zawsze: tablica scrumowa (a tak naprawdę jest to tablica kanbanowa).

Magia tablicy

Jednym z częściej powielanych mitów dotyczących Scruma, jest stwierdzenie, że wymaga on tablicy, na której Zespół umieszcza listę rzeczy, którymi się zajmuje. Ta lista rzeczy, bardziej poprawnie zwana Backlogiem Sprintu, obejmuje listę rzeczy do zrobienia w iteracji wraz z planem ich realizacji i tym samym osiągnięcia założonego Celu Sprintu.

W Backlogu Sprintu znaleźć można zatem te elementy Backlogu Produktu, nad którymi Zespół pracuje w Sprincie, ale najczęściej jest on o wiele obszerniejszy. Duże wymagania rozkładane są na mniejsze elementy, pojawiają się opisy czynności niezwiązane wprost z implementacją zmian w produkcie, ale potrzebne do osiągnięcia Celu Sprintu. Bywa, że elementy Backlogu Sprintu są echem ustaleń z Retrospekcji (a więc opisują jakąś akcję mającą usprawnić działanie Zespołu).

Magia tablicy, na której widać wszystko, jest tak silna, że członkowie korzystającego z niej Zespołu często traktują ją z przesadną atencją i zaczyna ona w zauważalny sposób wpływać na to, jak Zespół działa. Jeśli prowadzi to do usprawnień, to dobrze. Gorzej, jeśli Zespół zaczyna dostosowywać swój sposób działania do ograniczeń stosowanej przez siebie tablicy.

Zdarza się, że raz przyjęta forma tablicy zmienia się bardzo rzadko, a bywa, że Zespół w ogóle nie poddaje jej inspekcji i nie próbuje nawet dopasować do zmieniających się potrzeb. Ba, czasami wycofuje się z możliwych zmian, bo te wpłynęłyby na sposób działania tablicy scrumowej, a to przecież zbrodnia i gwałt na Scrumie, nieprawdaż? Cóż, to akurat kompletna bzdura.

Obalamy mity

Przede wszystkim należy jasno powiedzieć: Backlog Sprintu to nie lista zadań na obowiązkowej tablicy, ale lista rzeczy, które Zespół ma do zrobienia oraz plan ich realizacji, wraz z celem, który pozwoli to osiągnąć (Celem Sprintu). Te rzeczy będą istnieć niezależnie od tego, czy Zespół stworzy tablicę, aby je zwizualizować, czy nie. Innymi słowy, tablica nie jest czymś obowiązkowym w Scrumie, a jedynie narzędziem, które ma ułatwić pracę.

Skoro tablica ma wizualizować listę rzeczy do zrobienia i stan prac nad nimi, musi pokazywać informacje, które są zgodne ze stanem faktycznym. To oznacza, że zmiana w sposobie pracy Zespołu niemal zawsze musi wpłynąć na formę wizualizacji. Innymi słowy, tablica nie może być niezmienna, bo ma odzwierciedlać sposób pracy, zamiast go definiować.

Aby korzystanie z tablicy miało sens, jej utrzymanie musi być mniej kosztowne, niż radzenie sobie bez niej. Kierunek powinien być zasadniczo taki: na podstawie informacji na tablicy podejmujemy decyzje o wykonaniu czynności, które prowadzą do rezultatów odwzorowanych potem na tablicy. Jeśli tablica używana jest tylko do pokazania stanu spraw, ale nikt z niej nie korzysta przy podejmowaniu decyzji, wtedy stanowi jedynie kosztowny w utrzymaniu słup ogłoszeniowy.

Tablica-pułapka

Poza pojawianiem się w mitach o Scrumie jako niezbędny jego element, tablica – podobnie jak inne narzędzia używane przez Zespoły – może czasami bardziej szkodzić niż pomagać.

W dużych mocno sformalizowanych organizacjach bywa tak, że narzędzia, których używają Zespoły Scrum, narzucają tym Zespołom proces i sposób pracy. Tablica idealnie się do tego nadaje, jeśli Zespół nie będzie wystarczająco samodzielny i asertywny, by dążyć do dopasowywania narzędzia do siebie, zamiast ulegać jego ograniczeniom.

Pamiętajmy, że sposób pracy Zespołu zmienia się cały czas, więc nie istnieje realna możliwość, by zmiany w wizualizacji Backlogu Sprintu nie były wcześniej czy później konieczne. Jeśli okaże się, że to niemożliwe, niektóre Zespoły mogą zrezygnować z niezbędnych zmian w sposobie pracy, jeśli prowadzą one do rozbieżności z tym, co da się na tablicy pokazać. Będą więc działać nieefektywnie tylko dlatego, by móc nadal używać narzuconego narzędzia.

Może też się zdarzyć, że brak możliwości zwizualizowania rzeczywistego sposobu pracy nie powstrzyma Zespołu przed zmianami, czyniąc tablicę z definicji nieadekwatną i nieskuteczną jako radiator informacji (bo nie będzie już prezentować faktycznego planu działania i postępu prac). Rodzi to dwa zagrożenia:

  • Zespół, nie mając aktualnych danych o stanie spraw, może podejmować błędne decyzje;
  • ponadto przejrzystość tego, co się dzieje, dramatycznie spada dla osób spoza Zespołu (bo nie muszą one wiedzieć, w jaki sposób rzeczywistość różni się od tej przedstawionej na tablicy).

W ekstremalnym przypadku, gdy Zespół dojdzie do punktu, w którym rozbieżności między rzeczywistym sposobem pracy a jego wizualizacją będą ogromne, Developerzy przestają korzystać z tablicy jako narzędzia. Ogólny poziom przejrzystości spada, co wcześniej czy później spowoduje problemy w samym Zespole (utrudniając planowanie kolejnych dni w Sprincie), jak i organizacji (utrudniając planowanie kolejnych Sprintów i reagowanie na problemy).

Prawdziwy dramat rozpoczyna się, gdy narzędzia do wizualizacji zaczynają zastępować komunikację. Jeśli przedstawiciele biznesu, kierownictwo lub Product Ownerzy domagają się, by wizualizacja Backlogu Sprintu każdego Zespołu dawała im pełny obraz tego, co się dzieje w Sprincie, wtedy Developerzy mogą utracić kontrolę nad tym, jak działają użytkowane przez nich narzędzia. Nie będą w stanie ich zmieniać, bo sprawiłoby to kłopot użytkownikom tablicy spoza Zespołu, a więc możliwość adaptacji zostanie ograniczona lub w ogóle zaniknie. Co gorsza, usunięty w ten sposób może zostać jeden z filarów zwinności: bezpośrednia komunikacja, która ułatwia i skraca procesy decyzyjne i zmniejsza ryzyko przekłamań przy wymianie informacji.

Ostrożnie z narzędziami

Zdrowy rozsądek jest zawsze potrzebny i warto się do niego odwoływać, dlatego należy nieustannie upewniać się, czy używane przez nas narzędzia faktycznie nam pomagają, czy też narzucają sposób pracy. W tym drugim przypadku najszybciej, jak to możliwe, dokonujmy adaptacji, a jeśli ona jest niemożliwa, szukajmy innych narzędzi lub rozwiązań, najlepiej opartych o bezpośrednią komunikację.

Tablica i inne radiatory informacji są wyjątkowymi narzędziami: bez nich jest trudniej uzyskać lub podnosić przejrzystość procesu i stanu produktu. Szukając dobrych rozwiązań w tym obszarze, zawsze kierujmy się trzema prostymi zasadami:

  • muszą pozwalać na odzwierciedlenie rzeczywistości takiej, jaka ona jest,
  • muszą zmieniać się wraz z ewolucją procesów,
  • muszą być łatwe w utrzymaniu i modyfikacji przez Zespoły Scrum, a zwłaszcza Developerów w nich.

Tak samo, jak zmieniają się w czasie produkt i procesy, tak narzędzia muszą się zmieniać, aby nie stać się przeszkodą dla rozwoju. Nie jest przy tym możliwe przewidzenie i przygotowanie takich narzędzi, które raz zdefiniowane i uruchomione zawsze będą wystarczające.

Prawo własności

Czyje powinny być narzędzia używane przez Zespół Scrum i przez Developerów? Nie ma dobrej odpowiedzi na to pytanie, ponieważ mocno zależy ona od tego, co dokładnie robi Zespół i w jakiej organizacji funkcjonuje. Istnieje możliwość, że radiatory informacji, takie jak tablice lub różne miary i prezentujące je wykresy, zostaną Zespołowi narzucone bez możliwości odmowy ich stosowania; z tym często trzeba się godzić tak długo, jak realnie nie utrudnia to pracy Zespołom.

Natomiast w przypadku Backlogu Sprintu, który stanowi własność Developerów w Zespole Scrum, wizualizacja tego Backlogu powinna również należeć do Developerów. Ogólnie mówiąc, Zespół Scrum musi mieć możliwość takiego przedstawienia stanu spraw w Sprincie, jaki dla niego jest wygodny i jaki pomaga w utrzymywaniu działania pętli inspekcji-adaptacji na poziomie produktu i procesu. Jeśli takiego poczucia własności nie ma, wcześniej czy później pojawią się problemy w skutecznym wdrożeniu usprawnień zidentyfikowanych przez Zespół.

Warto o tym pamiętać i maksymalizować możliwości Zespołu do adaptacji (a więc i do reagowania na zmiany), również w zakresie stosowanych praktyk i narzędzi.

„Nic nie widać na waszej tablicy”

Jakże często Developerzy słyszą takie stwierdzenie od swoich Product Ownerów, interesariuszy, przełożonych i każdego, kto z jakiegokolwiek powodu ma wgląd w tablicę wizualizującą Backlog Sprintu. Pojawia się od razu dylemat: skoro Scrum wymaga przejrzystości, kto chce, powinien taką tablicę móc zobaczyć; z drugiej strony lepiej byłoby ją ukryć, by nie prowokować trudnych pytań, wątpliwości lub prób wpłynięcia na to, co i jak Zespół w Sprincie robi.

Może się stać tak, że aby „poprawić” wizualizację zgodnie z oczekiwaniem otoczenia, Zespół zacznie modyfikować praktyki i reguły, którymi się kieruje, choć sam takiej zmiany nie potrzebuje, albo wręcz spowoduje ona negatywne skutki. Już samo to jest złe, a do tego szybko okaże się, że ocena skutków wprowadzonych zmian nie będzie już należeć do Developerów, skoro nie byli jej inicjatorami. I w efekcie, choć im będzie być może trudniej pracować, otoczenie uzna, że dzięki zmianie „jest lepiej”.

Jeśli Zespół poczuje presję i zacznie dostosowywać używane narzędzia do cudzych potrzeb, pojawi się też ryzyko regresu w umiejętności samodzielnego organizowania swej pracy. Wraz z nimi wyparuje z Zespołu odpowiedzialność, a nierzadko efektem będzie utrata przez Developerów poczucia wpływu na to, jak pracują i co robią. Stąd już tylko krok od załamania motywacji.

Jeśli więc Developerzy słyszą narzekanie na wizualizację Backlogu Sprintu, jedynym rozsądnym rozwiązaniem jest wyjaśnienie, co na tablicy się znajduje i podziękowanie za sygnał, że być może jest ona nieczytelna. Wszelkie zmiany wprowadzane powinny być tylko wtedy, jeśli Developerzy uznają, że faktycznie przyniosą one Zespołowi jakiekolwiek korzyści i spowodują, że będzie on skuteczniej działał w Sprintach.

Należy też jasno wytłumaczyć dopytującym, co oznacza samoorganizacja w Scrumie: czy się to komuś podoba, czy nie, Zespół sam decyduje jak przekształcać problemy postawione przed nim przez interesariuszy w wartościowe, działające rozwiązania. Scrum Master może wesprzeć Zespół w radzeniu sobie z natrętami, ale przede wszystkim powinien nauczyć Developerów jak robić to samodzielnie i nie ulegać presji.

Oczywiście nic nie stoi na przeszkodzie, by w trakcie Retrospekcji Sprintu Zespół zastanowił się nad sugestiami osób spoza Zespołu co do sposobu pracy lub wizualizacji Backlogu Sprintu. Nie jest wykluczone, że uwagi są zasadne i ujawnią obszar, w którym można dokonać usprawnień. Może zatem się stać tak, że Zespół dokona zmian, jakie mu zasugerowano, ważne by były one przeprowadzone świadomie i aby Zespół precyzyjnie określił, co chce dzięki nim osiągnąć.

A jak wizualizacja Backlogu Sprintu wygląda u Was? Czy udaje wam się dostosowywać narzędzia do potrzeb w miarę, jak potrzeby te się zmieniają? A może udało wam się osiągnąć „stan idealny” i dalsze zmiany wydają się już niepotrzebne…?