W poprzednich częściach tego artykułu pisaliśmy o tym, czym jest agile charakteryzując go głównie poprzez opis podejścia Scrum (zobacz więcej) oraz sposobu tworzenia kultury organizacyjnej, która wspiera pracę wykonywaną w oparciu o metodyki zwinne (czytaj więcej).
Wspominaliśmy również, iż agile nie jest koncepcją zbyt nową, gdyż jego zasady ogłoszono w manifeście z 2001 roku. Dlatego też trudno się dziwić, iż przy szybko rozwijających się technologiach i trendach w zakresie zarządzania, już od kilku lat co raz częściej mówi się o podejściu „post agile”. Zwolennicy tej nowej krytycznej fali zarzucają „agileowcom” przede wszystkim zbytni fanatyzm i bezmyślne stosowanie metodyk zwinnych niezależnie od specyfiki realizowanego projektu, jak również przeświadczenie, iż wdrożenie tego podejścia w organizacji rozwiąże jej wszystkie problemy (tzw. Cargo Cult Agile).
Już w 2011 roku Mike Gualtieri w swoim artykule „Agile Software Is A Cop-Out; Here’s What’s Next” zwracał uwagę na 2 obszary, które według niego świadczyły o słabości i niedojrzałości tego podejścia:
- Używanie „działającego oprogramowania jako podstawowej miary postępu” jest narcystyczne. Myślenie, że kod jest miarą wszystkiego jest błędem. Software jest zawsze tylko częścią większej całości. Działa w bezpośrednim lub pośrednim połączeniu z innymi oprogramowaniami, technologiami, środowiskiem, procesami biznesowymi i ludźmi w celu stworzenia odpowiedniego Customer Experience lub/i udoskonalenia wydajności operacyjnej. Zatem takie podeście jest zdecydowanie „dewelopero-centryczne”, a nie „użytkowniko-centryczne”.
- Zasada „Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu” jest rozleniwiająca. Odzwierciedla kapitulację deweloperów, którzy nie mogą zrozumieć prawdziwych wymagań. Tymczasem codzienne (lub bardzo częste) spotykanie się z ludźmi z biznesu nie ma większego sensu, szczególnie, iż najczęściej to nie oni są ostatecznymi użytkownikami oprogramowania czy też ekspertami w zakresie projektowania. Ponadto, kto z nich może przeznaczyć tyle czasu na dyskusję z deweloperami. Zespół deweloperski musi po prostu zrozumieć wymagania użytkowników i biznesu lepiej niż siebie.
Natomiast Thomas Cagley w tekście „Post-Agile Age: The Age of Aquarius (Something Better is Beginning)” z 2016 roku wskazuje cztery przyczyny, dla których Manifest Agile traci na wartości:
- „Metodyczne Lemingi” – bezmyślne podążanie za zasadami Agile, a co się z tym wiąże częste ich realizowanie w niewłaściwy sposób,
- „Zakazujące Normy” – tworzenie ograniczeń wokół metod, co zmniejsza elastyczność,
- „Ekosystemy Zorientowane na Markę” – rozprzestrzenianie się różnych konkurencyjnych szkół,
- „Brak Systemowego Myślenia/ Zarządzania” – bardziej powrót do zarządzania ludźmi niż do systemowego oglądu.
Mimo pojawiania się wielu głosów krytycznych w stosunku do manifestu Agile i zastosowania go w praktyce, podejście „post agile” nie jest nadal spójne i eksperci nie są do końca zgodni, co do jednej całościowej definicji, czy też założeń. Nowy nurt warto jednak przyrównać do nawiązującego pod względem etymologicznym pojęcia, jakim jest postmodernizm. To termin oznaczający w sztuce niejednolity ruch artystyczny, który daje przestrzeń do konfrontacji różnych koncepcji i rozwiązań, a wspólnym mianownikiem łączącym twórców jest polemiczne podejście do jednolitej wizji świata.
Tę ideę bardzo dobrze odzwierciedla w swoim artykule „50 shades of agile: Software development since the Manifesto” Mike Perrow pisząc, że aby być efektywnym w zakresie rozwoju oprogramowania trzeba patrzeć szeroko:
- zrozumieć swoją organizację i kulturę w zespole deweloperskim,
- nie ograniczać się do jednej metodologii, ale przyglądać się uważnie co sprawia, że Twój zespół deweloperski z sukcesem osiąga cele wspierające biznes,
- dostosować swoje podejście do danego projektu i ludzi, z którymi będziecie musieli pracować.
Podsumowując nasz cykl, warto zauważyć, iż dobór sposobu rozwoju oprogramowania zależy od bardzo wielu elementów, tak samo jak wybór form doskonalenie kompetencji pracowników. Jako HR powinniśmy zatem wspierać zespoły deweloperskie poprzez budowanie odpowiedniej kultury organizacyjnej, pozyskiwanie i pomoc w utrzymywaniu osób znających różne metody pracy, motywowaniu do przeprowadzania pogłębionej diagnozy sytuacji i znajdowania na jej podstawie optymalnej formuły realizacji danego projektu.
