Meer dan Scrum: waar Agile transformaties vaak te kort komen

De term ‘Agile’ is een beetje verpest. Het woord wordt overal rond gestrooid en iedereen bedoelt er net weer iets ander mee. Zelfs Dave Thomas – een van de ondertekenaars van het Manifesto for Agile Software Development – heeft gezegd: “Agile is dead“.

Maar de principes uit het manifesto zijn nog steeds van waarde en helpen organisaties bij het vergroten van de productiviteit en wendbaarheid; met name in de context van ontwikkeling van digitale producten en diensten. Werkmethoden die deze principes toepassen, zijn in de meeste situaties veel effectiever dan traditionele methodieken.

Veel organisaties kiezen er dan ook voor om naar een Agile methode over te gaan voor hun productontwikkeling. Maar veel organisaties onderschatten wat er voor nodig is om dit goed te doen. Veel van hen richten zich vooral op het invoeren van Scrum.

Even sprinten en klaar…

In veel gevallen wordt een Agile transformatie gestart door management team van de IT afdeling. Er worden Scrum-teams samengesteld waarin verschillende disciplines samenkomen zoals business analyse, front-end development, back-end development en test management. Deze teams krijgen dan training, waarin ze bekend worden gemaakt met rituelen zoals Sprint Planning, Sprint Review, Retrospective en een Daily Stand-Up. Ook wordt er voor een tool gezorgd waar de Scrum-teams hun Sprints in kunnen plannen. En iemand die wel goed kan opschieten met een aantal managers in ‘de business’ wordt benoemd tot Product Owner. En de programmeur met grootste organisatorische vermogen wordt tot Scrum Master benoemd. Klaar! Toch?

Bij een dergelijke aanpak zal al snel blijken dat er nog aardig wat uitdagingen zijn.

Er is geen data waarmee gemeten kan worden of de productiviteit daadwerkelijk verhoogd is
Er is geen duidelijke aansluiting van strategie en executie (beperkt portfolio inzicht)
Teams hebben vaak onafgerond werk aan het eind van de sprints
Het duurt nog steeds lang voordat een verandering beschikbaar is voor de eindgebruiker

Hierdoor ontstaan weer extra problemen in de vorm van wantrouwen tussen management en de teams. En voor je het weet worden er rapportages gemaakt van de Story Points van teams om team performance te meten en te vergelijken. En product owners worden gevraagd om PowerPoint planningen en rapportages te maken, ook al hebben ze hun hele planning en roadmap al in Jira staan.

Wat er ontbreekt

Iedere organisatie en iedere transitie is natuurlijk anders. Maar toch zijn er veel voorkomende gebreken:

Team autonomie
Portfolio structuur in de planningstool (zoals Jira)
Holistische aanpak

Team autonomie

Een team heeft autonomie nodig om te kunnen versnellen. Autonomie betekent in deze context dat het team klantwaarde kan leveren zonder afhankelijkheden van buiten het team. Problemen die hierbij vaak voorkomen zijn:

De Product Owner heeft niet genoeg mandaat en is afhankelijk van besluitvorming van management
Het development team is afhankelijk van andere teams om een deel van de wijzigingen door te voeren om zo tezamen klantwaarde te leveren
Het team kan niet zelf testen en releasen waardoor changes niet naar productie kunnen binnen de sprint (of spoedig na de sprint)
Architectuur kent veel point-to-point integraties en laat geen autonome deployment toe; Er is geen Service Oriented Architecture (SOA) waardoor het naar productie brengen geblokkeerd is totdat aanhangende systemen zich op de aanstaande verandering hebben aangepast

⚠️ Opvattingen over team autonomie kunnen overigens ook te ver doorslaan; teams kunnen soms ‘vergeten’ dat ze werken binnen de context van een grotere organisatie, gedeelde doelen en afhankelijkheden.

Portfolio structuur in Jira

Na het invoeren van Scrum als vervanging van een traditionele projectmanagementmethodiek ontstaat over het algemeen een grotere transparantie. Vooral als er voor 1 aangewezen planningstool wordt gekozen waar alle teams hun backlog en sprints in beheren. Dan is er ineens gedetailleerd- en up-to-date inzicht in wat welke teams nu precies doen.

Maar hoe vind je tussen honderden Stories de rode draad? Hoe staat het nu met bepaalde initiatieven? Zetten we onze capaciteit nu wel in op de strategisch belangrijke themas?

Problemen die hier vaak spelen zijn:

Epics worden gebruikt als ‘categorieen’ zonder start en einde waardoor ze geen enkele informatiewaarde hebben in de context van het portfolio
Epics en Stories worden niet vanuit het klant-perspectief gedefinieerd waardoor ze niet herkenbaar zijn voor stakeholders.
Epics (Features) zijn niet te herleiden naar initiatieven of projecten.
Er worden geen roadmaps gemaakt om de lange termijn planning in de gaten te houden

Holistische aanpak

Om succesvol te zijn in een Agile transitie moet je zorgen dat de hele interne organisatie goed aansluit op de nieuwe manieren van werken. Hieronder een aantal voorbeelden van belangrijke onderwerpen die vaak over het hoofd gezien worden.

Financieel: vaak blijven organisaties werken met projectfinanciering. Maar die sluit niet meer goed aan bij de nieuwe werkwijze en voegen geen waarde meer toe. Verander daarom naar een financiering van (vaste) teams per capability. En schaf meteen het tijdschrijven af; tijd hoeft toch niet meer aan projecten toebedeeld te worden. Heroverweeg daarnaast ook of kosten voor deze Agile / DevOps teams als investering of als kosten gezien moeten worden.
HR: stabiele goed functionerende teams zijn van essentieel belang. Maar vaak is er geen groeipad binnen functies zoals programmeur. Hierdoor gaan deze vaak voor een managementpositie of verwisselen ze van werkgever om een stap te maken. Zorg ervoor dat ook een programmeur (veel) schalen kan groeien binnen deze functie. Vereenvoudig ook meteen het functiehuis zodat deze brede functies heeft voor de leden van de Agile teams en stimuleer de brede ontwikkeling van medewerkers.
Cultuur: een organisatie die wendbaar wil zijn, moet een lerende organisatie zijn. Een organisatie waar mensen de ruimte krijgen om zich te ontwikkelen en ook om fouten te maken (en daar van te leren). Ook moet er – ongeacht het formaat van de organisatie – een platte organisatie zijn. Niet allen in structuur, maar ook in cultuur. Iedereen moet benaderbaar zijn. En let op: dit zit ook in kleine dingen zoals het afschaffen van ‘dure functie titels’ als ‘senior vice president’; dit soort dingen vergroten juist afstand en verminderen benaderbaarheid.
Sourcing en inkoop: het offshore sources op basis van work orders kan een behoorlijke blokkade zijn voor een Agile transformatie. Ook het aankopen van grote software pakketten van starre leveranciers werken niet mee.

En dit is slechts een aantal voorbeelden. Het kan handig zijn om een model te gebruiken om te zorgen dat alle aspecten in overweging worden genomen. Zo kan bijvoorbeeld het 7-s model van McKinsey nuttig zijn om toe te passen op een Agile transformatie. Het meest belangrijke is dat kennishebbers van de verschillende functies worden betrokken in het verander-programma.

Hulp nodig?

Neem gerust eens contact op om te bespreken hoe we je kunnen helpen!

Maak kennis!

Meer dan Scrum: waar Agile transformaties vaak te kort komen