'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
Iedereen kent wel de zwaar opgetuigde specificatiefase van watervalprojecten: veel discussie, veel bezwaren worden geformuleerd en dikke documenten worden opgesteld. Ondertussen is er helemaal niets 'uitgeprobeerd', dus geen enkel concreet systeem waarop gereageerd kan worden. Planning en requirements kunnen weliswaar zeer precies en controleerbaar zijn, maar toch afwijken van de toekomstige werkelijkheid.
De planning en requirements die zijn geformuleerd vóórdat het ontwikkelproces is gestart (van buiten af) beschrijven dus een schijnwerkelijkheid.
Controle achteraf
Controle (testen) achteraf heeft de bekende nadelen van het niet gevoelig zijn voor wijzigende omstandigheden, het laat aanpakken van risico's en het laat ontdekken van fouten/onvolkomenheden. Herstel kost veel tijd en geld.
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?
Als we nu een softwareontwikkelingsproject opvatten als een te besturen systeem, dan moeten we kiezen voor een zelfregulerende aanpak op zoveel mogelijk onderdelen. Stuurmechanismen kunnen worden toegepast op grofweg de volgende onderdelen van het ontwikkelproces:
– 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
Het bovenstaande maakt duidelijk dat een ontwikkelproces pas echt effectief is (of zelfs vanzelf wordt!) als het zelfregulerend is op elk niveau in dat proces. Zelfregulering ligt aan de basis van deze effectiviteit. De processen die hierop de nadruk leggen en andere, overbodige details achterwege laten zijn juist de Agile processen. Scrum bijvoorbeeld eist expliciet dat requirements continu moeten worden bijgesteld doo- de Product Owner, dat de productie optimaal wordt gehouden door Daily Standup en Sprint Retrospective Meetings, en dat het product telkens opnieuw wordt geëvalueerd in Sprint Review Meetings.
Mijn conclusie is dat alleen Agile-processen effectieve controle bewerkstelligen.
Goed artikel, ook de vergelijking met zelfregulerende systemen is weer eens wat anders dan de Plan-Do-Check-Act cycle.
Wat ik zou willen toevoegen is de wens om niet alleen op korte termijn doelen te sturen. Veel SCRUM projecten lopen in de valkuil door alleen op de korte termijn te plannen terwijl daarnaast ook de einddatum en het daarbij behorende resultaat en kosten moeten worden bestuurd. Dit ligt bij SCRUM op het gebied van de product burnup/down chart (i.t.t. de sprint burndown chart).
In control termen: Er is een zelfsturende feedbackcontroller nodig op zowel iteratie (sprint) niveau als projectniveau. De eerste is daarbij genest binnen de tweede.
Wel heel kort door de bocht. Agile is ontwikkeld voor het maken van proto-types in de ontwikkel fase van de SDLC. Niet als een op zich staande ontwikkel methodiek.
De principes zullen ook best nuttig zijn in andere situaties. Maar de inherente risico’s kan niet zomaar overheen gestapt worden.
Toepassingen die mission critical zijn voor de organisatie zou ik toch niet graag via een agile proces ontwikkeld zien worden.
Dacht een interessant artikel te gaan lezen, maar bij Controle (testen) achteraf ging het mis! Achteraf testen is allang niet meer van deze tijd. Het testvak heeft genoeg mogelijkheden om in een zo vroeg mogelijk stadium van development mee te doen, waardoor de nu getrokken conclusies hieromtrent volkomen onjuist zijn!
Dank voor de reacties tot nu toe: het is inderdaad absoluut noodzakelijk dat op elk niveau (dus zeker ook op projectniveau) feedback bestaat en wordt gebruikt.
En juist voor mission critical toepassingen is het essentieel om zoveel mogelijk feedback mechanismen tijdens realisatie toe te passen. Achteraf testen is dan zeker te laat. En hoewel dit niet meer van deze tijd zou moeten zijn, gebeurt het nog veel te vaak dat er pas zeer laat in een ontwikkeltraject wordt getest. Mijn conclusie is juist dat testen tijdens ontwikkeling ontzettend belangrijk is: testen is een essentieel onderdeel van de zelfsturing.
Het al dan niet slagen van succesvolle en/of effectieve controle staat of valt met de mensen die het moeten uitvoeren.
Ontwikkelmethodieken, of dit nu agile is, waterval of GBV, zijn daar in slechts ondersteunend.
Een veel voorkomende implementatie van Agile is AINO, waardoor de kans op falen groot is.
Hetzelfde geld bij andere methoden. Zolang men het belang van de (tussentijdse) controle’s niet inziet, zal men sturen op parameters als kwantiteit en tijd
Kwaliteit, effeciency etc. moet tussen de oren van de mensen zitten. Als de mensen niet willen, kun je allerlei methodieken introduceren, maar zal het niet van de grond af komen.
p.s.
AINO: Agile In Name Only
GBV: Gezond Boeren Verstand