90 Sprintów dla Rynków Kapitałowych – część 1

Stosowanie procesów Agile w bankach inwestycyjnych jest nie tylko możliwe, ale naprawdę bardzo potrzebne. Ponieważ w tej branży nieustannie zmieniają się potrzeby biznesowe i wymogi prawne, klasyczne podejście kaskadowe często jest nieodpowiednie. Mój zespół w GFT zajmuje się podstawowymi systemami dla rynków kapitałowych. W tej krótkiej serii artykułów podzielę się swoimi doświadczeniami i opiniami, a także omówię kilka popularnych mitów na temat Agile.

Mit 1: „Agile jest dla startupów”

Niedawno rozpoczęliśmy Sprint 90. Z doświadczeń mojego zespołu jasno wynika, że podejście Agile jest skuteczne w przypadku projektu związanego z konserwacją i przepisaniem oprogramowania w banku inwestycyjnym.

Agile przekłada się na mniejsze koszty. Umożliwia wypróbowanie wielu koncepcji i porzucanie ich szybko (Fail Fast) – oraz tanio – na drodze od wymagań początkowych do rzeczywistych potrzeb biznesowych. Zauważyliśmy też, że po krótkim wprowadzeniu, osoby zarządzające produktem po stronie klienta zwykle chętnie uczestniczą w procesie Agile — chcą korzystać z możliwości, które on daje.

Mit 2: „Aby skutecznie stosować podejście Agile, trzeba pracować w tym samym miejscu, co klient”

Mój zespół pracuje w Europie dla klienta ze Stanów Zjednoczonych. Z powodu różnicy czasu zespół i użytkownicy biznesowi mają tylko trzy nakładające się godziny pracy. Tyle nam w zupełności wystarcza. Ponadto zarówno interesariusze ze strony klienta, jak i programiści są rozproszeni w wielu miejscach. W takiej sytuacji trzeba dobrze przemyśleć sprawy związane z komunikacją i optymalnie wykorzystywać ograniczony czas. Gdy mamy tylko trzy godziny na kontakty z klientem (w rzeczywistości mniej, bo rano w banku inwestycyjnym dużo się dzieje), musimy starannie zaplanować komunikację. Sztywny harmonogram spotkań (stan projektu, uzupełnianie informacji itd.) trzeba zastąpić narzędziami takimi, jak tablica zadań online, issue tracker i inne, które powinny być dostępne 24/7. Kiedyś dostawałem każdego ranka 50 nowych wiadomości e-mail. Ich liczba spadła do pięciu i okazuje się, że tyle wystarcza.

Mit 3: „Spotkania stand-up są łatwe”

Nie są. Łatwo jest przeprowadzać je mechanicznie. Ćwiczyliśmy to tygodniami, starając skupić się na zobowiązaniach, osiągnięciach, celach i planach.

Stwierdzenie takie jak: „Pracowałem nad nowym formularzem, dzisiaj będę dalej to robić” niewiele wnosi. Te trzy pytania powinny tak naprawdę brzmieć następująco:

• Co wykonałem, pomagając mojemu zespołowi osiągnąć cel sprintu?
• Co planuję wykonać, aby pomóc mojemu zespołowi osiągnąć cel sprintu?
• Czy coś przeszkadza mi w realizacji planów?

Stand-up to nie przedstawienie stanu prac. Opisz swoje cele, a nie to czym zajmowałeś się cały dzień. Na przykład: „Wybrałem zadanie stworzenia nowego formularza i opracowałem podstawowy układ. Planuję mieć działającą wersję za dwa dni” — to brzmi lepiej.

Aby umieć planować sprint lub wersję, musisz najpierw nauczyć się planować swoją pracę kilka dni naprzód! Jeśli wiesz, że musisz codziennie poświęcić 50% czasu na zarządzanie, po prostu zaplanuj mniej programowania. „Nie udało mi się nic zrobić. Mimo to planuję wykonać zadanie na piątek” — to jest dobra, uczciwa informacja. Spróbuj oszacować przeciętne nieplanowane zakłócenia — i uwzględnij je w swoich planach!

Przeczytaj ciekawe omówienie tego zagadnienia w artykule Oscara Centeno z GFT Costa Rica.

Mit 4: „Najważniejszym spotkaniem Scrumu jest stand-up”

Dla nas najważniejszym spotkaniem Scrumu jest retrospektywa sprintu. Ta niedoceniania ceremonia jest często ignorowana lub przeprowadzana razem z przeglądem sprintu. Te dwa spotkania mają zupełnie różne cele i uczestników. W naszym zespole dobrze sprawdza się połączenie przeglądu sprintu z planowaniem sprintu. Na obu tych spotkaniach odpowiadamy na pytania „Co?” i „Kiedy?”.

Retrospektywę sprintu przeprowadzamy dzień po przeglądzie sprintu bez udziału interesariuszy biznesowych. Odkryliśmy, że najskuteczniejsza jest następująca struktura: najpierw przegląd waste logu, a następnie pogrupowanie punktów w kolumnach „Start Doing”, „Stop Doing i „Continue Doing”. Ważne jest zanotowanie wszystkiego podczas retrospektywy, a następnie przejrzenie notatek podczas następnej sesji. Członkowie zespołu powinni mówić otwarcie i uczciwie oraz dyskutować problemach traktując się z szacunkiem. Należy skupić się na rozwiązywaniu problemów, a nie na obwinianiu kogokolwiek.

Większość wniosków, które przedstawiam w tym artykule, była omawiana podczas spotkań retrospektywnych.

Mit 5: „Nie ma czegoś takiego, jak samoorganizujący się zespół”

Samoorganizacja nie oznacza tego, że przywództwo jest niepotrzebne. Lider, który pomaga zespołowi zorganizować się, jest oczywiście częścią zespołu. Samoorganizacja oznacza, że zespół:

• zarządza swoją pracą i wybiera sobie zadania do wykonania zamiast czekać na ich przydzielenie,
• jako grupa podejmuje decyzje i bierze odpowiedzialność za oszacowania i zobowiązania,
• w otwarty sposób komunikuje się z interesariuszami w celu wyjaśnienia wszelkich wątpliwości dotyczących wymagań.

Za żadne z powyższych nie odpowiada kierownik, Scrum Master ani nikt inny z osobna. Aby osiągnąć te cele, potrzebne jest zaufanie, szacunek, poczucie sensu i oczywiście kompetencje. Zły wpływ na morale i zaangażowanie zespołu może mieć zewnętrzny menedżer przypisujący poszczególne zadania. Agile promuje kierowanie jako pomoc zamiast wydawania poleceń i nadzorowania.

Następny krok to: nie polegać zbytnio na liderze zespołu. Zawsze sugeruję, że aby sprawdzić swoje umiejętności kierownicze, lider powinien wziąć dwa tygodnie wolnego (koniecznie obejmujące planowanie sprintu itd.). Należy zmierzyć czas i wysiłek potrzebne na przygotowanie do nieobecności. Czy możesz zniknąć w dowolnej chwili? Pod żadnym pozorem nie odbieraj telefonu. Gdy wrócisz, sprawdź skrzynkę e-mail. Czy możesz bezpiecznie usunąć wszystkie wiadomości? Jeśli odpowiedź na którekolwiek z tych pytań brzmi „nie”, to znaczy, że Ty jesteś wąskim gardłem. Nie sprawiaj, by jakikolwiek proces wymagał Twojego udziału. Jedyne zadanie, które spoczywa na Tobie, to promowanie otwartej komunikacji.

Lider, który dzieli poszczególne User Story na zadania, przydziela zadania członkom zespołu, zajmuje się całą komunikacją, podejmuje zobowiązania wobec klienta, nie będzie mieć samoorganizującego się zespołu. Lider musi pracować tak, aby być niepotrzebnym w pracy.

Oczywiście nie jest to łatwe — nie wystarczy zamówić pizzę i zostawić zespół samemu sobie. Lider musi dbać o to, by zespół pozostawał skupiony na celu długoterminowym. Powinien też motywować poszczególnych członków zespołu i zapewniać im poczucie sensu pracy. Tu skuteczną metodą jest zaplanowanie z wyprzedzeniem co tygodniowych spotkań indywidualnych z wszystkimi członkami zespołu. Lider powinien słuchać oraz być mentorem i przewodnikiem.

Najważniejszym zadaniem jest zapobieganie dyskusjom na temat „Czyja to wina?”. Lider nie powinien dopuścić do wytykania palcami ani polowań na czarownice.

Typowa rozmowa:

• Kto za to odpowiadał?
• Zespół.
• Czyja to wina?
• Najpierw zajmijmy się usunięciem usterki, a następnie przeprowadzimy retrospektywę, aby poprawić proces i uniknąć takiego problemu w przyszłości.

Pamiętaj, aby nie przekształcić jednego problemu, zapotrzebowania na oprogramowanie, w dwa problemy: zapotrzebowanie na oprogramowanie plus konieczność zarządzania zasobami. Dzięki właściwym wskazówkom zespół zrozumie, że sam musi udowodnić swoją zdolność działania w sposób niezależny i dynamiczny.