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?
Wat mij betreft zijn de opgesomde problemen nou niet echt Agile specifiek. Oftewel de Wet van Behoud van Ellende. Als je nou eenmaal een groot project hebt waarbij de eilandjes van elkaar afdrijven staat m.i. los van Agile.
Daar heeft bijv een Waterfall methode dan toch meer last van omdat je de die tussentijdse ijkpunten niet hebt of problemen met de mantel der liefde bedekt worden.
Bij dat soort problemen laat je de technische leiders per eiland samen uit een gezamelijke standaard komen met afspraken wat de uitzonderingen zijn en je gaat per eiland mensen roeleren zodat ze wat verder mogen kijken dan hun eilandje lang is.
Pa Va Ke
Jawel, de eerste opinie is een feit!
Alle methodieken ten spijt begrijp ik niet helemaal wat nu het probleem is want bugs moeten natuurlijk opgelost worden maar het lijkt me niet handig om daarvoor alles in debug mode te draaien. Dat er inefficiëntie kan ontstaan als je meerdere versies moet onderhouden is wel begrijpelijk. Toen jaren geleden object-oriented programming populair werd had ik al het idee dat we gingen knikkeren maar ik weet niet of hier nu bedoeld wordt dat iedereen zijn eigen knikkers meeneemt of alleen de knikkerzak.
De geschetste problemen hoeven niet agile specifiek te zijn, maar agile wordt vaak aangegrepen als vrijbrief om niet meer aan de regeltjes van de beheersorganisatie te hoeven voldoen. Immers, het team is self-supporting…..
In hoeverre dit een probleem is hangt sterk af van de sector. Voor een bedrijf dat apps maakt of op een devops manier aan het werken is zal de impact heel anders zijn dan een bedrijf dat complexe systemen maakt met een levensduur / onderhoudsverplichting van 10 jaar of meer.
@Pa Va Ke
Zoals je beschrijft maken in jouw werkomgeving projecten zo ongeveer zelf de dienst uit. Inderdaad, dan helpt programmamagement ook niet meer. Dat lijkt me echter niet de schuld van Agile. In Agile projecten bepaalt de product owner wat er gedaan moet worden uit naam van de business. In jouw geval is gebruik van die tooling waar je over hebt, gewoon deel van de requirements die de product owner zou moeten bewaken. Scrummaster en team hebben dat maar te accepteren.
Als de business dat niet begrijpt of niet wil sturen, is dat niet een verborgen inefficiency van Agile. Jij schrijft er bijvoorbeeld over, niet verborgen dus.
Kan natuurlijk zijn dat Scrummaster en team zeggen dat ze zo niet kunnen werken, want niet Agile genoeg. Dan moet de business de Agile methodiek als oplossing voor hun bedrijf verwerpen. Agile stelt ook nergens dat het in elke situatie de meest geschikte manier van projectmanagement en/of softwareontwikkeling is.
@PaVaKe
Ik brom van instemming. IT-architecten zouden dit wat mij betreft moeten bewaken. Die moeten niet alleen bepalen wat je moet maken, hoe je het zou moeten maken, maar ook waarmee.
Uitstekend artikel! Voorbeeld voor de anderen.
PaVaKe,
Een duidelijk opiniestuk dat ik volledig kan onderschrijven.
Het lijkt erop dat je hier nog een ander centraal probleem met agile aan de orde stelt, namelijk de combinatie van agile met architectuur. Daarmee sluit je opinie perfect aan bij het onlangs verschenen “Architectuur kan ook agile zijn”; waar we dan naar toe willen is “Agile kan ook onder architectuur”!
De eilandautomatisering die het gevolg lijkt van agile ontwikkelen (ieder probleem z’n systeem) lijkt hand in hand te gaan met “een potpourri aan ondersteunende tools” (ofwel: iedere fool z’n tool).
Je pleidooi voor convergentie naar een standaard toolset is dan to the point en urgent.
Onder architectuur werkend zouden de onderhoudsafdelingen – uitgesmeerd over een breed scala aan applicaties en platformen – dezelfde tools moeten gebruiken als de agile ontwikkelafdelingen!
Voorbeeld: aan het eind van de rit zou een agile testteam een volledig geautomatiseerde regressietest voor de nieuw ontwikkelde functionaliteit dienen op te leveren, waarmee de onderhoudsafdeling direct uit de voeten kan. Want: tijdens de ontwikkelingsfase moest dit team ook qua testtooling toch als samenwerken met de onderhoudsafdeling; dat is nu juist inherent aan werken onder architectuur.
Kortom: je hebt een testtool nodig die de samenwerking tussen technische testers, functionele testers en agile (liever nog: business) testers optimaal ondersteunt en mogelijk maakt (een soort TestFrame Next). Het mag dan ook niet verbazen dat sommige bedrijven inmiddels een architect testautomatisering in het leven hebben geroepen.
Waar we naar toe gaan is dus: agile onder architectuur, een “best of both worlds’ waar jij in een reactie ook al voor opteerde.