In onze zoektocht naar excellente professionaliteit in softwareontwikkeling gaan we dieper in op de fundamentele principes die het verschil maken in onze aanpak. Deze principes vormen het DNA van professionele ontwikkeling en dragen bij aan het opschalen van de agility van teams naar de hele organisatie. Op basis van een serie van slogans die door een ontwikkelteam kunnen worden gehanteerd, onderzoeken we hoe de professionaliteit binnen de ontwikkelteams kunnen bijdragen aan het creëren van enterprise agility. In dit artikel kijken we naar het effect om eerlijk en transparant te zijn in alles wat we als ontwikkelteam doen.
Ontwikkelteams staan onder constante druk om aan de vele eisen en wensen van de organisatie te voldoen. Prioriteiten wijzigen en terwijl we druk aan het werk zijn om een feature af te ronden, worden we gevraagd om in te schatten wanneer nieuwe features kunnen worden opgeleverd. Het maken van een goede inschatting is lastig, zeker wanneer de eerste reactie is of dit niet sneller zou kunnen. Het lijkt er op dat, hoe meer transparant we zijn, hoe hoger de druk wordt om ook binnen de gestelde tijd te gaan leveren. En dat elke schatting die we maken, wordt gezien als een startpunt om te onderhandelen. Toch zijn eerlijkheid in wat kunnen en transparantie in wat we doen, essentieel om effectief te kunnen werken binnen enterprise agility.
Het maken van goede inschattingen is, zeker binnen software ontwikkeling, een vakgebied op zichzelf. Eind jaren 70 ontstond function point analysis (FPA) om op basis van specificaties een gefundeerde inschatting te kunnen maken van de complexiteit van het te ontwikkelen systeem, om vervolgens, op basis van de productiviteit in de gehanteerde ontwikkelomgeving, een inschatting te maken van de doorlooptijd. In de jaren hierna zijn verschillende andere calculatiemethoden ontstaan om tot betere inschattingen te komen en steeds beter te kunnen voorspellen wanneer beoogde functionaliteit kan worden geleverd. De basis voor dergelijke calculatiemethoden staat, zeker in de context van enterprise agility, vaak onder druk omdat de noodzakelijke specificaties om effectief te kunnen calculeren slechts beperkt en vaak pas later in het ontwikkeltraject worden opgesteld.
Binnen enterprise agility wordt daarom vaak het principe van relatief schatten gehanteerd. Het relatief schatten is gebaseerd op een aantal kernprincipes. Het gemiddelde van een groep van individuele inschattingen blijkt beter te zijn dan een enkele inschatting. Als mensen zijn we beter in staat om kleinere, overzichtelijke dingen in te schatten dan grotere dingen. Schattingen worden beter wanneer we niet een specifieke inschattingen maken, maar wanneer we een bandbreedte hanteren van de mate van inspanning. En we zijn beter in staat om dingen ten opzichte van elkaar in te schatten, dan wanneer we deze afzonderlijk moeten inschatten. Het relatief schatten maakt gebruik van al deze kernprincipes, en geeft – wanneer deze goed wordt uitgevoerd – een reëel beeld van de mate van inspanning. De opzet en werking van relatief schatten is eerder uitgelegd in het artikel “Het verhogen van de voorspelbaarheid van het portfolioproces”.
“Honest estimates”
Om goede inschattingen te maken is het van essentieel belang dat we, als ontwikkelteam, eerlijk moeten zijn in en over de inschattingen die we maken. Zeker wanneer externe deelnemers aanwezig zijn bij de inschatting, ontstaat nog wel eens de druk om positiever te worden over de mate van inspanning die een nieuwe feature vereist. Wanneer we hier in meegaan, moeten we ons realiseren dat we mogelijk de confrontatie op korte termijn voorkomen, maar op de middellange termijn de verwachtingen niet waar kunnen maken. En wanneer we niet aan deze verwachtingen kunnen voldoen, is het wachten tot interventies vanuit de organisaties worden uitgevoerd.
Daarom moeten we onszelf scherp houden op het maken van eerlijke inschattingen. Door zowel te kijken naar de complexiteit van de gevraagde feature als de verwachte inspanning, moeten we de meest waarschijnlijke bandbreedte selecteren. Door het verfijnen van de acceptatiecriteria kan de bandbreedte verder worden aangescherpt. Het bieden van meer transparantie over wat de organisatie kan verwachten, helpt om meer eerlijk te kunnen zijn over de mate van inspanning die hiervoor noodzakelijk is. Hierbij moet zowel het overschatten als het onderschatten van de mate van inspanning worden voorkomen.
Wanneer eerlijke (relatieve) inschattingen worden gehanteerd, kan de cone of uncertainty (zie afbeelding) worden gebruikt om transparantie te geven in welke periode een gewenste feature opgeleverd zou kunnen worden. Het is nu aan de ontvanger van de inschatting of deze aan de meer optimistische zijde van de bandbreedte wil zitten (en dus meer risico loopt dat de feature niet tijdig wordt afgerond) of juist meer aan de pessimistische zijde (en een hogere waarschijnlijkheid heeft dat de feature tijdig wordt opgeleverd. Daarbij kunnen we direct de consequenties laten zien wanneer de prioriteiten op de backlog over verloop van tijd veranderen.
“Saying no”
Van professionele ontwikkelteams wordt ook verwacht dat zij ‘nee’ zeggen tegen onrealistische verwachtingen of deadlines, of wanneer zij bijvoorbeeld gevraagd worden een feature sneller af te ronden ten koste van de kwaliteit. Zoals we in eerdere artikelen hebben aangegeven, ligt de verantwoordelijkheid voor een goede codebase in de handen van het ontwikkelteam. Wanneer we bezwijken onder de druk van de organisatie om aan onrealistische verwachtingen te voldoen, ontstaat alleen nog maar meer druk bij toekomstige deadlines. En, door de quick fixes, neemt de productiviteit al snel meer af. De schuld ligt hier niet bij de organisatie, maar bij het ontwikkelteam dat gefaald heeft om duidelijk ‘nee’ te zeggen tegen deze onrealistische verwachting.
Het zeggen van ‘nee’ is één ding, maar natuurlijk wordt wel verwacht dat we meedenken met de stakeholders over het probleem. Het accepteren van onrealistische verwachtingen behoort niet tot de mogelijkheden, maar wel kunnen we proactief meedenken om het probleem op te lossen. Is het mogelijk dat we scope van een gewenste feature reduceren? Is het mogelijk dat we een vereenvoudigde (tussen)oplossing creëren? Biedt de techniek mogelijkheden om het probleem op een alternatieve wijze op te lossen? Door actief mee te denken en met oplossingen te komen, ontstaat een gesprek over de mogelijkheden in plaats van de onmogelijkheden.
“We adhere to the DoD”
Om eerlijk en transparant te zijn in wat we doen, maken veel ontwikkelteams gebruik van een Definition of Done (DoD). Dit is een formele beschrijving van de staat van het product wanneer het voldoet aan de kwaliteitsmaatregelen die noodzakelijk zijn voor het product. Onderdeel van de kwaliteitsmaatregelen betreffen niet alleen het product zelf, maar vaak ook de processen rondom het voortbrengen van het product, zoals bijvoorbeeld het vastleggen van testbewijs, architecturele toetsing, etc.
Als ontwikkelteam is een gewenste feature pas gereed, wanneer het product als geheel voldoet aan de opgestelde DoD. Wanneer we hier, vaak weer onder druk van het opleveren, van af gaan wijken ontstaat intransparantie over de kwaliteit van het product en zijn we niet eerlijk over wat we kunnen doen. Dit heeft niet alleen consequenties voor de komende iteraties (want daarin moeten we nog werk doen om het product weer aan de DoD te kunnen laten voldoen, maar schept ook een verwachting van een hogere productiviteit dan echt kan worden gehaald. Wanneer we op basis van deze intransparantie en oneerlijke productiviteit gaan forecasten, ontstaat als vanzelf een negatieve spiraal waarin verwachtingen op middellange termijn niet meer gehaald kunnen worden.
“Fail fast, improve quick”
Wanneer we eerlijk en transparant zijn in wat we doen, moeten we niet schuwen om fouten te erkennen. Alleen door snel te falen, zijn we immers in staat om snel te verbeteren. Toch lijkt het alsof er een schaduw ligt over erkennen van fouten die we hebben gemaakt. Het is daarom belangrijk om continu eerlijk te zijn over waar we tegen aan lopen en borgen dat we niet alleen individueel, maar juist als team kunnen leren van dergelijke fouten. Inzicht krijgen in wat niet werkt, geeft juist ruimte om mogelijkheden te zoeken die wel werken.
Dit is niet alleen essentieel binnen het ontwikkelteam, maar juist ook in de gehele voortbrengingsketen. Ook voor de gebruikers is het essentieel om zo snel mogelijk te constateren dat een gevraagde feature in de praktijk niet het gewenste effect blijkt te hebben. Door korte communicatielijnen tussen de gebruikers en het ontwikkelteam kan dan worden gekeken naar betere alternatieven, waarmee het probleem kan worden opgelost.
“Manage expectations”
In omgevingen die continu aan verandering onderhevig zijn, is het van cruciaal belang om de verwachtingen te managen. Wanneer de prioriteiten op de product backlog verschuiven, moeten we dit zo snel als mogelijk communiceren aan alle stakeholders. Ondanks dat de prioriteit hierbij ligt bij degene voor wie de deadline naar achteren verschuift, moeten we ook zorgen dragen dat de personen voor wie de opleverdata eerder komt te liggen hiervan op de hoogte zijn. Alleen dan kunnen zij ook optimaal gebruik maken van de outcome wanneer deze ter beschikking komt.
De verwachting kunnen vaak niet of pas te laat worden gemanaged, wanneer ontwikkelteams niet transparant zijn over waar ze tegenaan lopen. Te vaak wordt gehoopt dat een ontstaan probleem nog tijdig kan worden opgelost, zonder dit te communiceren met de stakeholders. Wanneer de feature dan toch niet kan worden afgerond, staat de organistaie inmiddels voor een fait accompi. Zij hebben nu geen tijd meer om risicomitigerende maatregelen te nemen en kunnen niets anders dan de schuld bij het ontwikkelteam neerleggen. Door tijdig de verwachtingen te managen zijn we niet alleen eerlijk tegen onszelf, maar ook transparant naar de organisatie over wat zij wel en niet van ons kunnen verwachten.
Samenvatting
Het vermogen om projecten effectief te plannen, organiseren en uit te voeren is essentieel voor een succesvolle software-ontwikkeling. In een dynamische omgeving kan dit alleen wanneer we eerlijk en transparant zijn in wat we willen en kunnen doen. Dit betekent dat we eerlijk moeten zijn over de schattingen die we maken, nee moeten zeggen tegen onrealistische verwachtingen en snel moeten kunnen leren van fouten die we maken. Als we dan toch tegen onverwachte zaken aanlopen is het essentieel dat we de verwachtingen goed en tijdig managen, zodat de stakeholders en gebruikers tijd en ruimte hebben om eventuele afhankelijkheden goed te kunnen organiseren.
Bent u geïnteresseerd in meer essentiële aspecten om enterprise agility effectief in uw organisatie in te richten, kijk dan ook eens naar onze boeken “Enterprise Agility – een effectieve transformatie op basis van principes en practices” en “Enterprise Agility – pocketguide”.
Agile Aware 