Bij aanvang van de transitie naar een Agile-werkwijze werd developers een omgeving in het vooruitzicht gesteld, waarin hun talenten optimaal worden ingezet om waardevolle producten te ontwikkelen. Een omgeving waarin ze hun ambities kunnen realiseren. En de ruimte hebben om te leren en talenten te ontwikkelen. Ik constateer in de praktijk dat er een aantal ontwikkelingen zijn waardoor het leren wordt beperkt.
Het geven en verwerken van feedback is verplaatst van het opgeleverde product naar het op te leveren product.
Met Agile development ontstond het idee om incrementeel software naar productie te brengen om op basis van feedback te beoordelen welke user stories van de backlog ontwikkeld moesten worden. De behoefte om frequenter te releasen werd naar gelang de tijd vorderde steeds groter en dat heeft geresulteerd in continuous delivery. Het lijkt steeds minder te gaan om het beoordelen van de waarde van opgeleverde producten, maar meer om het beoordelen van het stabiel functioneren van de code. Met de toenemende frequentie van releasen is de noodzaak ontstaan om de teams en techniek zo in te richten dat ze die snelheid van opleveren kunnen realiseren. Daarmee is het geven en verwerken van feedback verplaatst van het opgeleverde product naar het op te leveren product. Met als gevolg focus op automatisering en integratie van tooling in plaats van op creativiteit en experimenteren. En dus leren.
De ruimte om talenten te ontwikkelen die ten goede komen aan de waarde van producten lijkt zeer beperkt als niet precies duidelijk is wat het op gaat leveren.
Een tweede ontwikkeling in het Agile werken is de toegenomen behoefte aan voorspelbaarheid. Het blijkt in de praktijk lastig om afhankelijk te zijn van teams die in onvoldoende mate in staat zijn aan te geven wat ze op termijn gaan opleveren. Er blijkt in organisaties nog steeds behoefte aan het realiseren van vooraf gedefinieerde doelstellingen om daar vervolgens op te gaan sturen. Er is daardoor minder plaats voor het leren door te experimenteren. De bij de introductie van Agile werken beloofde ruimte om talenten te ontwikkelen en benutten die ten goede komen aan de kwaliteit en waarde van de op te leveren producten lijkt zeer beperkt als niet precies duidelijk is wat het op gaat leveren.
Samen werken aan één product is niet alleen effectief, het stimuleert creativiteit en het leren van nieuwe vaardigheden.
Maar neemt het lerend vermogen van de teams nu alleen maar af omdat er minder ruimte voor geboden wordt? Nee, teams moeten de ruimte die er is wel willen benutten. In theorie zijn developers in een Agile organisatie personen die meedenken, een kritische blik hebben, creatief en ondernemend zijn en zichzelf continu willen blijven ontwikkelen. Daarbij heeft het management een faciliterende rol gekregen. Maar wat nu als in de praktijk teams zich niet continu willen blijven ontwikkelen en geen gebruik maken van de geboden faciliteiten? Ik zie in de praktijk dat de intrinsieke motivatie om voortdurend te ontdekken, te leren en elkaar te stimuleren om te leren er niet altijd is of minder aanwezig is dan voorheen. Belangrijk om te leren is het samenwerken juist ook buiten de reguliere Scrum gebeurtenissen. Samen werken aan één product is niet alleen effectief, het stimuleert creativiteit en het leren van nieuwe vaardigheden. Door samen te werken, wordt direct feedback gegeven op het gemaakte product en op een constructieve manier gezocht naar verbeteringen. De teamleden vergroten door samen te werken het lerend vermogen van elk individu en van het team als geheel.
Met QAOps worden QA activiteiten geïntegreerd in de CI/CD pipeline en daardoor ontstaat in het gehele ontwikkelproces aandacht voor de kwaliteitsaspecten van het product.
De ontwikkelingen op het gebied van de softwareontwikkeling gaan in razend tempo en dat vraagt veel van zowel het management als van de medewerkers. Ik vind het bewonderenswaardig welke resultaten worden bereikt in het ontwikkelen van organisatievormen en technische toepassingen. Mijn zorg zit in het niet optimaal benutten van de potentie die teams bezitten om wensen van de business te vertalen naar vernieuwende toepassingen die van waarde zijn. De noodzaak om te snelheid van ontwikkelen te combineren het zorgdragen voor kwaliteit en waarde van producten wordt ingezien. Daarmee is de ontwikkeling van DevOps naar QAOps ingezet. Met QAOps worden Quality Assurance activiteiten geïntegreerd in de CI/CD pipeline en daardoor ontstaat in het gehele ontwikkelproces aandacht voor de kwaliteitsaspecten van het product. Als dat gecombineerd kan worden met de ruimte en de wil om te experimenteren, te ontdekken, kritisch te zijn, samen te werken en echt wendbaar te zijn in de oplossingen die ontwikkeld worden, gaat er op alle vlakken nog heel veel geleerd worden. En daarmee waarde toegevoegd worden aan producten.
Boris Schouten
