De afgelopen weken hebben bij mij voornamelijk de onderwerpen ‘Agile’ en ‘Standaardisering’ in de schijnwerpers gestaan. ‘Agile’, omdat de TestingExperience er een hele uitgave (sept. 2008, nr. 7) aan gewijd heeft en ik collegae heb die het onderwerp veel aanstippen. Standaardisering omdat ik nu eenmaal in een standaardiseringorgaan zit als actief lid en als zodanig er veel mee te maken heb.
Nu is natuurlijk een link snel gelegd en dan ga je denken over standaardisering binnen ‘Agile’ of zelfs ‘Agile standaardisering’ (kun je dat hebben?). Het viel mij op dat het bij veel collegae die ik spreek het ene onderwerp het andere eigenlijk al uitsluit, want blijkbaar is de perceptie dat standaardisering per definitie een ‘Agile’ project in de weg staat. Standaardisering wordt geassocieerd met traag, log en bureaucratisch terwijl ‘Agile’ juist voor snel, flexibel en non bureaucratisch te boek staat.
Verder lijkt men, uitzonderingen daargelaten, ook te denken dat ‘standaardisering’ (en mede daarmee ook ‘certificering’ en normering) een (hoge mate van) innovatie (of dit nu innovatie in programmeerwijzen of processen zijn) in de weg staat.
Ik zou hier niet wat over schrijven als ik niet een andere mening aangedaan was. Ik ervaar een hoge mate van vrijheid om te innoveren wanneer er gestandaardiseerd is; ik ben immers niet bezig met zorgen dat alles gelijk is en aansluit, maar kan tijd besteden aan nieuwe ideeën en het stimuleert mijn creativiteit om oplossingen te vinden die binnen de grenzen van een standaard vallen. Bovendien zijn standaarden er dan wel om standvastigheid te creëren, maar het verbiedt niet om verbeteringen aan te dragen. Standaarden en normen zijn net zo goed onderhevig aan ontwikkelingen als ieder ander product, voortschrijdend inzicht en innovatie kunnen net zo goed invloed hebben op een geaccepteerde standaard zodat deze evolueert tot een nieuwe versie of standaard. En dan de ‘Agile’ stuff; ook hier zie ik standaardisering niet als struikelblok. Ik denk dat de diversiteit binnen het ‘Agile’ gebied juist voor een vertraging zorgt, er moet immers eerst worden bepaald binnen welke grenzen alles wordt ontwikkeld, terwijl een standaard dat juist al duidelijk aangeeft zodat een ieder gelijk van start kan gaan en er over werkwijzen geen discussie kan ontstaan. Het gaat te ver om alle aspecten hier te behandelen, maar ik denk dat de bottomline wel duidelijk ik. Ik ben benieuwd hoe anderen hier over denken dus ik zie graag reacties tegemoet.
2 opmerkingen:
Ben het volledig met je eens. Een standaard kan erg goed als basis gebruikt worden en richtlijn en hoeft helemaal niet voor beperkingen te zorgen. Templates zijn er niet om naar de letter te volgen, maar te gebruiken naar inzicht van het project (bijvoorbeeld). Anders zou je bij elk agile project constant het wiel weer opnieuw uit aan het vinden zijn. Als maak je alleen al maar een standaard voor het proces (bv wie nemen er aan deel, wat zijn de te nemen stappen die telkens weer terug komen etc). Ofwel agile en standaarden kunnen heel goed samen als je ze de standaarden maar practisch toepast!
In feite bestaan er al standaarden voor agile projecten. Een voorbeeld hiervan is het toepassen van SCRUM. Een aantal zaken leg je vast (bijvoorbeeld dagelijks staand overleg van 15 minuten bij de koffieautomaat), maar ook wat er per Sprint ontwikkeld en getest gaat worden. Van een dergelijke aanpak kan vrij makkelijk een standaard gedestileerd worden, zonder daarbij in flexibiliteit in te hoeven boeten.
Uiteraard moet de standaard niet te veel vast gaan leggen om het flexibele karakter van een agile project te kunnen blijven garanderen, maar een organisatie kan er zeker baat bij hebben om de 'basisregels' van een agile project, toegepast op de organisatie, vast te leggen in een standaard. Dit bevordert de uitwisselbaarheid van de menskracht over verschillende agile projecten. Het vaststellen van een dergelijke standaard kan er vervolgens voor zorgen dat agile de standaard binnen een ontwikkel- of testafdeling wordt!
Een reactie posten