Tablica jako radiator informacji o backlogu sprintu

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 są echem ustaleń z retrospektywy (a więc opisują jakąś akcję mającą usprawnić działanie zespołu).

Magia tablicy, na której jest 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 w ogóle zespół 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ć: sprint backlog to nie lista zadań na obowiązkowej tablicy, ale lista rzeczy, które zespół ma do zrobienia. One będą istnieć 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, to 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: w oparciu o informację 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, to 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 zformalizowanych organizacjach bywa tak, że narzędzia, których używają zespoły developerskie dyktują sposób ich 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 sprint backlogu 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 tych zmian w sposobie pracy, które prowadzą do rozbieżności z tym, co da się na tablicy pokazać.

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 tego, co widać 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 sprint backlogu 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ą nam 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 developerskie.

A więc tak jak produkt i procesy się zmieniają, tak narzędzia muszą się zmieniać aby nie stać się przeszkodą dla rozwoju. Nie jest zatem 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ół developerski? 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 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 każdym przypadku tak, jak sprint backlog stanowi własność zespołu, tak i wizualizacja tego backlogu powinna do zespołu należeć. Zespół musi mieć możliwość takiego przedstawienia stanu spraw w sprincie jaki dla niego jest wygodny i który 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).

„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ą sprint backlog zespołu. Pojawia się od razu dylemat: skoro Scrum wymaga przejrzystości, każdy 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 wyprawia.

Jeśli w wyniku takich zapytań zespół poczuje presję i zacznie dostosowywać używane narzędzie do cudzych potrzeb, pojawa się ryzyko regresu w umiejętności samodzielnego organizowania swej pracy. Ustępując żądaniom w kwestii sposobu wizualizacji, można mimowolnie zaprosić osoby postronne do dyskusji o sposobie pracy. Ba, może się stać i tak, że aby „poprawić” wizualizację zespół zacznie modyfikować praktyki i reguły, którymi się kieruje, co samo w sobie nie byłoby złe gdyby nie fakt, że ocena skutków zmiany nie będzie należeć już tylko do developerów ale też inicjatorów zmian, którzy członkami zespołu nie są.

Jedynym rozsądnym rozwiązaniem jest wyjaśnienie, co na tablicy się znajduje i podziękowanie za podzielenie się wątpliwościami z zespołem. 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 Product Ownera w rozwiązania wartościowe dla biznesu. 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 retrospektywy zespół zastanowił się nad sugestiami osób spoza zespołu co do sposobu pracy lub wizualizacji sprint backlogu. 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 sprintowego 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…?