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 oprogramowania. 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 inspekcja-adaptacja.

Ponieważ przedstawienie w formie graficznej, a więc wizualizacja, ułatwia przyswajanie informacji, Zespoły Scrumowe 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” (cudzysłów nieprzypadkowy, bo 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 zidentyfikowane przez Zespół działania niezbędne do 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 małe zadania techniczne, pojawiają się czynności niezwiązane wprost z implementacją kodu, 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, co ważne jest tak silna, że członkowie korzystającego z niej Zespołu często traktują ją z przesadną atencją i zaczyna ona w mniej lub bardziej zauważalny sposób wpływać na to, jak Zespół działa. Rzadko zmienia się forma tej tablicy, a zdarza się, ż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ż?

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 osiagnąć (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 obowiązkiem 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 musi wpłynąć na formę wizualizacji. Innymi słowy, tablica nie jest niezmienna i 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 i czynności, które prowadzą do rezultatów odwzorowanych 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 oraz Developerzy w nich, narzucają 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 tego 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 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. 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 dla osób spoza Zespołu dramatycznie spada (bo nie muszą one wiedzieć, jak 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, management 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ć, 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 są 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 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, „biznesu”, 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…?