Verloedert de softwarekwaliteit bij een Agile aanpak?

De Agile literatuur erkent het belang van softwarekwaliteit. Want, kwaliteit is belangrijk om flexibel te kunnen doorontwikkelen en om veel ‘rework’ te voorkomen. Een mooie open deur, want kwaliteit vinden we allemaal belangrijk, en rework wil niemand. Maar hoe borg je softwarekwaliteit als de product owner uit de business prioriteert, terwijl hij geen IT-achtergrond heeft? Verloedert de kwaliteit van software bij een Agile aanpak?

Het normenkader voor het duiden van systeemkwaliteit is in de software het de ISO-norm 25010 (2011). De ISO-norm 25010 kent twee hoofdmodellen. Zij beschrijven de systeemkwaliteit in een reeks kenmerken; acht voor het model voor productkwaliteit en vijf kenmerken voor gebruikskwaliteit. Zes kenmerken voor productkwaliteit zijn ‘niet functionele eisen’; het aloude traditioneel specificeren. En hier zit ‘em nu net de kneep…

Haaks hierop lijkt het belang van de product owner. In zijn Agile scrum rol focust hij op direct waarde toevoegen voor de eindgebruikers. Mag van de product owner verwacht worden ook rekenschap te geven aan ‘niet functionele eisen’? Ja, is mijn antwoord hierop. Af en toe klankborden met een architect over dit onderwerp helpt daarbij. De product owner zal immers in de dagelijkse praktijk het sprintresultaat toetsen aan de Definition of Done (DoD). Dit impliceert dat softwarekwaliteit onderdeel is van de DoD. Zeker bij software waarbij doorontwikkeling voorzien is. De DoD bevat dus meer dan de eisen en wensen ten aanzien van functionaliteiten voor gebruikers.

Kan de ISO-norm 25010 hierbij worden toegepast binnen de Agile werkvorm om tot een kwalitatief hoogwaardig systeem te komen? Ja, in mijn ogen wel. De genoemde 13 kenmerken zijn prima controlepunten voor elk backlogitem voorafgaand aan de sprint, Definition of Ready (DoR). Ook kunnen de kenmerken uit de ISO-norm 25010 gebruikt worden om de Definition of Done te verfijnen. De teamleden hebben de norm als handvat om de product owner te vragen naar de ‘niet functionele eisen’. Uiteraard mogen de eisen op gebied van usability, één van de benoemde kenmerken, niet vergeten worden. Op beide momenten, voorafgaand (DoR) en bij oplevering van een sprint (DoD) zijn de kenmerken belangrijke controlepunten.

Verloedert de softwarekwaliteit bij een Agile aanpak? Nee, op het juiste moment met de ISO-norm 25010 in de hand borgt ook de kwaliteit van software in een Agile werkvorm. Op de keeper beschouwd is Agile werken niks anders dan kleine watervalletjes achter elkaar waarbij functionele ontwerpjes worden gemaakt. Daarmee is de kwaliteit van het eindproduct geborgd. Dat brengt mij op de visie dat de traditionele architectuuraanpak of “design before build” nog zo gek niet is, maar daarover in een volgende blog meer.

Maakt Scrum de Projectmanager écht overbodig?

Puur volgens de letter van Scrum als Agile-methodiek maakt de samenwerking tussen Product Owner en (scrum-)team de behoefte aan de klassieke Projectmanager overbodig.

Een Scrum Master en Product Owner zorgen samen met het scrumteam dat deze taak –net als bijvoorbeeld bij het ‘testen’– binnen het team wordt opgepakt. Directe interactie staat voor deze ‘zelforganiserende groep mensen’ centraal in hun onderlinge samenwerking en de afstemming met stakeholders in de naaste omgeving.

De Scrum Master begeleidt en faciliteert dit zelfsturende team dat werkt aan het realiseren van de resultaten en zorgt dat de scrumprocessen worden doorleefd zodat deze vorm van samenwerken ook daadwerkelijk bij zal dragen aan de gewenste doelen. Daarnaast helpt de Scrum Master ook de Product Owner die een enorme verantwoordelijkheid draagt als ‘gemandateerd opdrachtgever’ voor het op te leveren resultaat.
Als cruciale schakel tussen team en stakeholders is deze Product Owner verantwoordelijk voor de Product Backlog en het prioriteren van functionaliteiten om zo resultaten op te leveren die de meeste toegevoegde waarde bieden voor Business; gebruikers en eventueel ook klanten.

Is een Projectmanager dan écht overbodig?
Vanuit deze theorie geredeneerd ontstaat de neiging om hier instemmend op te antwoorden, maar helaas leert de praktijk dat dit niet altijd voldoende is voor het realiseren van de gewenste resultaten…
Afhankelijk van het type organisatie zijn andere aspecten van belang om deze beoogde verandering te laten slagen.

Klassieke, formele(re) organisaties hebben vanuit hun behoefte aan ‘beheersing’ veelal de voorkeur om veranderingen via watervalmethodieken (als Prince2) te realiseren. Toch zie je ook daar stilaan de behoefte ontstaan om wendbaarder (‘Agile’) te worden in deze immer veranderende wereld. Bij het zoeken naar een meer wendbare benadering zal een Projectmanager met kennis van Scrum en Agile van grote toegevoegde waarde zijn om de organisatorische transitie te begeleiden zónder het gewenste resultaat uit het oog te verliezen.
Concrete voorbeelden hiervan zijn dat de Projectmanager deze (nieuwe vorm van) samenwerking en verandering begeleid als een soort Scrum Coach of optreed als (gedelegeerd) Product Owner om de verschillende afdelingen binnen de Business samen tot één Product Backlog te laten komen en daarmee richting één resultaat te sturen.

In grote Agile omgevingen zie je dat er behoefte ontstaat aan het managen van samenhang tussen verschillende expertises en afhankelijkheden. Ondanks dat gestreefd wordt naar het reduceren van complexiteit en autonomie voor deze teams, lopen deze teams in de praktijk vaak aan tegen afhankelijkheden met andere scrumteams of beheerafdelingen (Operations). Waar een ‘scrum-of-scrums’ prima kan voldoen voor het afstemmen over algemenere afhankelijkheden, biedt een goede Projectmanager meerwaarde door het creëren van juiste focus en richting. Door het managen van deze afhankelijkheden richting alle stakeholders en het agenderen van de verschillende userstories bij de scrumteams op de juiste momenten, zorgt de Projectmanager dat zij in samenhang bijdragen aan het uiteindelijke doel. Belangrijkste uitdaging voor de Projectmanager is dat deze zich bewust moet zijn van een gefixeerd budget (teamgrootte) en vastgestelde tijd (aantal sprints) en dat de Opdrachtgever en andere stakeholders worden meegenomen in het prioriterenvan functionaliteiten en sturen op een flexibele scope.

Binnen IT valt op dat scrumteams al relatief snel wendbaar (Agile) zijn, maar het vaak langer duurt voor de Business goed aansluit op deze werkwijze. Waar een scrumteam denkt in incrementen (resultaten) binnen iteraties (sprints), mist de Business een zekere Agile-awareness en denken zij vaak nog in scope, mijlpalen, kosten en doorlooptijden…
Als Projectmanager zal je dan minder sturen op de dagelijkse activiteiten, maar méér aandacht moeten hebben voor (persoonlijke) interactie en het verbinden van deze verschillende zienswijzen. Focus ligt dan op het stroomlijnen van deze onderlinge samenwerking en het regisseren van de communicatie om alle stakeholders op juiste wijze te betrekken.

Concluderend kunnen we stellen dat de Projectmanager niet overbodig, maar juist nodig is!
Afhankelijk van het type organisatie kan en zal de invulling van deze rol situationeel anders zijn: de Agile Projectmanager moet wendbaar zijn om veranderingen in verschillende omgevingen op succesvolle wijze te kunnen begeleiden.

Lees meer over succesvol Agile besturen

Vijf Agile tips voor managers

Hoe kan ik mijn rol als manager in een Agile omgeving het beste invullen. Vijf tips om uw management rol in de Agile omgeving in te vullen.

‘Mijn ontwikkelteams zijn enthousiast over scrum, zelf worstel ik nog hoe ik de zelfsturende teams aanstuur.’

Is één van de vragen die ik in de praktijk hoor. Of:

‘Mijn directie wil dat ik meer Agile gebruik in mijn IT-afdeling, maar ik weet niet waarvoor dat noodzakelijk is en wat het mij brengt.’

Kies een duidelijke aanpak
Agile werken is er in vele vormen. De startpositie van elke organisaties is anders. Sommigen hebben een grote development afdeling, anderen een bijna green field. Weer anderen gaan insourcen. Het kennisniveau en de achtergrond van medewerkers zijn overal anders en de beschikbare technische hulpmiddelen verschillen. Daarnaast moet rekening worden gehouden met implementatie- en veranderkosten en letterlijk, met leergeld. Dat dwingt tot nadenken over een aanpak die binnen uw eigen organisatie goed kan werken, niet zomaar wat doen (lees hier de blog van Joop Rasser). Introductie van Agile werken is een leerproces. Kleine successen helpen om het onderlinge vertrouwen te kweken dat nodig is om moeilijkheden onderweg te kunnen overwinnen. Een dynamische roadmap op basis van een gemeenschappelijk raamwerk en een gemeenschappelijke taal helpen daarbij.

Stop uw energie in de goede mensen
Agile werken vraagt om flexibiliteit, zelfstandigheid en professionaliteit. De belangen van klanten en afnemers moeten voortdurend worden meegewogen bij het maken van keuzes en het nemen van besluiten. Als Agile werken ook gebruikt wordt voor de industrialisatie van softwareontwikkeling moeten medewerkers kunnen omgaan met soms routinematig werk binnen een beperkte scope. Hebt u mensen in huis die over al deze capaciteiten beschikken? Wilt u ervoor zorgen dat mensen die iets nog helemaal niet kunnen het een beetje gaan kunnen, of wilt u dat mensen die iets al kunnen het veel beter gaan doen? Maak een vlootschouw, en zorg voor een goed HR plan. Trek zo nodig frisse krachten aan voor sleutelrollen.

Zoek beheersing in vertrouwen en transparantie
Het is verleidelijk om direct te sturen op gedrag en werkzaamheden van uw medewerkers. Maar in een context van Agile werken is dat contra-productief. De eigen inzichten en professionaliteit van uw mensen zijn de belangrijkste hefbomen voor succes. Maak daar gebruik van. Een directieve manier van sturing past niet bij Agile werken. Laat dit dus los en geef uw mensen vertrouwen. Maar vraag daar transparantie voor terug! Zorg voor een manier van verantwoording waarbij transparantie ontstaat over de geleverde prestaties, in relatie tot het doel waar het om begonnen is: het leveren van toegevoegde waarde voor klanten.

Houd bij de uitvoering oog voor balans tussen functionele eisen voor de kortere termijn en technische eisen voor de langere termijn
Agile werken wordt gedreven door de wensen van de business. Maar soms zijn technische aanpassingen geboden die niet direct effect hebben voor de business, maar die wel noodzakelijk zijn voor de stabiliteit en continuïteit van systemen op termijn. De governance van Agile werken moet er in voorzien dat besluiten worden genomen waarin beide belangen herkenbaar en op een evenwichtige manier worden meegenomen.

Laat u niks wijsmaken!
Agile werken zorgt voor veel gespreksstof in uw omgeving. U zult misschien horen dat managers niet meer nodig zijn, en dat projecten in het Agile tijdperk volledig uit de tijd zijn. Agile bestaat inderdaad geruime tijd (lees hier mijn andere blog). Maar laat u niks wijsmaken! Agile werken heeft een aantal belangrijke voordelen. Door het werken in multidisciplinaire teams ontstaan korte lijnen en kan met bepaalde afhankelijkheden tussen werkzaamheden efficiënt worden omgegaan. Ook is er een directe koppeling met de meest belanghebbenden, die volledig worden betrokken bij het totale productieproces. Maar die voordelen gaan niet altijd op. Soms is Agile werken niet de oplossing, en zelfs bij Agile werken moet er stevig worden ge-managed. Het is om problemen te voorkomen nuttig dat u zich goed verdiept in de kenmerken van Agile werken en in de omstandigheden waarin deze aanpak optimaal tot zijn recht komt.

De architect is de onmisbare duizendpoot in een scrum team

Een van de principes van het Agile manifesto luidt: “The best architectures, requirements, and designs emerge from self-organizing teams”. Een architect zorgt voor verbinding in, en tussen, de zelfsturende teams. Maar ook voor commitment aan de vastgestelde architectuur principes en richtlijnen van de organisatie. In de praktijk wordt de rol van solution architect vaak vergeten in scrum teams, terwijl de rollen ‘ontwikkelaar’ en ‘tester’ wel expliciet worden benoemd. De rol van de solution architect is een essentiële en onmisbare rol binnen een Scrum team.

Bij Scrum heeft de product owner de rol om verbinding te maken met verschillende stakeholders. Dit zal hij voornamelijk doen vanuit zijn eigen functie vanuit de business. Daar zitten immers zijn roots en DNA. De verbindende factor op ICT-gebied en tussen de business en ICT, de architect, wordt in veel gevallen buiten het team gelaten. Hierdoor ontstaat er, geen tot weinig, interactie met andere scrum teams en/of te weinig interactie tussen business en ICT binnen de organisatie.

Het toevoegen van een solution architect aan een Scrum team loont altijd. Zeker in een Agile omgeving, aangezien wensen en prioriteringen mogen veranderen, maar wel impact hebben op de ontwikkeling van de informatievoorziening. Een solution architect kan snel de impact van de wijzigingen aangeven. Hierbij is het belangrijk om de solution architect de schakel te laten zijn tussen de bouwers van de oplossing, en de product owner.

Het toevoegen van een solution architect aan een Scrum team heeft verschillende voordelen. Zo kan deze architect, net als de business analist, functioneren als rechterhand van de product owner. Bijvoorbeeld bij het uitwerken van de product backlog items, zodat ze ‘ready for sprint’ zijn. Ook kan hij direct daarna de requirements uitwerken naar een technische oplossing. Hierdoor kan de product owner betere keuzes maken en beter prioriteren.

Een ander voordeel is dat de solution architect door het maken van architecturen vooruit werkt op het team. Van hem wordt verwacht dat er ‘just enough’ design wordt gemaakt voorafgaand aan de sprint. In dit design worden bijvoorbeeld keuzes gemaakt als: Wat voor type applicatie wordt er ontwikkeld, een web app, mobile app of werkplek app? Daarnaast zal de solution architect altijd kiezen voor software en applicaties die al door de organisatie gebruikt worden. Hierdoor zal het team ook voldoen aan de door de organisatie vastgestelde architectuurprincipes en richtlijnen.

Naast het maken van keuzes is de solution architect ook de kwaliteitsmanager voor het team. Hij is de inhoudelijk vraagbaak voor het team, en zet de lijnen uit voor de verwachtte kwaliteit. Denk hierbij aan de verwachte methode van het vastleggen van code, het voorschrijven van best-practices voor het opstellen van code en het veelvuldig en gecoördineerd testen van nieuwe programmatuur.

Al met al voegt een solution architect meer waarde toe, dan men in eerste instantie zou verwachten. De vraag moet dan ook niet zijn of architecten in een Scrum ontwikkeling betrokken moeten worden, maar hoe.

Succesvol Agile Besturen

Veel organisaties doen maar wat bij de besturing van Agile/SCRUM projecten!

Veel organisaties nemen een toevlucht tot nieuwe ontwikkelmethodieken zoals agile/SCRUM om de slagingskans van hun projecten te vergroten. Bijzonder hierbij is dat de keuze voor een dergelijke ontwikkelmethodiek voorbijgaat aan de identiteit van de organisatie en de karakteristieken van de te volgen ontwikkelmethode. VKA ervaart dat de keuze voor een methodiek vaak platvloers tot stand komt, namelijk ‘omdat andere organisaties ook met agile/SCRUM werken’ of omdat ‘we dat al jaren zo doen’. VKA ziet dat beslissers te gemakkelijk voorbijgegaan aan de karakteristieken en de waarden van de eigen organisatie in relatie tot de gekozen ontwikkelmethode. Oftewel wie zijn wij als organisatie, hoe zijn wij georganiseerd, hoe besturen we onze medewerkers, etc. Het is van belang om de projectmanagement methodiek goed te laten aansluiten bij uw ondernemingsmodel en hierover expliciet te communiceren. Ook bij uw organisatie ligt er ruimte voor verbetering!

Aan de hand van de karakteristieken van twee stereotype ondernemingsmodellen[1] beschrijf ik dit fenomeen in meer detail. Ik gebruik hiervoor het Rijnlandsmodel en het Angelsaksische model. Het Rijnlandsmodel legt de nadruk op het middellange- en langetermijndenken, waarbij continuïteit van de onderneming belangrijker is dan het nemen van een snelle kortetermijnwinst. In het Angelsaksische model staan liberale waarden als zelfredzaamheid, particulier initiatief, marktwerking, vrijheid en een beperkte sociale zekerheid centraal. In onderstaande tabellen projecteer ik de karakteristieken van deze modellen op die van de twee meest voorkomende ontwikkelmethoden, namelijk waterval en Agile/SCRUM. Ik wil hierbij aangeven dat deze projectie geen uitspraak doet over het al dan niet kunnen toepassen van een van deze projectmethoden in een organisatie.

Een organisatie met karakteristieken volgens het Rijnlandsmodel kan even goed de projectmethode Agile/SCRUM als waterval toepassen. Ik constateer dat er op het gebied van organisatie een duidelijke aandachtsgebied ontstaat indien deze organisatie volgens de projectmethode waterval wil werken. Medewerkers die een platte organisatie gewend zijn met korte communicatie lijnen komen terecht in een meer hiërarchische projectorganisatie waarbij het takenpakket van de betrokken teams, werkgroepen en stuurgroep duidelijk zijn afgebakend. Als projectmanager dien ik hier rekening mee te houden door de medewerkers hierop te coachen.

Aan de hand van bovenstaande tabellen blijkt dat de eigen identiteit, cultuur en waarden van een organisatie duidelijke consequenties heeft en een rol speelt in de te kiezen projectmethode. Al was het alleen maar om duidelijk te maken op welke aandachtsgebieden coaching en begeleiding van de medewerkers nodig is wil de projectmethode slagen!Hetzelfde geldt voor Angelsaksisch georiënteerde organisaties. Wanneer deze organisatie besluit te werken volgens de ontwikkelmethode agile/SCRUM ontstaat er een duidelijk aandachtsgebied betreffende sturing. Immers de medewerkers die van oudsher werden afgerekend op individueel succes zullen nu ineens moeten samenwerken in zelfsturende teams. Ook hier dien ik als projectmanager de medewerkers te coachen op de gewenste werkvorm.

Naar Mathieu Weggeman

Verdonck, Klooster & Associates

Tag: Scrum