Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

De verborgen inefficiency van Agile

 

Computable Expert

Pa Va Ke
Configuration Management / Product Lifecycle Management, nvt. Expert van Computable voor de topics Development, Beheer en Zorg.

Eén van de kenmerken van agile-projectteams is dat ze 'self supporting' zijn. Het idee hierachter sprak me in eerste instantie heel erg aan, maar na enkele agile-projecten van dichtbij meegemaakt te hebben, zijn er toch vraagtekens gerezen bij de vermeende efficiency van deze teams. Het is maar net welke invalshoek je neemt.

Binnen een self supporting-team kiezen de teamleden onder andere zelf de ondersteunende middelen om daarmee zo snel en efficiënt mogelijk naar het eindresultaat toe te werken. Binnen de scope van hun project klinkt dit logischerwijs als zeer efficiënt. Maar wat nu als er meerdere agile-teams werken binnen je organisatie die op deze manier elk hun eigen gereedschapskist samenstellen?  Dit leidt al snel tot een potpourri van tools die hetzelfde doel dienen, zoals planning, digitale scrumboards, versie beheer, defect tracking  en programma’s voor continue test en integratie

Het wiel opnieuw uitvinden

Eén van de neveneffecten hiervan is dat ieder project afzonderlijk tegen alle uitdagingen aanloopt van het integreren van deze tools. Door de onderlinge verscheidenheid kunnen projecten  weinig van elkaar leren, waardoor het spreekwoordelijke wiel telkens weer opnieuw uitgevonden wordt.   Door met z’n allen nu dezelfde tools te gebruiken, kun je het integreren van deze tools centraliseren, waardoor (vanuit de organisatie gezien) je een stukje tijdswinst kunt behalen.

Vergelijkbaar hiermee is de tijd en energie die door de projecten verstookt wordt om deze tools te installeren, upgrades en patches te installeren en de daar uit volgende problemen weer op te lossen.  Door het kiezen van één toolset, en deze centraal te laten beheren kan ook op dit vlak tijdswinst behaald worden.

Alle wielen draaiende houden

Afhankelijk van je organisatie kan het winst-effect nog veel groter zijn. De agile-projecten leveren aan het eind van de rit producten op.  Heb je nu op deze producten een onderhoudsverplichting, hoe ga je dan de onderhoudsomgeving inrichten? Ga je de diverse ontwikkelomgevingen één op één overnemen? Wanneer je hier voor kiest, krijgt je onderhoudsomgeving niet alleen de software om te onderhouden, maar ook de eerder genoemde potpourri aan ontwikkeltools. Omdat de hoeveelheid producten in onderhoud het aantal producten in ontwikkeling al snel overschrijdt loopt de onderhoudsafdeling al snel het risico met een onbeheer(s)bare set aan ontwikkeltools te zitten.

Door te convergeren naar een standaard toolset wordt het leven van de onderhoudsafdeling een stuk makkelijker en hoeven ze niet alle 'wielen' die uitgevonden waren tijdens ontwikkeling draaiende te houden. Dit zou in mijn ogen nog moeten gebeuren onder de vlag van het project. Daar zit immers alle kennis van de gebruikte omgeving.

Maar .. zijn we dan nog wel agile?

Dit is een vraag die ieder voor zich mag beantwoorden en waarop ik graag jullie reacties tegemoet zie. In mijn ogen is het doel van het project een product opleveren, liefst op een snelle en efficiënte manier. Agile is een methodiek die hierbij kan helpen. En als het, door op sommige punten hiervan af te wijken, nog sneller kan, waarom zouden we dat dan niet doen?

Dit artikel is afkomstig van Channelweb.nl (https://www.channelweb.nl/artikel/4728437). © Jaarbeurs IT Media.

?

 

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.