Agile scrum is gewoon oude wijn in nieuwe zakken. Alsof we in de 90’er jaren niet begrepen hoe de toen chaotische software ontwikkeling moesten structureren. Op basis van bewezen principes uit de bouw en industrie, hebben we toen immers voor software ontwikkeling hele duidelijke fasen bedacht: requirement fase , systeemontwerp, implementatie, testen, uitrollen en onderhouden. En alles netjes gedocumenteerd met normalisatie diagrammen in standaard documentatie, zoals het requirements understanding document (RUD), het high-level design document (HDD), enz. Je wist precies waar je aan toe was met Prince2 of PMI.
Met Agile Intermezzo wordt deze blog gelardeerd met bijdrages van 5 minuten over agile werken. Vlug, behendig, wendbaar of zelfs fit zou je een agile organisatie kunnen noemen. In mijn dagelijkse praktijk zou ik de agile werkwijze vooral als levendig willen omschrijven, want leiding geven aan agile teams betekent voor mij never a dull moment en het is vooral erg leerzaam om te werken met agile professionals.
René Jansen
Digital productmanager en agileistIk richt mij tot de critici van agile scrum: je argwaan naar de agile apostelen is terecht. Alsof software ontwikkeling en onderhoud van software nog maar pas is uitgevonden. We hebben immers de ITIL processen om kwaliteit te garanderen, nietwaar?
Agile is inferieur aan traditionele software voortbrenging:
1. Omdat eindresultaten vooraf volledig moeten zijn vastgelegd, voordat er gestart kan worden met het ontwikkelen. Iedere fase wordt netjes afgerond en we tekenen deze pas af met de opdrachtgever als aan de criteria is voldaan. We hebben voldoende inspanning geleverd in de voorbereiding. De sponsor in het management heeft flink wat geld vrijgemaakt voor dit project. Hij heeft het recht om van tevoren te weten wat hij krijgt en hoe het ervoor staat. Daarna is er wellicht ruimte voor feedback een aanpassingen, aangezien we ook een gedegen change management proces hebben ingericht.
2. Omdat voortschrijdend inzicht het proces verstoort en daarom is het belangrijk om de scope te bewaken. Wijzigingsverzoeken gaan door een change proces en als de consequenties niet opwegen tegen de meerwaarde, dan negeren we de gevraagde aanpassing. Wellicht dat deze in toekomstige releases meegenomen kan worden, maar niet in ons project. Bij additionele scope moet de aanvrager maar eerst eens extra budget aanvragen, onderbouwd met een business case.
3. Omdat de documentatie in orde moet zijn, want ruwe schetsen en post-its aan de muur verhoogt de kans op fouten en daarmee de risico’s voor de kwaliteit van de software of de uitlevering ervan. Met beperkte documentatie kan je nergens op terugvallen, wanneer het eindproduct niet overeenkomt met de verwachting van de eindgebruiker. Op goed naslagwerk kun je bouwen en schept duidelijkheid gedurende het traject en na afronding.
4. Medewerkers moeten vooraf goed opgeleid zijn en succesvolle teams zijn al op elkaar ingespeeld. Leren tijdens de uitvoering is eigenlijk niet gewenst, omdat software ontwikkeling zeer complex is en leerervaringen en voortschrijdend inzicht de voortgang in de weg staan. Capabele mensen maken het juist, dat je de complexiteit vooraf volledig kan doorgronden. Traditionele software ontwikkeling is immers gebaseerd op industriële bouwprincipes, waar ook boortorens en vliegtuigen mee gebouwd zijn.
Als jij heilig overtuigd bent van de bovenstaande denkwijzen, dan ben je klaar met het lezen van alle agile intermezzo’s op deze blog. Misschien zelfs met de hele weblog. Je kan weer gewoon aan het werk gaan en agile predikers de rug toe keren. Ga gerust verder met het normaliseren van de data of het afronden van de functiepunten analyse, of wat dies meer zij.