Rigide regels verstoren complexe systemen

´Minder regels´ is een kreet die vaak gebruikt wordt in een politieke context. Men komt steeds vaker tot de conclusie dat rigide regels ontwikkelingen flink in de weg kunnen zitten. Ook binnen software engineering heeft men vergelijkbare inzichten gekregen. Rigide processen zitten de dagelijkse gang van zaken binnen complexe systemen vaak in de weg. De oplossing is volgens Jurgen Appelo van ISM eCompany te vinden in minder regels van bovenaf en meer verantwoordelijkheid bij de deelnemers.

Het is mij opgevallen dat de doorstroming van het verkeer op het Hofplein in Rotterdam groter is wanneer daar alle stoplichten uitgevallen zijn. Ondanks de anarchie die een dergelijke situatie met zich meebrengt, bereikt iedereen de overkant van het plein eerder dan wanneer de stoplichten wel operationeel zijn. Dit geldt niet alleen voor automobilisten, maar ook voor voetgangers en fietsers, zonder dat er ongelukken vallen.

Hier moest ik aan denken toen onder de kop ´Verkeer zonder regels is veiliger´ eerder dit jaar een artikel in Intermediair verscheen waarin uitgelegd werd dat de verkeersveiligheid toeneemt op kruispunten waar verkeersborden en stoplichten weggehaald worden. In zo’n verkeerssituatie voelt men zich namelijk gedwongen om eigen verantwoordelijkheid te nemen en zelf te bepalen wat de beste manier is om zonder krassen op de bumper aan de overkant te komen.
De oorzaak van deze paradox is te vinden in ´risicoperceptie´ en ´schijnzekerheid´. Haal het groene stoplicht (schijnzekerheid) weg en de automobilist zal niet meer blind plankgas geven in de veronderstelling dat hij voorrang heeft op slaperige voetgangers. Haal het zebrapad weg en de voetganger zal beter om zich heen kijken om te zien of er geen opgefokte automobilisten in de buurt zijn (verhoogde risicoperceptie.) Het aantal verkeersongevallen is teruggedrongen op alle plekken waar dit systeem is ingevoerd, bij een toegenomen verkeersdoorstroming.

Alle deelnemers verantwoordelijk

Analoog aan deze verkeerssituaties durf ik te stellen dat dit principe ook van toepassing is op de regelgeving (processen) binnen software ontwikkeling. Het proces in een project moet de verantwoordelijkheid zijn van alle deelnemers aan het project, en dus niet van één autoritaire persoon die van achter een afgelegen bureau de regels uitvaardigt. De introductie van nieuwe regels voor de wijze waarop code ontwikkeld moet worden, hoe er getest moet worden, en hoe nieuwe versies gebouwd en uitgerold moeten worden, leidt niet zomaar tot een hogere kwaliteit van opgeleverde projecten. Integendeel: een vastgelegde testprocedure (stoplicht) die geen rekening houdt met specifieke projecteigenschappen kan juist leiden tot schijnzekerheid. En een formeel specificatietraject (zebrapad) wordt door projectleden vaak doelbewust genegeerd om klanten uit een impasse te kunnen helpen.

Ik ben ervan overtuigd dat iedere deelnemer in het verkeer, en in projecten voor software ontwikkeling, ervan doordrongen moet worden om zelf verantwoording te nemen. Alle regels zijn vuistregels. Ze wijzen je in een richting die vaak de slimste oplossing van een probleem is, maar niet altijd. Soms is het nodig om regels juist af te schaffen om te voorkomen dat mensen ze blind blijven volgen. In de meest succesvolle projecten, waaraan ik een bijdrage heb kunnen leveren, hebben we als ontwikkelaars en projectmanagers veel vuistregels aan onze laars gelapt. We hebben ter plekke met gezond verstand de beste beslissingen genomen. We hebben snel en veilig de overkant bereikt door obstakels tijdig te omzeilen en onzinnige stoplichten te negeren.

Voorzorgsprincipe

Ik probeer het bovenstaande altijd in acht te nemen wanneer zich in een project een vervelend incident heeft voorgedaan. Er is dan altijd wel iemand die roept dat er weer een nieuwe regel nodig is om dergelijke situaties voortaan te voorkomen. Als ik daar elke keer gehoor aan zou geven, ben ik niet anders dan de bureaucraat die voor elk potentieel gevaar een extra verkeersbord op een kruispunt prikt, of de politicus die elk probleem met een nieuwe wet probeert op te lossen. Bij de overheid heet dit het ´voorzorgsprincipe´ en het is op veel gebieden officieel beleid. Nederland is dan ook het land met de meeste verkeersborden per vierkante meter.

Kwaliteitsmanagers die gangbare methodieken voor procesverbetering hanteren, zoals het CMMI, gaan meestal ook uit van het voorzorgsprincipe. Problemen worden opgelost door het toevoegen van nieuwe procesbeschrijvingen. Ik heb ze er nog nooit op kunnen betrappen dat ze processen verwijderen om zaken beter te laten lopen. Dit is natuurlijk heel begrijpelijk: politici en verkeersregelaars hoor je ook niet snel zeggen dat hun bemoeienis met de samenleving averechts werkt. Een kwaliteitsmanager zal van zichzelf niet zeggen dat zijn baan meestal overbodig is en dat de dagelijkse praktijk maar beter aan verstandige projectdeelnemers overgelaten kan worden.

Methodologieën

Als reactie op de alsmaar uitdijende procesbeschrijvingen van diverse methodologieën (denk aan RUP en Prince-2) is enige jaren geleden een tegenbeweging ontstaan van zogenaamde agile methodologieën, waaronder onder meer DSDM, XP en SCRUM geschaard worden. De intentie van deze methodieken was om onder verstikkende regelgeving in projecten uit te komen door alleen de meest eenvoudige en essentiële processen te definiëren. Heel veel wordt aan het probleemoplossend vermogen van de projectleden overgelaten.

Toch blijkt in de praktijk dat de agile methodieken wel flexibel zijn ten opzichte van de user requirements, maar niet ten opzichte van het proces. In de procesbenadering zijn ze feitelijk net zo strikt als de grotere methodieken, maar dan op kleinere schaal, met een kleiner aantal processen. DSDM stelt dat je begint met een feasibility study en een business study, XP vertelt ons dat je requirements beschrijft als user stories, en SCRUM schrijft een Scrum Master voor, die het proces moet bewaken, om maar wat voorbeelden te noemen. Dit strookt niet met het idee dat er geen vaste regels zijn. Een goede projectmanager mag alle regels vervangen of overboord gooien, zolang de stakeholders maar tevreden zijn.

Inmiddels beseffen de experts steeds meer dat geen enkele methodologie de juiste is. Ivar Jacobson, één van de geestelijke vaders van RUP, heeft het onlangs toegegeven in een driedelig artikel genaamd ´Enough of Processes: Let’s do Practices´. Niemand moet zomaar vertrouwen op regels die door anderen uitgevaardigd zijn en die niets weten van de praktische situatie waarmee je jezelf geconfronteerd ziet. Je bereikt de beste resultaten wanneer je al doende je eigen processen inricht, die passen bij de situatie van de dag. Laatst zag ik het resultaat van enkele onderzoekers die agile software processen bestudeerd hadden. De titel van het artikel zegt genoeg: ´The Best Way to Implement Agile Processes: Your Own Way´.

Conclusie

Binnen het vakgebied van software engineering verwacht ik verdere ontwikkelingen op dit gebied. Het enige nut van methodieken is software engineers bewust maken van mogelijke processen en hen te laten kiezen uit best practices. De toepassing hiervan vindt steeds minder plaats via proceshandboeken, door kwaliteitsmanagers op het niveau van de organisatie of zelfs het project. De werkelijke successen wordt behaald door medewerkers die in staat zijn om per dag te bepalen welke processen op de actuele situatie van toepassing zijn.

Ik let in het verkeer al jaar en dag nauwelijks op verkeersregels. Dat is omdat ik voortdurend intensief op alle auto’s, fietsers en voetgangers let. In de vijftien jaar dat ik mijn rijbewijs heb, heb ik nog nooit iemand aangereden. Een vriend van mij is daarentegen laatst gezakt voor zijn eerste rij-examen. Hij had netjes naar het groene stoplicht gekeken, en had daardoor bijna een voetganger van de sokken gereden die bij een rood voetgangerslicht de straat overstak. Inmiddels heeft hij geleerd eerst naar het verkeer te kijken, en pas daarna (als er tijd is) naar de regels.

Jurgen Appelo, chief information officer ISM eCompany