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

De verborgen inefficiency van Agile

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 Computable.nl (https://www.computable.nl/artikel/4728437). © Jaarbeurs IT Media.
?

 

Reacties

Mijn ervaring is dat er al vrij snel standaard tooling wordt gebruikt over verschillende projecten zodat je geen wildgroei krijgt. Vaak zie je dat mensen tussen projecten uitgewisseld worden, en zodoende is er vaak toch wel een gemeenschappelijke doos met tooling die iedereen beheerst.

Je zoekt programmamanagement voor Agile projecten. Daarin kan je vast wel een standaard toolset voorschrijven. Als programmamanager kun je nu eenmaal wat minder Agile zijn.
In het Agile manifesto (denk er trompetgeschal bij) wordt wat rechts staat vermeld niet afgewezen. Letterlijk :
"That is, while there is value in the items on
the right, we value the items on the left more."

Ikzelf ben niet bekent met een agile methode die letterlijk voorschrijft dat het team ook geheel zelf bepaalt welke tools zij gebruikt. Misschien dat dit afgeleid kan worden uit de diverse principes. Maar kijkend naar hoe we 'agility' meestal definiëren, zie 't manifesto, dient een team zich m.i. ook aan te kunnen passen of schikken naar de omstandigheden. De 'werkende software' moet vaak intergreren of 'praten' met andere applicaties c.q. software en dat houdt nu eenmaal in dat er eisen aan worden gesteld aan infrastructuur, incl. tooling. Dus ik ben het wel eens met je conclusie dat aanpassen om dingen efficiënter en sneller te doen goed is. Dat is overigens ook heel erg 'agile' ;)

Het probleem van de vele ontwikkeltools staat m.i. los van het toepassen van agile principes (om het even welke methode). Dit herken ik al van 'tig jaar geleden. Wat uiteindelijk tot dezelfde onderhoudsproblematiek leidt. Het is een issue wat m.i. juist door het toepassen van agile principes sneller duidelijk wordt. De productie van softwareproducten gaat omhoog, incl. gebruikte tooling, etc. en beheer/ onderhoud kan het niet meer bijbenen. Niet voor niets is er momenteel een ontwikkeling gaande onder de noemer 'DevOps' om het onderscheid tussen ontwikkeling/ beheer te laten vallen. Houdt het bij één team die alle kennis heeft.

Je kan ook zeggen dat door te kiezen voor een flexibele, schaalbare architectuur met vaste tools en andere applicaties, een agile team zich niet meer druk hoeft te maken om tooling e.d. En dus zich volledig kan uitleven op het leveren van een werkende oplossing binnen de door de organisatie gestelde grenzen. Wanneer blijkt dat deze grenzen daadwerkelijk het vermogen om passende oplossingen te leveren, de snelheid en efficiency aantasten, wordt het tijd om deze bij te stellen (in de vorm van herziene architectuur, tools, etc.). Alleen hebben volgens mij nog veel organisaties grote moeite om alleen al dit voor elkaar te krijgen...

@Peter V: mijn verwachting is ook wel dat het die kant op zal gaan op termijn, maar op dit moment zie ik meer divergentie dan convergentie. Heeft wellicht ook te maken met de grootte van de organisatie en de diversiteit in projecten

@mauwerd: we hebben een standaard toolset beschikbaar, maar de praktijk leert dat de projecten allemaal wat anders willen. Daar helpt programmamanagement weinig aan helaas

Ik ben dezelfde mening toegedaan als Pa Va Ke in deze. Meer nog omdat Agile als methodiek in een IT wereld te vrijblijvens is. Veel tijd en inzet gaat er verloren naar het 'tunen' en het 'zoeken naar ....' voordat men eindelijk eens op stook weet te komen.

Binnen een lineaire materie zoals IT, die in essentie nooit veranderd, heb je waarden nodig voor je uberhaupt een stap kunt zetten. wat die waarde toegekent dan ook moge zijn.

De fouten die menig maal worden gemaakt is dat plan, visie, idee, proces en projecten daardoor teveel onbekende factoren tegemoet zal zien waardoor je voorspelbaar tegen zaken aan zult lopen, in negatieve zin.

IT is een voorspelbare lineaire materie waar je met dezelfde voorspelbaarheid mee om moet gaan. Vanuit die hoedanigheid knik ik ja als er gesteld word dat Agile voor mij zeker niet de meest geëigende methode is te gebruiken binnen automatiserings trajecten of processen.

@PaVake Als het nu zo uit de klauwen loopt met gebruikte tools en iedereen maar wat doet dan zou je toch zeggen dat het probleem ergens anders ligt? Dan heeft een organisatie zijn zaken niet op orde. Mag duidelijk zijn, ik zou dat hele scrum/lean/kaban etc meteen afschaffen en al die overbodige rollen opdoeken. Scheelt je geld en een hoop gekwek, gewoon de essentiele rollen die bij een IT project hoort. De rest is onzin. Kan je ook prima Agile werken.

@PaVaKe Interessante eerste blog van je, complimenten! Belangrijk topic wat je stevig neer zet, smaakt naar meer :-)

Het probleem wat je schetst is inderdaad iets waar (veelal grotere) organisaties mee worstelen. Ook al voor dat ze agile gebruikten, ik heb diverse programma's meegemaakt om het aantal in gebruik zijnde tools te verminderen.

Projecten, teams en ook organisaties zijn minder anders dan dat men vaak beweert, en het zou goed zijn als we wielen meer gaan gebruiken om mee te rijden in plaats van ze telkens opnieuw uit te vinden. Dat vereist dan wel dat teams van elkaar kunnen en mogen leren, en zaken kunnen hergebruiken. Daar is niet altijd ruimte voor in organisaties. Soms is er de ruimte wel, maar wordt die te weinig benut.

Agile zijn met (deels) dezelfde tools, het lijkt mij dat dat mogelijk is. En als een team echt problemen heeft met een bepaald tool, is de kans groot dat ze niet de enige zijn die daar last van heeft. Maar ga dan niet een nieuw wiel uitvinden, maar pas de al draaidende wielen aan, zodat alles nog soepeler en sneller gaat lopen :-)

Het hele verhaal, en ook een groot deel van de reacties (waarvoor dank!) past denk ik goed binnen de golfbeweging die je in ontwikkeling ziet

van centraal naar decentraal gemanagede omgeving, van lange termijnstrategie (hoe ga ik op dit project nog 10 jaar onderhoud doen) naar korte termijnstrategie (zo snel mogelijk naar de markt), van flexibelit (agile) naar over-processed et cetera.


Door bijvoorbeeld invoering van Agile willen sommigen rigoreus "breken" met alles wat men daarvoor deed. De uitdaging is mijns inziens vooral om "the best of both worlds" te combineren, alleen dan kom je er sterker uit.

Ik ben het met PaVaKe eens dat Agile/Scrum implementatie nogal eens aangepakt wordt om het compleet anders te doen. Daarom mag de implementatie van Agile/Scrum geen doel op zich zijn, maar moet een middel zijn in het bereiken van iets anders, dat kan divers zijn: hogere kwaliteit, kortere time to market, etc. Dat hogere doel mag niet in gevaar komen door bepaalde vrijheden die ontwikkelteams menen te mogen nemen.

@PaVaKe: Ik zag ineens een fotootje bij je naam en toen pas je artikel en dus het verband :-)

Goed eerste artikel, smaakt inderdaad naar meer. Relevant, prikkelend en onderbouwd.

Paar gedachten:
- De tools om iets te bouwen zijn toch anders dan de tools om iets te beheren? De taal veranderd toch niet? Noch de conventies.

- Bouwen (Build) is iets anders dan draaien (Run). Ik ben een aanhanger van (John) Gall's law: A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

En daarmee ben ik dus een fan van Agile.

zelf zie ik niet zo het nadeel van verschillende tools. Wel van verschillende technologieën of programmeertalen. Integratie en de voorwaarden daaraan staan in mijn ogen los van de methodiek van ontwikkelen. Als er inefficiëntie optreedt wijdt ik dat eerder aan de mens dan aan de methodiek. Dit is echter opinie :-)

Wel tof dat je hier schrijft! Ik hou me aanbevolen.

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.

Computable Expert
Pa  Va Ke

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

Vacatures

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

×
×