Wspólnym mianownikiem tegorocznych panelistów konferencji „Agile w biznesie” były lata doświadczeń przepracowane na bazie zwinnych metodyk. Każdy z nich miał do przekazania szereg obserwacji dotyczących kwestii, o których warto pamiętać w średnio- i długookresowej praktyce funkcjonowania Agile w kulturze organizacyjnej firmy.

„Po kilku latach ujawnia się problem z określeniem, czy na pewno robimy rzeczy strategiczne” – przyznaje Robert Skrzypczak, dyrektor IT w AXA Polska. Wydzielone pod poszczególne linie biznesowe zespoły deweloperskie, tygodniowe sprinty oraz skupiona na nich uwaga Właścicieli Produktów (Product Owners) i menedżerów sprawiają, że utrzymanie strategicznej perspektywy w realizowanych pracach jest wyzwaniem. „Brakuje mi kogoś, kto ustalałby, czy dana inicjatywa jest na pewno zgodna ze strategią, kto pomógłby przemyśleć, czy na pewno w tym tygodniu chcemy angażować się w dany projekt” – mówi Skrzypczak.

Zobacz również:

• Panfofelki, ameby, koty… Scrum jako droga do efektywnej organizacji szczęśliwych pracowników

„Zachowanie dyscypliny planowania jest trudne” – stwierdza Rober Skrzypczak, i podkreśla: „Agile nie powinien oznaczać, że mamy nie planować. Mamy na przykład projekty regulacyjne, np. – w przypadku firmy finansowej, takiej jak AXA – rekomendację D”. Termin dostosowania środowiska IT w firmie jest sztywno ustalony przez regulatora, a do zapewnienia zgodności z nowymi przepisami konieczny jest duży nakład pracy. Pracę należy więc zaplanować, pamiętając przy tym, że charakterystyczny dla Agile brak początkowego uwzględnienia całości wymagań funkcjonalnych oraz tygodniowe iteracje nie będą ułatwiały oszacowania niezbędnego czasu.

Zmiany wprowadzane przez kolejne iteracje sprawiają, że szacowanie zasobów jest wyzwaniem. Jak wspomniano wyżej, Agile nie przewiduje kompleksowego opisu założeń funkcjonalnych, co generuje trudności także w odniesieniu do określenia niezbędnych na rzecz realizacji zasobów. Robert Skrzypczak z AXA przedstawia to obrazowo: „przedstawiciel biznesu mówi, że chce samochód, i na tym szczegóły się kończą. Potem w toku prac okazuje się, że ten samochód ma wozić znacznie więcej ludzi, niż początkowo zakładaliśmy, a do tego jeszcze przyczepę. Wymagania zmieniają się wraz z procesem wytwórczym, ale na końcu nikt o tym nie pamięta. Tymczasem do zarządu trafia podsumowanie projektu, w którym napisane jest, że to co miało kosztować 100, kosztowało 300, a w ogóle efekt jest nie do końca taki, jaki miał być”.

Można oczywiście ustalić listę szczegółowych wytycznych, ale przecież nie o to chodzi w podejściu zwinnym. Uniknięcie problemów związanych z szacowaniem zasobów oraz dostarczaniem pożądanych funkcji wymaga pracy doświadczonego Właściciela Produktu, który na bieżąco będzie pilnował zgodności powstającej usługi z potrzebą określoną przez linię biznesową.

Zwinne zespoły IT ograniczają liczbę błędów. „Rozwiązaliśmy problem ogromnej liczby defektów – nie przez budowę dużego działu Q&A, ale migrację kompetencji testerskich do zespołów deweloperskich. Zespół Q&A buduje jedynie narzędzia, które wspierają automatyzację testów. To deweloper jest odpowiedzialny za jakość, nie dział IT” – podkreśla Jarosław Walaszek, członek zarządu DreamLab w Grupie Onet. Działający w zwinnych zespołach deweloperzy powinni być szczególnie uczulani na kwestie bezpieczeństwa.

Niezbędny jest kompromis między zwinnością a ładem architektonicznym i bezpieczeństwem. W jaki sposób zapewnić zgodność kilku realizowanych na raz przez różne zespoły iteracji projektów IT? Dotyczące ich decyzje zapadają w zasadzie z tygodnia na tydzień. Robert Skrzypczak proponuje rozwiązanie: „W AXA ustaliliśmy, że jeśli projekt trwa powyżej 4 dni roboczych, musi obowiązkowo przejść walidację architektów oraz specjalistów od bezpieczeństwa”. Wcześniej okres ten ustalony był na 2 dni, to jednak mocno ograniczało zwinność.

Podporządkowanie zespołów IT biznesowi ogranicza zasoby na informatyczny backoffice. Dawny, funkcjonujący jeszcze w logice kaskadowej zespół deweloperski AXA został w ramach transformacji Agile podzielony na mniejsze zespoły domenowe. Zasadniczo poprawiło to wydajność prac programistycznych, jednak „podzielenie zespołu IT na mniejsze sprawia, że nie mamy zasobów na pewne inicjatywy typowo informatyczne, np. migracje do nowych wersji czy między platformami” – przyznaje Robert Skrzypczak. Ponieważ zespoły IT znalazły się pod kontrolą linii biznesowych, teraz tam szukać trzeba alokacji niezbędnych zasobów.

Według Skrzypczaka kluczowe dla utrzymania sprawności firmowego IT będzie zatem odpowiednie nastawienie Właściciela Produktu, jego szerokie spojrzenie na sprawy firmy. To on raportuje do szefa danej linii biznesowej z koniecznością przeznaczenia zasobów na rzecz projektów, które nie są jednoznacznie związane z procesami biznesowymi. „W przypadku krótkowzrocznego Product Ownera jest tu duży potencjał do podejmowania arbitralnych decyzji” – przestrzega Rober Skrzypczak.

Powstaje rynek zasobów IT. „Jeśli w danym projekcie nie utylizuje się wszystkich specjalizacji członków któregoś z zespołów, jego członkowie są wypożyczani do innego zespołu. Przy dobrze współpracujących ‘Product Ownerach’ działa to bardzo dobrze, choć na początku nie jest proste” – twierdzi Rober Skrzypczak z AXA. W takim układzie zespoły wypracowują sobie metody wzajemnego wsparcia, a kompetencje w naturalny sposób alokowane są tam, gdzie ich najbardziej potrzeba.

Brak obciążania odpowiedzialnością za niepowodzenia wspiera innowacyjność i wydajność. Liczba zmian wprowadzanych w efekcie kolejnych sprintów jest bardzo duża, a wiele z nich ma charakter testowy. „Robimy maksymalnie dużo eksperymentów, pewne z nich po prostu nie działają” – stwierdza Jarosław Walaszek. Dodaje jednak, że „przy dużej liczbie niepowodzeń ludzie zaczynają sądzić, że po prostu się do tego nie nadają. Dlatego wprowadziliśmy kulturę ‘blameless’, dzięki której wzrosła ich aktywność, a innowacje przyspieszyły. Rozwiązanie to pozwala im stosować rozwiązania, na które wcześniej by sobie nie pozwolili, bojąc się, że ktoś wytknie im porażkę”.

Agile nie może się przy tym zacząć i skończyć tylko na IT, a zmiana mentalna nie jest prosta. „Największym kłopotem było przestawienie biznesu z myślenia kaskadowego na rzecz ‘try and buy’ – sprawdzania i testowania rozwiązań” – mówi Rober Skrzypczak.

Warto jednak próbować. Po dokonaniu zmiany biznes nie wyobraża sobie powrotu do Waterfalla. Ma poczucie, że jest blisko zespołów tworzących dedykowane dla niego narzędzia. Zadowoleni są także specjaliści IT – ich separacja od działów biznesowych zanika. „Efektywność per capita organizacji jest dużo lepsza. Pojawia się więcej kreatywności, a ludzie zyskują przestrzeń do rozpoczynania własnych inicjatyw” – podkreśla Kate Terlecka, Agile Coach i założycielka centrum szkoleniowo-doradczego Brass Willow.

Chmura oraz standaryzacja wspierają podejście Agile. „Mamy daleko posuniętą standaryzację i platformizację. Wszystko, co może zostać wykorzystane wielokrotnie powinno być standaryzowane i używane przez wszystkie zespoły” – podkreśla Jarosław Walaszek z DreamLab. To konieczne dla optymalizacji kosztów.

„Posiadanie 6 równolegle pracujących zespołów deweloperskich wymaga zapewnienia odpowiednich narzędzi. Kilka równolegle zachodzących zmian w bazach danych wymaga sporej koordynacji” – dodaje Robert Skrzypczak z AXA. Firma stosuje m .in. takie narzędzia jak repozytorium kodu czy platformy do automatyzacji powtarzalnych zadań.

Walaszek twierdzi, że środowisko informatyczne powinno w pewnym sensie przypominać fabrykę szybko dostarczającą niezbędne komponenty. Naturalnie takiemu podejściu sprzyjają technologie chmurowe oraz DevOps.

Agile niekoniecznie ułatwia współpracę z dostawcami IT. Metodyki zwinne cieszą się popularnością, co nie znaczy, że każdy dostawca deklarujący znajomość podejścia Agile rzeczywiście pracuje np. w Scrumie. „Mam wrażenie, że wiele firm podchodzi do metodyk zwinnych marketingowo. Zakładają, że jeśli zadeklarują brak znajomości Agile, to odpadną” – mówi Robert Skrzypczak. W efekcie problematyczne są często nie szczegóły – jak np. czas trwania iteracji – ale same podstawy. W takim wypadku nieoceniona jest rola Scrum Mastera, który musi sprawnie dostosować pracę dostawcy do firmowego zespołu deweloperskiego, ponieważ „nie da się pracować scrumowo i niescrumowo jednocześnie” – podkreśla Skrzypczak.

Scrum jest stratą. Ciągłe udoskonalanie zastanego środowiska pracy prowadzi do ciekawych obserwacji. „Zaryzykuję stwierdzenie – dla nas dzisiaj Scrum jest stratą. I przed takim wyzwaniem dzisiaj stoją nasi Scrum Masterzy” – mówi Jarosław Walaszek. „Dlaczego? Zmierzyliśmy koszty wszystkich spotkań scrumowych, które odbywają się w zespole. Efekt robi wrażenie. Spotkania te muszą przeliczać się na wartość. Jeżeli nie przeliczają się, trzeba nad tym pracować”. To zadanie zarówno dla specjalistów, jak i menedżerów. Podobnie jak każda inna kwestia, tak samo Agile wymaga optymalizacji i upraszczania. Jeżeli jakieś elementy procesu nie dodają wartości, należy zastanowić się, czy da się je usprawnić bądź wyeliminować.

„Spośród dostępnych ram i metodyk wybieramy rozwiązania pod konkretne problemy. Fundamentem jest u nas Lean IT, potrzeba ciągłego doskonalenia procesów i eliminowania strat. Ludzie sami widzą że coś staje się niepotrzebne i adaptują się” – opowiada Walaszek.

Do optymalizowania Scruma zachęcają także doświadczeni menedżerowie. „Scrum to przede wszystkim framework do możliwie jak najefektywniejszego tworzenia oprogramowania. Sam w sobie, jako metoda, jest jednak kosztem, dlatego po pierwsze należy ustalić, do czego służyć mają jego poszczególne elementy. W pewnym momencie rzeczywiście może się bowiem okazać, że ośmiogodzinny planning jest zbędny, a nam wystarczy np. pół godziny” – mówi Kate Terlecka z Brass Willow. Dodaje jednak, że modyfikacja Scruma jest ryzykowna, dopóki dobrze się go nie zrozumie.