Management

Software-ontwikkeling
Agile

Zo maak je agile teams effectiever

Het draait om de businesswaarde

24 mei 2017

Het draait om de businesswaarde

Agile is tegenwoordig dé manier om software te ontwikkelen. Het biedt in theorie veel voordelen, met name als het gaat om het vinden van aansluiting bij de business. De praktijk is echter weerbarstig. Vaak vallen Scrum-teams na verloop van tijd terug in oude gewoonten en worden de beloofde vruchten niet geplukt. Hoe kun je dit voorkomen?

Vrijwel iedere organisatie die software ontwikkelt, heeft in meer of mindere mate de overstap gemaakt van waterval naar agile. De aanleiding is over het algemeen het beter realiseren van businessdoelen:

• sneller software opleveren;

• de kosten van ontwikkeling en beheer verlagen;

• de kwaliteit van software verhogen;

• betere samenwerking tussen IT en business;

• hogere klanttevredenheid.

Gaandeweg raken deze businessdoelen echter vaak uit zicht. In veel teams draait Scrum meer om het toepassen van de werkwijze dan om de adoptie van het gedachtegoed. De implementatie is vaak een IT-feestje. De nadruk ligt op het goed toepassen van de spelregels van Scrum. De daily stand-ups vinden trouw plaats. Er worden een ScrumMaster en Product Owner benoemd, vaak zonder al te goed na te denken over hoe die rollen moeten worden ingevuld en of de personen wel écht gekwalificeerd zijn voor deze functie. En last but not least worden de sprintdeadlines heiligverklaard.

Business krijgt niet of nauwelijks tegengas van agile teams

Een spelregel die minder goed wordt toegepast, is de gelijkwaardige samenwerking met de business. De business heeft onvoldoende zicht op wat agile werken betekent en blijft zelf hangen in de ‘wij vragen en jullie draaien’-modus. De business heeft bovendien vaak onrealistische wensen, zeker wat de snelheid betreft waarmee producten moeten worden opgeleverd. Dat kun je de business niet eens kwalijk nemen, want hij krijgt niet of nauwelijks tegengas van de agile teams. Het resultaat is dat onder tijdsdruk wordt gemorreld aan de kwaliteit van software [zie kader]. Het resultaat: de business is ontevreden, want hij ziet dat het aantal incidenten in productie stijgt. En de tevredenheid van de agile teams is evenmin erg hoog. Zij voelen zich niet serieus genomen en bezwijken bijna onder de werkdruk.

Meten

Iedere goede manager weet dat de tevredenheid van een medewerker bepalend is voor het succes van zijn team. Dat hangt vaak samen met het vertrouwen dat medewerkers krijgen. Vertrouwen lijkt vaak een magisch iets dat nauwelijks valt te sturen, maar niets is minder waar. Meten is weten en dat is de basis om te verbeteren. Dat geldt voor harde factoren, maar ook voor zachte. Als het gaat om het functioneren van een team dan zijn er maar weinig mensen die kunnen aangeven op welke KPI’s je zou moeten sturen, en dat zijn de leden van het team zelf. Zij weten wat voor hen belangrijk is om goed te functioneren. Zij geven ook zelf aan wat voor hen een prettige manier is om onderling te communiceren, wat ze willen doen om de teamdynamiek en de betrokkenheid van medewerkers bij hun werk te vergroten.

Periodiek meten

Organisaties die volgens de Scrum-methode werken, zetten in het begin vaak agile coaches in. Die coaches helpen bij het implementeren van de methode en sturen daarom sterk op het proces: verloopt het volgens de spelregels van Scrum? De werkelijke waarde van agile zit in beter aansluiten bij de business. Dit proces vraagt tijd. Net als in een huwelijk zullen business en IT structureel aan hun relatie moeten werken. Met een agile monitor kun je periodiek meten, bijvoorbeeld eens per kwartaal, om vast te stellen of de dingen die je doet om de relatie te verbeteren ook hun vruchten afwerpen.

Met andere woorden: je meet de tevredenheid van de Scrum-teams dus niet met een standaardvragenlijst die is afgeleid van het jaarlijkse tevredenheidsonderzoek. Nee, de teams moeten zelf kunnen bepalen wat voor hen belangrijk is om prettig te kunnen (samen)werken. Zij moeten zelf de factoren kunnen verwoorden die zij belangrijk vinden in stellingen. Ieder team kan op de proppen komen met andere stellingen. Ieder team bestaat immers uit andere mensen, die anders met elkaar samenwerken. Dat is niet erg. Sterker, dat moet je juist faciliteren. Want zodra je iedereen in hetzelfde keurslijf propt, zal de tevredenheid direct dalen.

Het is niet de bedoeling elkaar af te vallen

De teamleden kunnen aan iedere stelling twee scores geven: een score voor dit moment en een gewenste score. Voor de ene medewerker is het bijvoorbeeld erg belangrijk dat hij privé goed met zijn collega’s kan opschieten, voor de ander is dat veel minder relevant. De gewenste score zal in dat laatste geval anders zijn. Mede omdat de score transparant beoordeeld moet worden, kan het bespreken van de resultaten de eerste keer wrijving opleveren, zeker in teams die nog sterk kunnen verbeteren. Dit is dan ook een proces dat je goed moet begeleiden. Het doel van deze exercitie is immers niet om elkaar af te vallen, maar om eerlijk tegen elkaar te zijn over de mogelijkheden tot verbetering.

Businesswaarde

Teamtevredenheid is een randvoorwaarde voor succes, maar het draait uiteindelijk natuurlijk om de businesswaarde die de agile teams genereren. De meeste teams denken daar nauwelijks over na. Ze blijven in hun eigen IT-wereldje hangen. Het is daarom ook niet vreemd dat die ongelijkwaardige relatie tussen IT en business is ontstaan.

Meeste teams blijven in eigen IT-wereldje hangen

Wil je dat doorbreken, dan moet je agile teams veel actiever laten meedenken over de manier waarop zij businesswaarde genereren. Die manier zouden zij kunnen verwoorden in stellingen die de basis vormen voor het onderzoek onder stakeholders in de business. Aan de hand van een compacte enquête kun je de business vragen hoe tevreden hij is met de producten die de agile teams opleveren, en met de samenwerking. Door de agile teams deze businessenquête zelf te laten samenstellen en af te stemmen, dwing je ze om uit hun eigen wereld te stappen en een visie te ontwikkelen op hun rol in het grotere geheel.

Natuurlijk kost het bedenken van stellingen voor het meten van teamtevredenheid en klanttevredenheid eenmalig veel tijd. Het voordeel is wel dat je daarna meet op dingen die er voor de teamleden toe doen. Je dwingt de teamleden ook om met elkaar in gesprek te gaan over wat voor hen belangrijk is. Alleen al dat gesprek is in veel teams van onschatbare waarde.

Dashboard

Wat levert deze werkwijze op? Inzicht in de vele verschillende factoren die van invloed zijn op het succes van agile teams. Het helpt je om een relatie te leggen tussen teamtevredenheid en het genereren van businesswaarde. Het geeft inzicht in de oorzaken waarom de businesswaarde nog niet op het gewenste niveau ligt. En het laat zien welke zaken betreffende het functioneren van het team hieraan ten grondslag liggen. Door dit inzichtelijk te maken in een dashboard waarin je kunt doorklikken tot op het niveau van de stelling of het teamlid, geef je het team knoppen om aan te draaien. Agile teams kunnen zo zelf vorm geven aan continuous improvement.

Technische schuld

Iedereen die werkt aan doelen voor de langere termijn zal moeten proberen om de verleidingen op korte termijn te weerstaan. Dat is zo als je wilt afvallen, als je aan het sparen bent voor een verbouwing van je huis en bij softwareontwikkeling.

Bij softwareontwikkeling zou de total cost of ownership (TCO) een belangrijke leidraad moeten zijn. Immers, meer dan 65 procent van de kosten van software zit in onderhoud en nog geen 10 procent in het ontwikkelen van de eerste versie. Wat zie je echter in de praktijk: de snelheid is vaak het belangrijkste argument. De business heeft haast. Hij vraagt een agile team een schatting te maken van de benodigde tijd. Een goede schatting maken kost tijd, het vraagt dat je vooraf een goede inschatting kunt maken van de complexiteit. Maar zelfs het afgeven van een tijdsplanning moet onder tijdsdruk gebeuren, dus het team steekt een natte vinger in de lucht en doet een ruwe schatting. Al snel blijkt dat die veel te optimistisch is omdat juist in het managen van die complexiteit veel tijd gaat zitten. Maar dan is het al te laat. Dan zijn de verwachtingen al geschapen en wil niemand daar nog afstand van doen.

Het vervolg is voorspelbaar: het team levert, zo goed en zo kwaad als het gaat, toch snel een minimal viable product (MVP) op. En ach, omdat het een MVP is, mag er best nog wat technical debt in zitten. Dat is (ontwikkel)werk dat later ontstaat doordat wordt gekozen voor oplossingen die op korte termijn weliswaar makkelijk te implementeren zijn, maar die op lange termijn moeilijk te onderhouden zijn. De business is enthousiast over het MVP en zet druk op de deadline waarop het naar productie moet. Het team krijgt de tijd niet om de technical debt weg te werken, met als resultaat een behoorlijk aantal incidenten in productie.

Het is een vicieuze cirkel waar je haast niet meer uitkomt, want niemand wil de investering doen om eerst al het achterstallige onderhoud weg te werken. Zo doe je op lange termijn dus afbreuk aan de businesswaarde.

Lees meer over
Lees meer over Management OP AG Intelligence
1
Reacties
Stanislaw Rutkowski 26 mei 2017 09:02

Het "Co-Creatie wiel" van CoCreata is een effectief en handzaam instrument om agile teams hierin te faciliteren.

Zie www.cocreata.nl 

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.