Tijdens een onlangs georganiseerde bijeenkomst over de symbiose tussen agile ontwikkeling en kwaliteit gingen vijftien Nederlandse cio’s en cto’s een discussie met elkaar aan over dit onderwerp. Het samengaan van kwaliteit en agile is geen vanzelfsprekendheid, het is topsport.
Naast de discussie presenteerden Bol.com, Nationale Nederlanden en Océ interessante praktijkcases. Stuk voor stuk voorbeelden van een geslaagde symbiose van agile ontwikkeling en kwaliteit, maar ieder belicht vanuit een andere hoek. Het samengaan van kwaliteit en agile is geen vanzelfsprekendheid. Daar waren alle cio’s en cto’s het over eens. Sterker nog, volgens mij is het topsport!
Alle gevolgen van dien
Stel, je wilt met een team deelnemen aan een wielerwedstrijd. Als het goed is spring je dan niet op de eerste de beste fiets, maar bereid je je gedegen voor. Je bedenkt met elkaar antwoorden op vragen als welke afstand afgelegd moet worden, in hoeveel etappes, met welke taakverdeling in het team en met welk materieel. Ik heb al verschillende organisaties gezien die de overstap maakten naar agile en van de een op de andere dag gewoon begonnen te fietsen, met alle gevolgen van dien.
Om je voor agile goed voor te bereiden moet je denken aan de volgende punten:
– Hoe ziet het ontwikkelproces eruit, welke rollen zijn er en dragen wanneer bij en hoe wordt de kwaliteit gewaarborgd? Testers nemen bijvoorbeeld al in een vroeg stadium deel; bij het bespreken van de user stories. Ze bouwen geautomatiseerde testscripts en reviewen de unit tests die de ontwikkelaars maken. De ontwikkelaars reviewen de testscripts.
– De verandering die het team moet doormaken om een goed op elkaar ingespeeld agile team te worden. Kwaliteit is bij agile ontwikkeling een team effort, rollen van analist, tester en ontwikkelaar lopen meer en meer in elkaar over. Deze verandering zal niet vanzelf gaan, het is vallen en opstaan.
– Als het te bouwen systeem groter wordt, ontstaat de uitdaging het werk op te delen tussen teams. Door het opdelen zal er telkens weer een vorm van coördinatie en overleg georganiseerd moeten worden. Zo kunnen de agile teams bijvoorbeeld op basis van features opgedeeld worden, de zogenoemde feature teams. Deze teams werken vanuit het perspectief van gebruikersfeatures en doorsnijden hiermee vaak het hele systeem. Hiernaast is het teamoverstijgend ontwerpen vaak een punt van aandacht, wat niet met de scrum of scrums alleen opgevangen kan worden.
– De inzet van tooling voor bijvoorbeeld continues integration and regressietesten. Om hoge kwaliteit te behalen in combinatie met korte doorlooptijden is vergaande automatisering van bouw- en testprocessen noodzakelijk.
Ten slotte is er het aspect van continu verbeteren. De beste agile organisaties en teams leggen de lat elke keer een stukje hoger en zijn continu bezig met het verbeteren van alle mogelijke aspecten. Al deze aspecten bij elkaar maken dat het bereiken van symbiose tussen kwaliteit en agile ontwikkeling een vorm van topsport is waar je goed voorbereid aan moet beginnen. En vergeet daarna niet aan je conditie te blijven werken om te kunnen pieken, anders is het bereiken van de top slechts van korte duur.
Ik denk dat er sprake is van begripsverwarring, de rollen en genoemde werkwijze horen naar mijn mening meer bij scrum. Scrum is een procesbegeleidingsmethode en zegt niet zoveel over de inhoud. Bij agile heb ik iets anders voor ogen en dat kan uitstekend zonder scrum of enige ander procesbegeleidinsmethode. Bij agile denk ik aan een werkwijze waarbij ruimte is voor voortschrijdend inzicht.
Over het opdelen in teams bij grote projecten. Je geeft aan dat teams worden ingedeeld naar features. Ik denk dat dat niet verstandig is, bij het opdelen van een ict project in deelprojecten zou volgens mij het technische ontwerp van je software een rol moeten spelen: ben je in staat om het werk in ‘onafhankelijke’ delen op te delen. Onfhankelijk behoudens de interfaces tussen die onderdelen natuurlijk.
Wel aardig om te lezen over het continu verbeteren, onlangs hoorde ik nog de rol continu verbeter coach. Naast de bevindingen coördinator en de dependency manager. Het mag duidelijk zijn, ik vind het een gruwel en het kost ook nog bakken met geld. Het is inderdaad geen garantie voor kwaliteit.
Met alle Respect voor de auteur, schud ik mijn hoofd maar weer eens. Ook heir word duidelijk dat je het verhaal uiteindelijk kunt volgen als je een straatje ‘scrum’ hebt gedaan en daar een certificaat voor hebt gehaald.
IT en topsport. Als er iets lui’s is, dan is het wel een IT-er. Tenminste, een goede IT-er. het doel van autonatiseren is namelijk steeds vaker achterover kunnen leunen en apparaten ‘het werk’ laten doen. Zo simpel is dat.
Nu zijn er een aantal dingen die je hebt met IT. Wtmatigheden omdat de materie IT zich gewoon zo beweegt, een lijstje met do’s en do not’s, willen begrijpen waarom ‘iets’ wel werkt of niet en….. bereid zijn te leren van je fouten.
En dat doe je gewoon met ‘proven concepts’, ook bij ontwikkelen en testen. Je kunt het wat mij betreft Tmap, Iseb, Scrum, Agile, Itil, Prince noemen, feit blijft heel eenvoudig, dat als je de brug niet slaat tussen IT en Non IT, je kan roepen wat je wilt, maar dat trajecten dan vooral heel erg veel geld blijken te gaan kosten.
Van de meest basale werking in essentie van IT als materie heeft menig scrum enthousiast haast geen kaast gegeten, laat staan menig tester of ontwikkelaar. En dat is jammer. want heel scrum begint echt niet met….. ‘Dit is IT als materie, zo werkt het, en als je dat niet inegreerd met, om het even, welk middel en hoe je het noemt, met de werking van IT als materie, dan gaat het je een hele hoop geld kosten….’.
En was het nu net niet zo dat we willen dat IT en Non IT elkaar eindelijk eens gaat begrijpen zodat we bereiken met IT waar IT voor staat? Heel eenvoudig besparen?
Toch?
Dat kwaliteit topsport is, met of zonder agile, is niet nieuw. Geld, tijd, en ook functionaliteit zijn tastbaarder dan kwaliteit. Wil je een goede balans hebben tussen alle aspecten, dan is het nodig om meer aandacht te geven aan kwaliteit: Scherp krijgen voor alle stakeholders wat kwaliteit is en wat het voor hun betekent en samenwerken om de vereiste kwaliteit waar te maken.
Scrum helpt om kwaliteit zichtbaar en bespreekbaar te maken, en een agile mindset draagt bij om een effectieve en efficiënte aanpak te bepalen, en die continu te verbeteren. Het toepassen van Scrum is inderdaad topsport, teamsport!
In een eerder artikel op Computable, https://www.computable.nl/artikel/opinie/management/4657509/2379250/kwaliteitsproducten-en-diensten-met-scrum.html, heb ik mijn kijk op kwaliteit met Scrum beschreven. Succesfactoren voor kwaliteit met Scrum zijn:
– Samenwerken met gebruikers
– Vaker en tijdiger actie ondernemen
– Agile kwaliteitstechnieken
Item 2 en 3 zie ik terug in bovenstaande samenvatting van de bijeenkomst over de symbiose tussen agile ontwikkeling en kwaliteit, maar item 1 mis ik? Ik zou verwachten dat een CIO de samenwerking tussen IT / R&D afdelingen en de gebruikers / klanten belangrijk vindt, en daar ook op stuurt. Is hierover gesproken op deze bijeenkomst? Zo ja, wat doen CIOs om deze samenwerking te verbeteren? Ik ben benieuwd!
In dit artikel worden een aantal belangrijke zaken genoemd. Natuurlijk zijn een goede voorbereiding, goed teamwerk, overzicht, tooling, integratie- en regressietesten en verbetering belangrijk. Vergeet echter niet dat wederzijds vertrouwen en inzet hier van groot belang is.
Om de analogie met sport door te zetten: de sporter moet er vanuit kunnen gaan dat de organisatie een goede wedstrijd neerzet, maar de organisatie moet er ook vanuit kunnen gaan dat de sporter niet valsspeelt. Alleen wanneer dit vertrouwen er is, kan er sprake zijn van een positieve vorm van symbiose (dus geen parasitisme, wat ook een symbiose is).
Wat ik nog mis in dit artikel is een duidelijke uitleg over kwaliteit. Gaat het hier over de kwaliteit van het opgeleverde product, de kwaliteit van het proces of beide?