Hoewel de meeste softwareontwikkelactiviteiten in de categorieën gecompliceerd en complex vallen, geldt dit niet voor het domein software engineering in z’n geheel. Het spectrum van software ontwikkeling reikt immers van nieuwe innovatieve productontwikkeling tot productonderhoud, operatie en support. Onderhoudswerkzaamheden kunnen in het Cynefin model bijvoorbeeld anders geclassificeerd worden dan nieuwe innovatieve productontwikkeling.
Snowden definieert een probleemomgeving als eenvoudig indien er een voor de hand liggende relatie is tussen oorzaak en gevolg. Vaak vallen we in dergelijke situaties dan ook terug op ‘best practices’ om het probleem op te lossen. De oplossingen zijn immers bekend. Bijvoorbeeld; je gaat wandelen, het begint te regenen en je wordt nat. Je weet uit ervaring dat het gebruik van een paraplu de oplossing is. Wandelaars die uit voorzorg een paraplu bij zich dragen op een druilerige dag is het gevolg van best practice denken. Scrum kan gebruikt worden in simpele omgevingen, maar het is waarschijnlijk niet het meest efficiënte middel. Denk bijvoorbeeld eens aan de behoefte van een bedrijf in hun communicatie gebruik te maken van een website waarin ze zelf de content kunnen aanpassen en updaten. De ervaring leert dat dit tijdrovend en kostbaar is, waardoor er Content Management Systemen ontwikkeld zijn. Een web development bedrijf zal voor de realisatie zich waarschijnlijk richten op een dergelijk CMS-systeem. De aangeboden oplossing zal afgezien van vormgeving en omvang van de website niet veel verschillen van vergelijkbare opdrachten. Het is eerder een herhaling van zetten. Zeker als techniek, middelen en personeel vrijwel constant zijn, ligt het voor de hand om hier een proces voor te gebruiken waarin een duidelijk gedefinieerde, herhaalbare set van stappen wordt gedefinieerd die keer op keer leidt tot het gewenste projectresultaat.
Gecompliceerd
Bij gecompliceerde problemen is er nog steeds een verband tussen oorzaak en gevolg, maar deze is veel minder gemakkelijk te zien. Vaak zit er tijd tussen oorzaak en gevolg, waardoor het minder voor de ligt. Ook hier is er sprake van best practices, maar is er veelal een expert nodig om het verband te leggen tussen oorzaak en gevolg. Bovendien kunnen er ook meerdere goede oplossingen zijn, slechts de aanpak en neveneffecten verschillen. Denk bijvoorbeeld eens aan een defect koffiezetapparaat; iedereen kan herkennen dat er is mis is, maar zelf repareren lukt niet. In dat geval zit er tijd tussen het opmerken van het gevolg en het achterhalen van de oorzaak door de expert. Hoewel je zeker met Scrum kunt werken in een dergelijke omgeving, is het waarschijnlijk niet het meest voor de hand liggend. Als we bijvoorbeeld eens kijken naar softwareonderhoud dat op dagelijkse basis plaats vindt (dus niet periodiek), dan is er een voortdurende stoom van supportvragen of bugs te verwerken. Experts hebben weliswaar de ervaring hoe ze vaak voorkomende problemen moeten onderzoeken en oplossen, maar het is voorafgaand lastiger te plannen wat de doorlooptijd is van probleem naar oplossing.
Complex
Snowden definieert een situatie als complex als het verband tussen een oorzaak en een gevolg niet zomaar eenduidig is. In complexe situaties zijn oorzaak en gevolg pas achteraf zichtbaar en heeft een gevolg vaak meerdere oorzaken. We spreken vaak van een samenloop van omstandigheden. Complexe omgevingen vergen een andere manier van handelen en managen. Een ander kenmerkend aspect is dat steeds een andere samenloop van omstandigheden kunnen leiden tot hetzelfde gevolg. Denk bijvoorbeeld aan het fileproblematiek. Files kennen uiteenlopende oorzaken. Het is minder zinvol de vele verschillende oorzaken die samen tot één enkele file leiden in kaart te brengen. Het levert geen bijdrage aan het oplossen van files. Complexe situaties zijn vaak eerder onvoorspelbaar dan voorspelbaar. Als we al iets weten dan is het achteraf. Een bijdrage in de oplossing is dan ook het uitvoeren van experimenten, ook wel probing genoemd. Hierbij leren we van het probleem en kunnen we ons erop aanpassen. Dit vraagt echter een creatieve en innovatie manier van werken. Routine en standaardoplossingen zijn hier immers niet van toepassing. Wat we echter wel nodig hebben is een ‘fail-safe’ omgeving waarin we kunnen experimenteren om te kunnen leren en tot belangrijke informatie te komen. Innovatieve software ontwikkeling is een typisch voorbeeld van een complexe omgeving. Scrum is hier dan ook bijzonder geschikt.
Chaotisch
Chaotische situaties vragen om een snelle reactie. Denk bijvoorbeeld eens aan een autobrand, het bezoek van Anders Breivik aan het eiland Utøya, of de financiële crisis is Griekenland. Kenmerken voor een chaotische situatie is dat je eerst iets moet doen (om het acute gevaar te ontlopen). Spring uit je brandende auto, zorg voor een grote kapitaalinjectie om de eerste financiële nood te trotseren, enz. En pas daarna ga je om je heen kijken of er nog meer onheil of je afkomt of dat er kansen zijn voor verbetering van de situatie. Het zijn situaties waarin we onmiddellijk moeten reageren om de schade te beperken en iets van orde te herstellen. Scrum is hier niet het beste middel. We zijn niet geïnteresseerd in het prioriteren van een backlog waarin we de acute nood gaan inplannen voor de volgende sprint. Het stoppen van het bloeden heeft immers de meeste prioriteit. Dat gezegd hebbende wil het niet zeggen dat Scrum niet mogelijk is. Als we werk in een sprint moeten onderbreken voor bijvoorbeeld een productieverstoring, wat zijn dan de gevolgen voor de sprint? En maakt dit het gebruik van Scrum onmogelijk? (Zie ook de blog “onderhoud en Scrum werkt niet?!“)
Wanorde
Er is sprake van wanorde als je niet kunt beoordelen in welk van de eerder genoemde situaties je je bevindt. Dit is een gevaarlijke situatie. In een dergelijk geval neigen mensen ernaar om op basis van persoonlijke voorkeur te interpreteren. Bovendien handelen ze naar eigen inzicht. En dat is vaak op basis van bestaande kennis en ervaring. In softwareontwikkeling staat de alom bekende gefaseerde, sequentiële (waterval) aanpak centraal, die goed werkt in simpele domeinen. Daar zijn we mee ‘groot gebracht’. Helaas blijkt een dergelijke aanpak een slechte fit bij de meeste aspecten van software ontwikkeling.
In geval van wanorde is het advies om de situatie op te delen en in te delen en deze afzonderlijk te classificeren. Of Scrum geschikt is in geval van wanorde? Dat is niet de vraag. Zorg dat je uit de wanorde geraakt en kijk voor elke deelsituatie welk middel het best een bijdrage vormt in de oplossing
Referentie
Snowden, David J., en Mary E. Boone. 2007. “A Leader’s Framework for Decision
Making.” Harvard Business Review, November.
