Czynnik sukcesu 1:
Kultura zwinnego zespołu poprzez osobiste zaangażowanie, uczenie się i doskonalenie
Aby wdrożenie agile zakończyło się sukcesem, konieczne jest, aby członkowie zespołu osobiście zaangażowali się w wartości i zasady agile. W końcu agile opiera się na ludzkiej komunikacji i interakcji. Dlatego też samo narzucenie lub wdrożenie metod zwinnych nie przyniesie oczekiwanych rezultatów. Potrzebna jest kultura organizacyjna otwarta na zwinne sposoby myślenia oraz nowoczesne przywództwo, które samo jest gotowe stać się zwinne: porzucić myślenie hierarchiczne, dać przestrzeń dla samoorganizacji oraz inaczej podejść do mechanizmów planowania i kontroli. Kultura, która pozwala na popełnianie i uczenie się na błędach oraz oferuje miejsce na eksperymenty, zapewnia optymalny klimat dla ciągłego doskonalenia i adaptacji do zmieniających się okoliczności. Jednostki mogą odegrać kluczową rolę w tej zmianie kultury, rozwijając się w “zwinnych superbohaterów” (Holz, B.&Knoernschild,K., lipiec 2018), czyli osoby o odpowiednich cechach i umiejętnościach, które mogą pełnić rolę wzorców i ambasadorów. Pomagają one w rozpowszechnianiu zwinnych praktyk w organizacji. Ale agile odnosi sukces tylko wtedy, gdy zespół może wyłonić się z grupy jednostek. Aby odnieść sukces w agile, członek zespołu musi, oprócz umiejętności technicznych, posiadać wiedzę biznesową, architektoniczną, silne umiejętności komunikacyjne oraz zdolność do efektywnej współpracy i utrzymywania relacji.
Czynnik sukcesu 2:
Doświadczeni programiści, umiejętności techniczne i dobry kod źródłowy
Jedną z zasad agile jest ciągła dbałość o wysoką jakość techniczną. Ze względu na nacisk na szybkość, w metodzie zwinnej można ulec pokusie pójścia na skróty w kodzie źródłowym, co może prowadzić do powstania długu technicznego. Doświadczony programista jest bardziej świadomy skrótów i może lepiej ocenić krótko- i długoterminowe implikacje. Nie dotyczy to tylko metod zwinnych, ale w tym przypadku dąży się do większej zwinności, a utrzymanie czystego kodu źródłowego staje się bardziej istotne niż w przypadku metod wodospadowych. Baza kodów jest pod większą presją w agile, co może prowadzić do tego, że – jeśli agile jest źle wdrożony – trudniej jest dostarczyć poprawnie działające elementy w każdej iteracji. Craftsmanship i ciągłe refaktoryzowanie kodu źródłowego oraz “lekka” dokumentacja są zatem kluczowe dla utrzymania zrównoważonego tempa zwinnego rozwoju. Dopiero gdy to opanujemy, sensowne staje się skalowanie zespołów zwinnych i rozprzestrzenianie ich na inne części organizacji. Niebezpieczeństwo związane z agile polega na tym, że wszystko musi być zrobione szybciej, ale na dłuższą metę ucierpi na tym jakość. Agile nie działa szybciej i lepiej, ale wolniej i bardziej podatnie na błędy. Jest to jedno z największych ryzyk przy wprowadzaniu agile.
Czynnik sukcesu 3:
Szkolenia i coaching w zakresie pracy zwinnej
Około 52 procent respondentów w badaniu przeprowadzonym przez AEB jako największą przeszkodę podaje brak doświadczenia i wiedzy na temat tego, jak przejść z tradycyjnych metod kaskadowych na metody zwinne. Dobre wsparcie ze strony doświadczonych trenerów i coachów agile zarówno dla IT, jak i biznesu jest więc jednym z czynników czynników sukcesu. W celu opanowania zwinnego rozwoju, ważne jest, aby programiści poznali techniki niezbędne do rozwoju iteracyjnego w krótkim cyklu. Jak zapewnić prawidłowo działające rozwiązanie na koniec sprintu? Jakie są najlepsze praktyki techniczne zwinnego rozwoju? Na przykład, Scrum nie oferuje żadnych standardów dotyczących tego, co dokumentować, a czego nie, ani w jakiej formie. Co to jest “wystarczająca” dokumentacja? Pytania te mogą powodować zamieszanie w metodach zwinnych i prowadzić do tego, że ludzie – niesłusznie – w ogóle nie tworzą żadnych projektów. Dlatego też szkolenia i wskazówki są niezbędne. Dzięki zrozumieniu zasad i wartości Manifestu Agile oraz różnych ram i technik agile, możliwe staje się również wybranie z nich najbardziej odpowiednich i dostosowanie do własnych, zmieniających się okoliczności. Bez odpowiedniego opanowania zwinnych praktyk w zespołach, samo odgórne narzucenie metod zwinnych jest ryzykowne. Szkolenia i treningi w zakresie metod zwinnych powinny równieżuwzględniać obawy dotyczące sposobu postępowania w przypadku ewentualnego przekroczenia budżetu. Jak mierzyć sukces inicjatyw zwinnych? W jaki sposób możemy stworzyć zwinne ramy, które zapewnią niezbędną dyscyplinę i zarządzanie, aby jak najlepiej zarządzać ryzykiem? Agile Scrum oferuje zwinne formy, takie jak planowanie historii użytkownika, planowanie sprintu, codzienne standupy, przeglądy sprintu, retrospektywy sprintu i skrupulatne prowadzenie dziennika produktu.
Czynnik sukcesu 4:
Skalowanie poza zespół IT i angażowanie partnerów zewnętrznych
Multidyscyplinarne podejście agile oznacza, że przedstawiciele biznesu są również częścią zespołu programistów. Jeśli reszta organizacji poza działem IT nie jest zaznajomiona ze zwinnymi metodami pracy i filozofią leżącą u ich podstaw, zwinne zespoły mogą napotkać przeszkody. Mogą popaść w konflikt z odgórnym, zorientowanym na kontrolę stylem zarządzania, oporem wobec zmian oraz brakiem zrozumienia i obycia. 70 procent członków zespołów agile uważa te czynniki za główne źródło napięć między zespołami agile a resztą organizacji. Dla sukcesu zwinnych metod rozwoju konieczne jest zatem, aby zwinny sposób myślenia pojawił się również poza zespołem programistów lub działem IT, usuwanie murów pomiędzy zespołami scrumowymi i skalowanie agile do reszty organizacji. Jest więc oczywiste, że zespoły spoza działu IT również powinny pracować zgodnie z metodami zwinnymi, z tymi samymi rytuałami, takimi jak codzienne standupy i retrospektywy sprintu. Również w przypadku współpracy z partnerami zewnętrznymi, jak to miało miejsce w przypadku Hardis i DocData podczas wdrażania systemu Reflex WMS w bol.com, ważne jest, aby dla udanego wdrożenia metod zwinnych usunąć jak najwięcej przeszkód.. Można to osiągnąć przede wszystkim poprzez otwartość na bliską współpracę z partnerami zewnętrznymi i włączenie ich do zespołu agile. Strona zewnętrzna musi być również zaangażowana w relacje z klientem i przejąć pełną odpowiedzialność za wspólne interesy i problemy. Krótko mówiąc: bądź prawdziwym partnerem.
Czynnik sukcesu 5:
Krótkie cykle dostaw i zautomatyzowane testowanie (DevOps)
Ze względu na szybkie cykle wydawnicze i wysoką częstotliwość dostarczania zmian w zwinnym podejściu deweloperskim, konieczne są intensywne testy. Poprzez częstsze i bardziej intensywne testowanie, baza kodu staje się bardziej stabilna, a ciągłe doskonalenie agile staje się naprawdę osiągalnym celem. Między innymi dzięki zastosowaniu technik DevOps, możliwe staje się utrzymanie zaangażowania testowego w zarządzaniu. Zautomatyzowane testowanie pozwala na wykonanie testu regresji end-to-end w ciągu kilku minut zamiast dni. Techniki zwinne, takie jak ciągła integracja i zautomatyzowane wdrażanie, zapewniają stały przepływ nowych funkcji do produkcji. Okresowe publikacje są zatem zbędne. Projekty” mogą być postrzegane jako duży zestaw cech, gdzie każda cecha z osobna dostarcza wartość biznesową. Mogą one być w coraz większym stopniu dostarczane poza projektami, tak że docelowo, pod wpływem metod zwinnych, również projekty będą coraz bardziej odchodzić w cień (Scrum Alliance,2018).
Przypadek klienta:
bol.com wprowadza innowacje WMS w zwinnym ekosystemie z partnerami zewnętrznymi
Sprzedawca internetowy bol.com musiał poradzić sobie z rosnącą złożonością handlu elektronicznego podczas przejścia na nowy system WMS. Przyczynił się do tego głównie wzrost sprzedaży internetowej oraz nowe propozycje dla klientów w zakresie rabatów, promocji i terminów dostaw. Ponadto, liczba kategorii produktów nadal rosła, podobnie jak liczba i różnorodność partnerów sieciowych w największym sklepie internetowym w Holandii.
Podczas wymiany swojego systemu zarządzania magazynem, bol.com wybrał podejście agile-scrum w ścisłej współpracy z dostawcą oprogramowania Hardis i dostawcą usług logistycznych DocData. W ten sposób powstał “ekosystem” partnerów biznesowych.
Przy projektowaniu zastosowano zwinne planowanie w celu wykorzystania prototypów w różnych iteracjach, aby dojść do rozwiązania WMS opartego na zaprojektowanych procesach biznesowych. Multidyscyplinarne zespoły scrumowe składające się z konsultantów i programistów zarówno z Hardis, jak i bol.com pracowały w sprintach nad stopniowym ulepszaniem i rozbudową systemu Reflex WMS. Hardis zobowiązał się do wydawania aktualizacji do rdzenia WMS kilka razy w roku.
Podczas pierwszego uruchomienia dostarczono działający i zintegrowany podsystem, w tym niezbędny sprzęt, sieć oraz organizację zarządzającą i wspierającą. Oznaczało to, że początkowe problemy można było rozwiązywać na wczesnym etapie. W kolejnych etapachgo-live funkcjonalność była rozszerzana krok po kroku, w zależności od zmian w środowisku logistycznym. Najważniejszym wymogiem było to, aby klienci nie zauważyli żadnego rozszerzenia. W tym celu wdrożono plan ramp-up z bramkami KPI, aby zmniejszyć i kontrolować ryzyko. Przy każdym uruchomieniu można było liczyć na w pełni funkcjonującą organizację zarządzającą, ponieważ już wcześniej, przy pierwszym uruchomieniu systemu WMS, działała ona na małą skalę.
Dobra współpraca z partnerami zewnętrznymi była kluczowa w tym projekcie. Praca w jednym wspólnym zespole scrumowym ułatwiła dzielenie się informacjami i zarządzanie oczekiwaniami. Codziennie odbywały się krótkie standupy z udziałem całych zespołów scrumowych Hardis i bol.com. Cotygodniowa koordynacja odbywała się z kierownikami projektów, a comiesięczna z odpowiedzialnymi dyrektorami.
Obecnie bol.com pracuje nad nowym centrum dystrybucji. Jest to kolejny przykład na to, jak agile jest wpleciony w ich kulturę. Nowe centrum dystrybucyjne jest budowane kawałek po kawałku. Gdy tylko komponent jest gotowy, zostaje uruchomiony. Można od razu sprawdzić, czy wszystko funkcjonuje prawidłowo i w razie potrzeby szybko wprowadzić ulepszenia, bez ujawniania tego dopiero pod koniec budowy. To także jest praca zwinna, nie w ramach IT, ale w ramach fizycznej konstrukcji.