Blog

W czasie szkoleń i warsztatów często po omówieniu jakiejś praktyki lub techniki pada sakramentalne pytanie: a jakie narzędzie pozwala mi to zrobić w formie elektronicznej? Takie narzędzia jak User Story Mapping czy Affinity Estimation sprawdzają się najlepiej, gdy możemy z elementami Backlogu Produktu w formie karteczek w łapkach stanąć przed ścianą lub tablicą i zacząć je układać, przeklejać, dyskutując przy tym. Tyle że nie da się tego zrobić z osobami, które siedzą w mieście odległym o setki kilometrów lub wręcz na innym kontynencie. Co wtedy? Pytanie bardzo zasadne, a odpowiedź prosta nie jest.

Bo przede wszystkim należy postawić sobie całkiem serio pytanie: czy praca w geograficznym rozproszeniu jest konieczna? Może da się tego uniknąć albo przynajmniej doprowadzić do spotykania się w jednej lokalizacji częściej niż raz na rok? Wtedy poszukiwanie narzędzi, które wspierają Zespoły rozproszone i pracę na odległość może okazać się niepotrzebne. Ot, popatrzmy na taki User Story Mapping: jak już wspólnie w jednym miejscu wytworzymy mapę, dalsze uaktualnienia możemy realizować zdalnie, wysyłając sobie po prostu zdjęcia po zmianach (przy założeniu, że nie są one fundamentalne).

Używajmy narzędzi świadomie

Czasami faktycznie się nie da spotkać w jednym miejscu. Problematyczne bywa zwłaszcza ściągnięcie gdzieś interesariuszy. A w przypadku, gdy sama wspólna praca będzie trwać krócej, niż dojechanie na spotkanie w jednym miejscu, wtedy rzeczywiście – trzeba wspomagać się narzędziami do kolaboracji.

Tu istotna uwaga, o czym niejednokrotnie już pisałem: narzędzia elektroniczne mają często duże ograniczenia albo umożliwiają zrobienie czegoś tylko w jeden sposób przewidziany przez twórców oprogramowania, bez łatwej możliwości dokonywania modyfikacji. Jira, Rally, Asana czy nawet lekkie i elastyczne Trello, mają duży potencjał wytwarzania dysfunkcji wszędzie tam, gdzie zaczynamy dopasowywać proces do narzędzia, lub gdzie rezygnujemy z jakiegoś działania, bo nie jest ono wspierane przez software.

Narzędzi jest wiele, ale…

Wróćmy do poszukiwania odpowiedzi na pytanie: jakie narzędzia wspierają dobrze praktyki, których używają Zespoły zwinne? Odpowiedź: nie ma takich narzędzi. Każde z nich wytworzone zostało do jakiegoś celu i z początku doskonale go realizowało: w kontekście konkretnej potrzeby, konkretnych użytkowników, konkretnego miejsca i czasu. Potem zachodzi proces „generalizowania i udoskonalania” funkcjonalności, a software staje się ogromnym wszystko mającym kombajnem. Od tego momentu mało kto jest w stanie łatwo, szybko i zgodnie z pierwotnym zamysłem coś w takim oprogramowaniu zrobić.

To daje pole do popisu wytwórcom dedykowanych rozwiązań, które służą wciąż jednemu, może maksymalnie dwóm celom i potrafią na związane z nimi potrzeby odpowiedzieć całkiem dobrze. Tak zrodziło się całkiem szerokie spektrum narzędzi do budowania wirtualnych tablic (bez ciężkiego workflowu pod spodem), do przeprowadzenia User Story Mappingu, do szacowania pracochłonności, do tworzenia projektów graficznych i prototypowania. Duzi gracze oczywiście starają się za tym nadążyć, też dodać te funkcjonalności w swoich rozwiązaniach, czyniąc je jeszcze bardziej złożonymi molochami.

„Individuals and interactions over processes and tools”

Natomiast narzędzia elektroniczne gubią bardzo istotne aspekty wielu praktyk, które mają wspierać, czyli bezpośrednią komunikację, możliwość obserwacji grupy ludzi oraz komunikację niewerbalną. Wartością praktyk takich jak User Story Mapping nie jest przecież to, że powstanie tablica pełna karteczek, ale że robią ją ludzie wspólnie, rozmawiając przy tym.

Przy czym bywa, że dyskusja toczy się w grupie, do której dołącza kolejna osoba zainteresowana tym, co usłyszała, przechodząc obok. Czy da się zrobić coś takiego online? Czy da się zauważyć, że kluczowy interesariusz podniósł w zdziwieniu brwi, albo architekt wymownie milczy i kręci głową? Czy moderator zorientuje się, że w dyskusji online bierze udział zaledwie garstka ludzi, a reszta już dawno odpadła od grupy?

Dlatego pamiętajmy zawsze, że może jednak warto wsiąść w samolot lub pociąg i spotkać się w jednym miejscu. Sumując koszty licencji na software, może wyjść nawet taniej, jeśli rozsądnie do tego podejdziemy.

Z życia trenera wzięte

A skoro już jesteśmy przy temacie dysfunkcji, jakie niewłaściwie dobrane narzędzie może spowodować w Zespołach, podzielę się opisem zdarzenia z jednego z prowadzonych przeze mnie warsztatów. Po to, by pokazać siłę rażenia narzędzi, które wtapiają nam w korę mózgową przekonania często zupełnie absurdalne.

Akt pierwszy dramatu: typowa dyskusja na temat tego, jakim narzędziem można zdalnie wesprzeć się w jednej z praktyk ułatwiających pracę z Backlogiem Produktu. Zapytany wprost, co nie podoba mi się kombajnach typu Jira lub Rally odpowiadam dość obszernie, wskazując na zaobserwowane przeze mnie słabości (przykładowe, bo jest ich – niestety – wiele). Nie próbuję nikogo przekonywać do swoich racji, bo też nie jest to nigdy moim celem; staram się raczej zaszczepić pewną ostrożność w zbytnim spoufalaniu się z konkretnym narzędziem, by nie ulec nieświadomie dyktatowi jego ograniczeń. Tylko tyle i aż tyle. Czasem ktoś się oburza, częściej twierdzi po prostu, że „wszystko da się zrobić, gdy dobrze zna się narzędzie”. Pełna zgoda – zawsze się da, istota tkwi w tym, jak to robić, a nie czy się da zrobić…

Drugi akt dramatu, dużo później: rozmawiamy o strukturze Backlogu Sprintu i o tym, co tam tak naprawdę się znajduje. I… mamy cię, drogi użytkowniku Jiry (w tym przypadku)! Słyszę o taskach i subtaskach, o historyjkach i epikach, o relacjach między nimi, o tym, że tylko takie rzeczy mogą być dodane do Backlogu, bo tak skonfigurowana jest firmowa Jira… Powiewa grozą.

Akt dramatu trzeci (bez antraktu, bo jest już późno i na przerwy czasu brak): pytam jak dodać do Backlogu Sprintu taki ot choćby spike? Jako task, czy jako historyjkę użytkownika? A actionable improvement z poprzedniej Retrospekcji Sprintu będzie taskiem, historyjką użytkownika, czy może epikiem? Będzie miał subtaski, czy niekoniecznie? Grzęźniemy dość szybko w dziwnej dyskusji, owiniętej mocno o nomenklaturę konkretnego narzędzia.

Mylenie pojęć ogranicza przejrzystość

Przy okazji gdzieś w tle pojawia się obserwowalne pomieszanie dwóch pojęć: zadania i wymagania. Rzeczy te wydają się synonimem dla wielu osób, które w Jirze mają jeden typ itemu – czyli wspomniany wcześniej task. Spotkanie osób pracujących nad czymś wspólnie, z których jedna używa na co dzień Jiry, druga Rally’ego a trzecia Trello, może stać się wyzwaniem, bo zanim ustalą, o czym właściwie rozmawiają (wymaganiach, zadaniach, czy jeszcze czymś innym) może minąć dłuższa chwila. O ile w ogóle zauważą, że mówią o kompletnie różnych rzeczach.

A tych pomyłek może być więcej. Bo czymże jest Sprint w Jirze? Czym jest Team? Czy Backlog to sposób filtrowania listy zgłoszeń, czy rzeczywisty, zupełnie osobny artefakt? Zachęcam do zrobienia eksperymentu w dużej organizacji i zadania prostego z pozoru pytania Zespołowi w czasie Planowania Sprintu: czy wasz Product Owner, kiedy dokonuje porządkowania Backlogu Produktu (czyli zmienia jego kolejność i zawartość), widzi dokładnie to samo, co można zobaczyć w trakcie Planowania? W dziewięciu przypadkach na dziesięć dostaję w takim przypadku odpowiedź „chyba tak”. Skąd ten brak pewności?

Oczywiście ten sam problem dotyczy każdego dużego narzędzia, które wyrastało z systemów do obsługi zgłoszeń i dopiero z czasem stało się czymś więcej. Nawet te produkty, które od początku tworzono po to, by wspierały pracę zwinną, potrafią zaskoczyć ograniczeniami. Przy czym ograniczenia te niekoniecznie są cechą produktu, równie często biorą się ze świadomego (ale złego) dysponowania uprawnieniami do robienia w systemach elektronicznych różnych rzeczy. I tak Zespoły „uszczęśliwiane” są często jednym generycznym workflowem, którego nie wolno im zmienić. Albo ograniczonymi, z góry zdefiniowanymi typami elementów w Backlogach, z narzuconymi z góry relacjami między tymi typami…

Czy narzędzia „wspierające zwinność” wytwarzane są zwinnie?

Czasami zadaję na szkoleniach pytanie, czy ktoś wie, jak te narzędzia są budowane – bo może trafię na kogoś, kto brał w tym udział. Chętnie bym dowiedział się lub zobaczył jak (i czy w ogóle) firmy te używają swojego produktu do celu, dla którego go wytworzyły. I czy ci, co oferują „wsparcie dla metod zwinnych” w swych produktach, rzeczywiście działają przy ich pomocy zwinnie. Nie twierdzę, że tak nie jest, ale zachowuję ostrożny sceptycyzm.

Z kronikarskiego obowiązku, przekory, ale przede wszystkim z głębokiego przekonania napiszę na koniec, że nawet niedoskonałe narzędzie będzie zbawieniem, jeśli alternatywą dla jego braku jest chaos. Jeśli nasz „Backlog” to wyciągane z losowych maili od interesariuszy strzępki informacji, wtedy jakakolwiek forma zebrania tego w dostępną dla każdego listę, określającą kolejność realizacji, będzie przełomowym usprawnieniem. Dlatego jak najbardziej zachęcam do korzystania z narzędzi tam, gdzie jest to rzeczywiście potrzebne, byle czynić to w sposób świadomy.