Battle for Agility

Dylemat autora narzędzia Agile

August 27th, 2011 Marcin Niebudek

Wiadomo nie od dziś, że zamieszany jestem w tworzenie narzędzia agile o nazwie tinyPM. I pewnie jako dostawca tego typu narzędzi nie powinienem pisać tego posta (tak mi coś dzwoni z tyłu głowy)…

Kontekst, albo szczypta histrorii

Kiedy podjęliśmy decyzję o napisaniu tinyPM’a kilka lat temu, częściowo świadomie, częściowo podświadomie, w każdym z projektów próbowaliśmy wdrażać jakieś zwinne praktyki. Zwykle jakaś część zespołu była rozproszona więc używaliśmy różnych narzędzi do wspomagania naszej komunikacji i udostępniania jak najlepszej informacji o stanie projektów.

Wtedy właśnie zaczęły nam doskwierać ograniczenia, jakie narzucały nam w taki bądź inny sposób narzędzia których używaliśmy (Excel, Wiki, SharePoint, itp.). Dlatego podjęliśmy decyzję o napisaniu własnego oprogramowania.

tinyPM był projektem prowadzonym po godzinach, wieczorami lub w weekend. Pamiętam, że zaczęliśmy od zarządzania informacją na wiki (nasz backlog i to co wokół niego). Po 3-4 iteracjach byliśmy gotowi do przeniesienia się do tinyPM’a. Wszystko co zawarte było z tinyPM’ie wynikało z naszych własnych doświadczeń. Pracując z nim od samego początku naprawialiśmy natychmiast wszystko co nam samym zaczęło przeszkadzać.

Kiedy tinyPM zbliżał się do jakieś wersji powiedzmy 0.69 (czyli taki niby już działający produkt, którego nikt jeszcze nie miał okazji zobaczyć) trafił się projekt, w którym miało być wdrożonych najwięcej praktyk agile. Nawet klient mocno parł na to aby tak zrobić.

Początkowo używaliśmy tam Trac’a, ale szybko przestał nam wystarczać. Zarówno nasz ówczesny pracodawca jak i klient zgodzili się na to aby użyć jako wsparcia naszego tinyPMa. To było świetne, bo na bieżąco do tinyPMa trafiały usprawnienia i funkcje, które bezpośrednio wynikały z codziennej praktyki naszego zespołu. Ich ślady można znaleźć w produkcie do dzisiaj.

Po kilku miesiącach zdecydowaliśmy się wydać wersję 1.0 i od tej pory zaczęliśmy zbierać informacje także przez UserVoice i e-mail. Nadal był to projekt, który prowadziliśmy równolegle z pracą na etacie programistów, ale założyliśmy już w tym czasie spółkę, aby móc formalnie sprzedawać licencje.

Projekty nad którymi pracowaliśmy na etacie stanowiły dla nas stałe źródło obserwacji i doświadczeń będących pożywką dla ulepszania tinyPM’a. Jednak praca na etacie i rozwój żyjącego już produktu były bardzo wyczerpujące. Nasze wysiłki skupiły się więc na uniezależnieniu się i zajęciu się na 100% naszym produktem.

Udało się. Praca nad tinyPM stała się naszym jedynym zajęciem, naszą pracą na etacie tyle, że na własny rachunek.

Tutaj docieramy do dylematu…

No właśnie. Jako dostawca narzędzia wspierającego zespoły stosujące praktyki agile, zajmowaliśmy się naszym narzędziem. Można by rzec, że od tego momentu mogliśmy się skupić na produkcie i na potrzebach naszych użytkowników. Jednak to co straciliśmy, to nasz udział w innych projektach. Zamieniliśmy go na intensywniejszą pracę nad tinyPM.

Najwięksi z producentów takich narzędzi prowadzą również (a może przede wszystkim) działalność konsultingową i szkoleniową. Ich armia coach’ów spędza miesiące w innych firmach wdrażających kulturę i praktyki agile. Inne firmy, takie jak nasza, opierają swoją działalność głównie o sprzedaż licencji.

Tylko czy to nie oznacza, że tracimy powoli kontakt z rzeczywistością?

Oczywiście używamy naszego własnego produktu do śledzenia pracy nad rozwojem tegoż. Pytanie czy to jest wystarczające? Czy producent tego typu narzędzia może opierać jego rozwój wyłącznie na komentarzach i potrzebach użytkowników zgłaszanych na forach takich jak nasze, czy też wiadomościach e-mail od użytkowników? Czy zwykła rozmowa, bez wniknięcia w kontekst projektów z jakimi borykają się użytkownicy to nie za mało? Pewne rzeczy trzeba poczuć na własnej skórze, żeby je zrozumieć.

To taki mini paradoks (przynajmniej tak go odczuwam), że tworząc narzędzie do zarządzania projektami, nie można dać się mu pochłonąć w 100%. Wbrew pozorom na jakość tego typu produktu duży wpływ ma właśnie fakt, czy tworzący go ludzie mogą część swojego czasu poświęcić zupełnie innym projektom. Projektom, które stanowią pożywkę dla rozwoju produktu oraz pole do doskonalenia samych procesów czy praktyk znajdując potem odzwierciedlenie w narzędziu.

Czas pokaże, czy projekt jaki my sobie znaleźliśmy (Conference Radar) wystarczy aby na nowo złapać dystans i zmienić nieco kontekst. A może właśnie dla “zdrowia” produktu należy rozszerzyć działalność i zacząć pracować z innymi zespołami?

Czy to ma sens? Jakiemu dostawcy zaufalibyście bardziej?

Kategorie: Narzędzia, Relacje z klientem, Różności