Blog

W czasie szkoleń i warsztatów często po omówieniu jakiejś praktyki lub procesu 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 w formie karteczek w łapkach stanąć przed ścianą lub tablicą i zacząć je układać i przeklejać, dyskutując. 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, 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 taką story mapę: jak już ją wspólnie w jednym miejscu wytworzymy, 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

Ale czasami faktycznie się nie da; problematyczne bywa zwłaszcza ściągnięcie gdzieś interesariuszy lub przedstawicieli biznesu. 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 ma 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 zatem 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 robienia story map, 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 interactinos over processes and tools”

Natomiast cały ruch związany z budowaniem narzędzi gubi po drodze bardzo istotny aspekt większości praktyk, które wymagają wspólnej pracy: to nie sama tablica i karteczki, lista, czy obrazek, albo model procesu, który da się wyświetlić zdalnie. To także, a być może przede wszystkim, możliwość rozmowy, poszeptania ze sobą w kątku, zauważenia podniesionej w zdziwieniu brwi kluczowego interesariusza, wymowne milczenie architekta kręcącego głową… Jak takie reakcje przenieść w świat wirtualny? Jak je zauważyć? Jak na nie wtedy reagować?

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, które go używają, 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ą koncepty 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 to da się zrobić”. Pełna zgoda – zawsze się da, istota tkwi w tym „jak” a nie „czy”…

Drugi akt dramatu: dużo później rozmawiamy o strukturze backlogu sprintu, co tam tak naprawdę się znajduje. I… mamy cię, drogi użytkowniku Jiry (w tym przypadku). Słyszę o „taskach” i „subtaskach”, o „usesach” i „epikach”, o relacji jednych do drugich, o tym że tylko takie rzeczy mogą być dodane do backlogu… Powiewa grozą.

Akt dramatu numer trzy (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 „ues”? A actionable improvement z poprzedniej retrospektywy to będzie „taskiem”, „usesem”, 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 baklog to sposób wyfiltrowania 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: czy wasz Product Owner jak dokonuje porządkowania backlogu produktu (czyli zmienia kolejność), widzi dokładnie to samo, co wy oglądacie teraz? W dziewięciu przypadkach na dziesięć dostaję 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 pisano 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 różnych rzeczy. I tak zespoły „uszczęśliwiane” są 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, to 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.