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?
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.