Effectieve controle kan alleen met Agile-proces

Computable Expert

Theo M Gerrits

Senior Business Consultant

Expert van Computable voor het topic Development

Meer

'Het ging weer eens niet goed, we moeten beter controleren' is de laatste tijd vaak te horen in zowel het bedrijfsleven als bij de overheid. Echter, controles zijn vaak nauwelijks meer dan overhead: een extra kostenpost met minimaal voordeel en mogelijk negatieve effecten op de motivatie van het personeel. Zowel natuurlijke processen als ervaringen uit de engineeringwereld leren ons dat zelfregulerende processen wèl een effectieve manier zijn om tot betere resultaten te komen. En dat zijn precies de Agile-processen, zoals Scrum en andere iteratieve methoden.

De drang tot controleren lijkt wel haast ingebakken in onze menselijke natuur. Bedrijven, instellingen en individuen willen alle mogelijke risico's tot in de kleinste details beheersen en controleren. De hiervoor gekozen oplossingen zijn vaak standaards zoals regels, keurmerken en certificaten. Daarbij vindt vaak een eindcontrole plaats door bijvoorbeeld audits of toetsen. Ook in de softwareontwikkelindustrie komt dit veelvuldig voor. Dit komt duidelijk naar voren in de traditionele waterval aanpak. Eerst wordt de standaard vastgesteld (de requirements), dan wordt er hard gewerkt, en als laatste wordt het systeem gecontroleerd (testen). Maar zijn deze oplossingen wel een goede manier om bij softwareontwikkeling tot betere resultaten te komen?

In dit artikel zal ik eerst uitleggen dat beheersing van buitenaf weinig effectief is. Daarna geef ik voorbeelden van systemen die wèl effectief zijn door zelfregulering. Ten slotte laat ik zien dat een Agile-proces de logische invulling van effectieve softwareontwikkeling is.

Vaststellen vooraf

De planning en requirements die zijn geformuleerd vóórdat het ontwikkelproces is gestart (van buiten af) beschrijven dus een schijnwerkelijkheid.

Controle achteraf

Controle achteraf is bovendien demotiverend: de kans is groot dat je na noeste arbeid te horen krijgt dat het resultaat niet geaccepteerd kan worden. Mogelijk ontstaat een sfeer van wantrouwen: de suggestie wordt gewekt dat werk niet naar tevredenheid is uitgevoerd.

De toetsing die plaatsvindt nádat het ontwikkelproces is beëindigd (van buiten af) heeft dus negatieve gevolgen.

Controle van werkwijze

Vrijheid (van werkwijze) leidt tot verantwoordelijk en pro-actief gedrag, maar beteugeling van menselijk gedrag leidt tot een afwachtende of zelfs een saboterende houding. Expliciete en strikte taakomschrijvingen laten geen ruimte voor samenwerken buiten je ‘eigen gebied'.

De beheersing van de werkwijze door niet-teamleden (maar van buiten af) is daardoor ook verre van optimaal.

Mogelijk worden we een tikje misleid door het Engelse werkwoord 'to control', wat onder andere expliciet in Prince2 (PRojects IN Controlled Environments) wordt genoemd. Dit Engelse woord betekent niet alleen controleren/beheersen maar heeft ook een heleboel betekenissen die het genuanceerder maken dan in het Nederlands. Denk bijvoorbeeld aan 'matigen, onderzoeken, beteugelen, toetsen en sturen'. Dit zijn zeker ook betekenissen zoals bedoeld in Prince2 en met name belangrijk voor softwareontwikkeling.

Voorbeelden van werkende controle

De meet- en regeltechniek laat ons zelfregulerende systemen zien waarbij op basis van directe metingen wordt bijgestuurd: de centrale verwarming regelt zichzelf met een thermostaat, auto's zijn veiliger door ABS en elektronische stabilisatie, moderne machinerie stuurt zichzelf bij op basis van sensorgegevens. Ook in de natuur bestaan zelfregulerende processen: dynamisch evenwicht op celniveau, zelfregulering van een organisme (homeostase), evolutie van populaties.

Deze voorbeelden hebben gemeen dat het zichtbare resultaat (gedrag, uiterlijk, functie) door het systeem zelf wordt bijgestuurd op basis van actuele omgevingsinformatie. Het systeem is goed in de zin dat het aangepast is aan en werkt in zijn omgeving.

Controle opgevat als meten en bijsturen is dus waar we ons op zouden moeten richten. Hoe meer een proces in staat is om te meten en bij te sturen, des te effectiever zal het zijn.

Verder levert de vergelijking van softwareontwikkeling en evolutie een zeer bruikbare metafoor op: de omgeving van softwareontwikkeling wordt gevormd door (de wensen van) de opdrachtgever, de software is aangepast (fit) als deze door de opdrachtgever wordt geaccepteerd.

Hoe moeten we software ontwikkelen?

- Het vaststellen van de requirements. Deze moeten regelmatig worden bijgesteld en geprioriteerd. Het contact met de werkelijke actuele eisen en omstandigheden (de omgeving) moet worden behouden.
- Het produceren van code (inclusief architectuur en design) en bijbehorende artefacten zoals documentatie. Productie (door het team) moet gefocust blijven op de juiste actuele richting. Taken moeten worden geformuleerd op basis van korte termijn doelen in plaats van geformuleerd op basis van hoe ze zouden moeten worden uitgevoerd.
- Deployment en testen (inclusief demonstraties). Het resultaat (de gebouwde software) moet regelmatig in zijn omgeving (vergelijkbaar met de productie-omgeving) worden getest op 'fitness'.

Conclusie

Mijn conclusie is dat alleen Agile-processen effectieve controle bewerkstelligen.