Agility zonder technische uitmuntendheid is kwetsbaar

Als agile het onderwerp is, lijkt het alsof de meeste discussies draaien om frameworks. Er zijn veel LinkedIn berichten dat 'SAFe niet agile is', 'Spotify is geen model' en 'Scrum is niet gebaseerd op realisme'. Ik meng me niet graag in die debatten, omdat het vaak meer gaat om 'het winnen van een argument' dan om elkaar te helpen naar een beter begrip.

Maar ik ben wel graag kritisch. We moeten ons vak hoog houden. Als je een agile coach, scrum master of een vergelijkbare rol hebt - het is je plicht om agile op de best mogelijke manier te doen. Het is je verantwoordelijkheid om er alles aan te doen om de voordelen van agility te realiseren. In dat licht wil ik wel een punt maken voor de agile gemeenschap. Ik probeer dat kritisch maar constructief te doen. Ik wil geen ruzie winnen. Ik wil de gemeenschap helpen om meer voordeel te halen uit hun agile inspanningen.

In alle bovengenoemde discussies denk ik dat we vaak geneigd zijn een hoeksteen te vergeten van waar het bij agile om gaat. Agile is oorspronkelijk bedoeld voor softwareontwikkeling.

Ja, wendbaarheid is cruciaal in verschillende andere gebieden die te maken hebben met de onzekerheid en  complexiteit van de moderne wereld. Ik wil niet alle situaties terzijde schuiven, maar mijn redenering hier geldt voor agile binnen het domein van software.

Agility en het bereiken van technische uitmuntendheid 

Agile gaat over het omgaan met de inherente complexiteit van het maken van waardevolle software. Het gaat over technische uitmuntendheid en 'andere' manieren van ontwikkelen en opleveren. Complexe problemen in software kunnen oplossen vereist experimenteren en creativiteit. Het is letterlijk leren tijdens het uitvoeren. Wij vinden de oplossingen door de code te schrijven. Om dit iteratief en incrementeel te doen, is wellicht een heel andere gereedschapskist met technische praktijken nodig.

Toch is er een aanzienlijk deel van de populatie van agile coaches, scrum masters en vergelijkbare rollen die weinig tot geen ervaring hebben op het gebied van technische praktijken. Geen oordeel, gewoon een observatie. Ik wil niet zover gaan dat je niet goed kunt zijn in die rollen zonder die expertise. Ik heb geweldige scrum masters gezien zonder enige technische ervaring. Ik denk wel dat als je geen aandacht hebt voor technische excellentie, je niet alle voordelen van agile kunt oogsten. De vraag is ook of de ontwikkelaars je ooit serieus zullen nemen. Er kan altijd een kloof zijn tussen hun wereld en de jouwe. Het is als een voetbalcoach die nog nooit in zijn leven heeft gevoetbald of een leiderschapsconsultant die nog nooit managementverantwoordelijkheden heeft gehad.

Als professional op dit gebied denk ik dat je agile moet benadrukken en ondersteunen met technische uitmuntendheid, anders wordt agile zinloos. Als we geen product maken dat veranderbaar en onderhoudbaar is en dat na elke iteratie van hoge kwaliteit is, verliezen we de wendbaarheid van het product zelf. Agile wordt kwetsbaar. Als we teruggaan naar de 'roots' van agile, het Agile Manifesto - moet je concluderen dat veel van de principes direct gerelateerd zijn aan technische praktijken (en ik zou voor alle principes iets kunnen zeggen).

Onze hoogste prioriteit is de klant tevreden te stellen door vroegtijdige en continue levering van waardevolle software. Continuous delivery en deployment

Veranderende eisen verwelkomen, zelfs laat in de ontwikkeling. Agile processen benutten verandering voor het concurrentievoordeel van de klant. Aanpasbaarheid van de software

Lever regelmatig werkende software op, van een paar weken tot een paar maanden, met een voorkeur voor de kortere termijn. Kleine releases en geautomatiseerde deployment

Voortdurende aandacht voor technische uitmuntendheid en een goed ontwerp verhoogt de wendbaarheid. Codering standaarden en eenvoudig design

De beste architecturen, eisen en ontwerpen komen voort uit zelforganiserende teams. Emergend Architecture en Test Driven Development

Als je een rol hebt als agile coach of scrum master, en je hebt deze ervaring niet, dan is het toch je plicht om je team te helpen bij het invoeren van technische praktijken en te focussen op technische uitmuntendheid als hoeksteen van wendbaarheid. Je hoeft niet alle antwoorden te hebben om het gesprek op gang te brengen. Je hoeft niet de expert te zijn om je team te coachen en te faciliteren. Het is meer dan goed om te vertrouwen op je team om hun eigen oplossingen te vinden op het gebied van technische uitmuntendheid. Je hebt wel de verantwoordelijkheid om je team te helpen zich voortdurend te verbeteren in de manier waarop ze ontwikkelen en leveren.

Vul uw gereedschapskist om uzelf beter in hun schoenen te plaatsen. Verdiep je in concepten als pair programming, continuous integration, continuous delivery, TDD, refactoring, technical debt, simple design en coding standards. Mijn advies daar: Praat met uw ontwikkelaars over de uitdagingen waarmee ze worden geconfronteerd telkens als ze onder de motorkap kijken. Praat met een collega die deze expertise wel heeft. Mijn vriendelijke suggestie: Focus op de hoeksteen van technische uitmuntendheid voordat u investeert in het leren van een nieuw framework.