De pluspunten van agile softwareontwikkeling, waarbij de bouw van grote applicaties in korte, overzichtelijke iteraties wordt opgehakt, hebben de afgelopen jaren de meeste aandacht gehad. Het maakt grote softwareprojecten behapbaar en organisaties wendbaarder. Minpunten zijn er ook. Zo is het in veel gevallen onduidelijk of de kosten wel in balans zijn met de baten.
Het is niet verbazingwekkend dat de kosten van agile softwareontwikkeling bij menige organisatie behoorlijk uit de klauwen zijn gelopen, terwijl de baten achterblijven. Dat komt omdat een gedegen onderbouwing van een agile softwareproject doorgaans ver te zoeken is. Het lijkt wat dat betreft op de laatste dieetmode: veelbelovend, maar de resultaten blijven uiteindelijk toch vaak achter bij de verwachtingen ook al zet degene die af wil vallen zich toch zo in.
Waar je bij een dieet nog enige objectieve meetbaarheid hebt – calorieën en lichaamsgewicht – worden bij agile rekkelijke begrippen als klanttevredenheid en velocity ofwel ontwikkelsnelheid als concrete doelstellingen opgevoerd. Dat is veel te mager gezien de enorme investeringen die met deze softwareprojecten gemoeid gaan. Het is niet voor niets dat CFO’s aandringen op een betere meetbaarheid van de gehele agile-methodiek (zie ook deze blog)
Niet alleen vanuit het oogpunt van financiën moeten er meer harde feiten komen, ook het hogere management ontbreekt het meestal aan afdoende stuurinformatie. Er worden geen gestandaardiseerde meetmethoden binnen de agile werkwijze toegepast, terwijl deze er wel zijn. Sterker nog één van de basisprincipes van het ‘Agile Manifest’, is dat een team zelfsturend is en naar eigen inzicht verschillende teamleden bij het project betrekt. Schaalbaarheid is problematisch. Agile werkt het beste in teams van beperkte omvang (tussen 3 en 9 mensen) en teams werken tot in hoge mate zelfstandig. Opschalen doe je door meerdere teams naast elkaar te zetten. Ieder team doet dingen op een eigen manier, hetgeen een nadelige impact heeft op het geheel.
Dat gebrek aan meetbaarheid is niet zo vreemd, omdat het zwaartepunt bij agile nu eenmaal op de individuele teams ligt en niet op de aansturing en ondersteuning. Van teams wordt verwacht dat ze het zo veel mogelijk zelf uitzoeken en bijgevolg wachten deze nog wel eens te lang met hulp inroepen van senior expertise. Daar hebben snelheid en kwaliteit onder te lijden. Gevolg is dat de doorlooptijd van projecten vaak slecht wordt ingeschat terwijl er tegelijkertijd organisatorisch niet aan bepaalde knoppen te draaien valt.
Over kwaliteit gesproken, in de IT is het al decennialang gewoonte dat mensen langs de zijlijn in een QA-achtige rol worden toegevoegd om de kwaliteit van software omhoog te krijgen. Denk aan de hele testindustrie, ISO/ISAE-consultants en aan architecten voor wie QA gewoon een deel van hun werk is. Het is natuurlijk niet realistisch te verwachten dat agile-teams dat ineens zelfstandig gaan doen. Dus wie bewaakt de kwaliteit zonder dat dit ten koste gaat van de benodigde snelheid?
Net zoals bij het volgen van een dieet ligt vervallen in oude patronen op de loer. Organisaties denken dat ze met een dagelijkse standup en tweewekelijkse sprint agile bezig zijn. Maar als sprint 1 het basisontwerp is, sprint 2 het detailontwerp van de database, sprint 3 het detailontwerp van de rapportages en… sprint 8 de realisatie van de rapportagefunctie, hoe agile ben je dan werkelijk? Dan heeft het er alle schijn van dat de traditionele manier van werken in een agile keurslijf is geduwd. Met voorspelbare gevolgen: kostenoverschrijdingen, achterblijvende functionaliteit en kwaliteit en deadlines die standaard niet gehaald worden.
Het is hoog tijd voor een reality check op agile. Dat kan met gestandaardiseerde metingen op productiviteit en kwaliteit van softwareprojecten zoals METRI dit aanbiedt. Daarnaast is ook governance essentieel. Organisaties worden alsmaar afhankelijker van software. Je kunt binnen een paar dagen failliet zijn als een kritiek systeem faalt en er geen tijdige remedie te vinden is. De aansturing van agile softwareontwikkeling is dan ook aan een nieuwe benadering toe. Want binnen een paar dagen failliet gaan is misschien wel heel agile, maar niet volgens plan…
Aanmelden
METRI organiseert op donderdag 4 april van 13.30 tot 18.00 uur samen met Cast het seminar “How to use Software Intelligence to save cost and prove more business value”. Deze bijeenkomst geeft u meer inzicht in het applicatie portfolio van uw organisatie en de mogelijke risico’s die hierin verborgen zitten. Software Intelligence biedt niet alleen inzicht in de risico’s, maar levert ook concrete handvatten om de grootste risico’s uit te mitigeren. Volg voor updates de LinkedIn-pagina van METRI: https://www.linkedin.com/company/metri/