- Czy nadgodziny dowiozą na czas? — 01/10/2020
- Przewodnik po EBM po polsku — 21/07/2020
- Kolejny raport o Agile. I co z tego? — 02/06/2020

Kolejny raport o Agile. I co z tego?
Wnioski autorów i komentarz
Kultura organizacyjna nadal ma znaczenie
Kultura organizacyjna nadal ma duże znaczenie. To, że obecna kultura organizacji różni się od tej reprezentowanej przez mindset Agile jest znaczącą przeszkodą w organizacji. W tej wersji raportu autorzy umieścili też opcje zbyt małego zaangażowania kierownictwa. Nowa odpowiedź również znalazła się w top 5.
Te wnioski pokrywają się z naszymi obserwacjami. W większości transformacji kierownictwo uważa, że jego transformacja nie dotyczy. Styl zarządzania command & control nie jest kompatybilny ze środowiskiem Agile. W Agile, gdzie sercem są samoorganizujące się zespoły, potrzebny jest styl zarządzania servant-leadership. Również system premiowania skupiony na indywidualnych osiągnięciach i KPI przeszkadza realizowaniu wspólnych, zespołowych celów i mierzeniu wartości produktu.
Scrum i SAFe dominują
Scrum i jego kombinacje z innymi metodami/frameworkami to aż 75% rynku. I tutaj znowu mamy podobne obserwacje, bo często spotykamy się z myśleniem Scrum=Agile i Agile=Scrum. Trochę to wynika z braku wiedzy, a trochę z dużej popularności Scrum na rynku. Dlaczego Scrum jest tak popularny? Chyba najlepsza hipoteza, to że Scrum ma dobry balans pomiędzy narzucaniem sposobu pracy i pozostawianiem swobody.
Zastanawiamy się nad tym, po czym respondenci ocenili, że używają Scruma. Czy tylko przez to, że mają przynajmniej niektóre role, wydarzenia i artefakty? Co ze Scrum BUT, Zombie Scrum. A na przykład Scrum with Kanban? Czy to będzie tutaj jako Scrum czy Scrumban? Odpowiedź Other/I don’t know pozostawiamy bez komentarza.
W skalowaniu nadal zdecydowaną większość rynku ma SAFe. Ale z drugiej strony tylko 35%. Nie ma w zestawieniu Scrum At Scale, który ma bogatą bibliotekę Case Study. Nie widzimy też tak popularnego w bankach i telekom Modelu Spotiify.
Zaskakujące jest umieszczenia Scrum of Scrum jako metody skalowania. Jest to co najwyżej praktyka, która w róznych formach występuje we frameworkach i metodach skalowania (np. SAFe, Scrum At Scale, Nexus).
Ciężko powiedzieć co autorzy i respondenci mają na myśli przez Enterprise Scrum. Znowu pojawia się kategoria Don’t Know/Other, która ma prawie taki sam udział w rynku jak SAFe.
Top 5 powodów dla transformacji bez zmian od lat
W tym roku top pięć powodów dla adopcji Agile to:
- Przyspieszenie dostarczania oprogramowania
- Zwiększona możliwość zarządzania zmieniającymi się priorytetami
- Wzrost produktywności
- Większa zgodność biznesu i IT
- Wyższa jakość oprogramowania
Z kolei korzyści z adopcji Agile w tym roku to:
- Zwiększona możliwość zarządzania zmieniającymi się priorytetami
- Widoczność projektów (Transparencja?)
- Większa zgodność biznesu i IT
- Szybsze dostarczanie oprogramowania
- Morale zespołu
Jak rozumieć te różnice pomiędzy powodami a korzyściami transformacji Agile? Powody bardziej rozumiemy jako to co organizacja zakładała jako cel. Korzyści to jest to, co zaobserwowali w wyniku transformacji. W ten sposób można wytłumaczyć różnice i sens posiadania dwóch kategorii.
Podsumowując szybsze dostarczanie oprogramowania, łatwiejsza zmiana priorytetów oraz zgodność biznesu i IT są osiągane zgodnie z założeniami. Wydaje się, że są to naturalne efekty wdrożenia Agile, ponieważ zmienność backlogu i realizowanie krótkich iteracji wspierają zarządzanie zmieniającymi się priorytetami. Z kolei nacisk na Definition of Done i ukończone przyrosty powinny naturalnie prowadzić do częstszych i szybszych wdrożeń.
Trochę gorzej ze zwiększeniem produktywności i jakości. O ile łatwo jest ocenić poziom jakości, o tyle nie wiemy jak postrzegana jest produktywność. Morale zespołu nie było tak ważne, ale zauważono poprawę.
Naszym zdaniem najciekawsze jest to, że zmniejszenie kosztów nie jest tak znaczącym czynnikiem jak w poprzednich latach. Spadek z 41% na 26% jest dosyć znaczący. Czyżby oczekiwania “Agile=taniej” odeszły do lamusa?
Co jeszcze można wyczytać?
Organizacje zaczynają mierzyć i szukać danych
Ponad połowa respondentów stosuje lub ma zamiar zastosować Value Stream Management. Oznacza to, że organizacje zaczynają przyglądać się efektywności swoich procesów i szukają konkretnych usprawnień. Value Stream Mapping jest częstym narzędziem, które stosujemy u klientów. Baczne przyglądanie się procesom naturalnie spowoduje znalezienie prawdziwych przeszkód w szybkości wdrożeń i dostarczaniu wartości biznesowej. Można tutaj liczyć również, na szersze spojrzenie na proces niż tylko na poziomie zespołu.
W raporcie widzimy, że główne obszary transformacji Agile to Software Development, IT i operations. Przecież Agile to głównie zdolność organizacji do reakcji na zmiany. Jak można to osiągnąć bez zmiany sposobu pracy biznesu?
Coraz więcej zagadnień technicznych
Wygląda na to, że organizacje zdają sobie sprawę z konieczności dostosowania technologii i narzędzi do pracy zwinnych zespołów. Więcej testów automatycznych, Continuous Integration, Continuous Delivery, Continuous Deployment stają się coraz bardziej powszechne. Być może skupienie na Technical Excellence spowoduje oczekiwany wzrost jakości w kolejnych raportach.
Niestety wszystkie te praktyki są wrzucone do worka DevOps, chociaż z założenia DevOps powinno oznaczać zespoły Developement i Operations pracujące razem albo tego typu kompetencje w jednym zespole. Tak czy inaczej tego typu praktyki znacznie ułatwiają szybsze dostarczanie wartości. DevOps dosyć często jest określana jako enabler dla zwinności.
Potrzeba szkoleń i wsparcia transformacji
Patrząc na trudności w Transformacji Agile możemy wyróżnić dwie spójne grupy.
Ogólny opór przed zmianą, brak zaangażowania kierownictwa, kultura organizacyjna niekompatybilna z Agile, brak wsparcia kierownictwa można podsumować jako dużą potrzebę wsparcia organizacji przez coaching i doradztwo.
Niespójne procesy i praktyki, praktyk umiejętności i doświadczenia w Agile, niewystarczające szkolenia i edukacja wskazują na potrzebę szkoleń. Te dwie kategorie pojawiają się w raporcie od lat.
To co obserwujemy ze swojej strony to duża popularność szkoleń Professional Scrum Master i Professional Scrum Product Owner. Szkolenia dla zespołów takie jak Professional Scrum Foundations i Professional Scrum Developer cieszą się dużo mniejszą popularnością. Co wydaje się dziwne patrząc na skład Zespołu Scrum (1 PO, 1 SM, 3–9 Developerów). Na szkoleniach rzadko spotykamy Dyrektorów. Mało osób bierze udział w szkoleniu Professional Agile Leadership (PAL‑E). Jeszcze rzadziej można spotkać kardę zarządzającą na szkoleniach ze skalowania takich jak Scaled Professional Scrum i Scrum at Scale Practitioner. Powyżej poziomu Dyrektora management nie jest zainteresowany edukacją w zakresie Agile i w najlepszym wypadku znajduje czas na prezentację. Równie rzadko uczestniczą aktywnie w jakimś Zespole Scrumowym.
Podsumowanie
Szukanie usprawnień w całym Value Stream czy wiesze skupienie na aspekcie technologicznym wskazują na to, że świadomość organizacji się zwiększa.
Z drugiej strony niestety nadal pojawia się potrzeba edukacji i wsparcia. Potrzeba również zacząć pracować z kierownictwem organizacji.
Podsumowując można powiedzieć, że inwestowanie w ludzi znacząco zwiększy szanse udaj transformacji Agile i przyniesie więcej oczekiwanych rezultatów.
Dzięki za syntetyczne przedstawienie wniosków. No i za czujność, w poprzednich latach raport pojawiał się na początku maja i gdy w drugiej połowie maja dalej go nie było, ani jakiejkolwiek wzmianki na stronie, że już za momencik nadejdzie, to przestałem monitorować sytuację.
Co do zawartości: także dla mnie ciekawym jest całkowity brak S@S, a także Spotify Model. Dotychczas (w roku wcześniejszym) stawiałem tutaj znak równości opierając się na komentarzach H. Kniberga nt. zastosowania S@S w Spotify. Zakładałem, że jest reprezentowany w dość niewielkich procentach, ale widząc niewielki zakres LeSS i Nexus mogłem jakoś to zaakceptować.
Jak co roku zaskakująca jest liczba przy Scrum of Scrums. Podobnie jak Krystian postrzegam to w tym kontekście jako jedną praktykę używaną szeroko w różnych podejściach, a nie całą metodę skalowania. Może respondenci nie są wystarczająco kumaci (kolokwialnie mówiąc), a może my o czymś nie wiemy?
W tym drugim kontekście ciekawe jest streszczenie na innej stronie, linkowanej na oficjalnej stronie raportu (https://explore.digital.ai/state-of-agile/the-14th-annual-state-of-agile-report-is-here). Tam wspomniany Scrum of Scrums jest utożsamiany właśnie ze Scrum@Scale. Dosłownie (acz w moim tłumaczeniu/rozumieniu) stawiana jest tam teza, że Scrum@Scale został zdystansowany o 19% przez SAFe i zajął dobre, drugie miejsce w rankingu na frameworki skalowania. Tak jak wydaje się to dość dużym (zbyt dużym) uproszczeniem, tak tę drogę obrali tamtejsi autorzy.
Jako że link do tego artykułu jest publikowany dosłownie obok linku do raportu (kafelek obok, w pierwszym wierszu na górze), to można nieśmiało domniemywać, że ktoś zadbał o review zawartości i jest to napisane w pełni rzetelnie, i co za tym idzie: S@S jednak jest względnie mocno wykorzystywany na świecie (a przynajmniej tam, skąd pochodzili respondenci) :)