Using Cynefin in agile digital projects
I first came across the Cynefin framework at my previous company, around 5 years ago. I loved its ability to reduce risk in projects, but couldn't make it work in the agile teams I was working with at the time.
Fast forward to 2020 mid pandemic, when I was working for UKRI on a decommissioning and transitioning report and roadmap for them. Made Tech had won the gig partially due to David Winters excellent book ‘Modernising Legacy Applications in the Public Sector’.
The Made Tech team had landed in a multi client, mid transition project that was undergoing incumbent team churn. Initially we learnt the ropes, and slipped into a technology led investigation. Thankfully we identified this as a risk early enough to modify our working practices and assumed a user first stance. Davids book contains a prioritisation matrix (shown below), which I used as a basis for prioritising the technical cost(risk) of decommissioning against the business value (I interpreted this as value to the user).
I brought the Cynefin technique of allocating an area of business (or business process) as either Chaotic, Complex, Complicated & Simple. This method has the neat function in that there is an inherent desire (or direction of travel) to reduce complexity of each domains content (EG. understand a chaotic process, and make it complex, and so on). Each domain has a series of tactics to be used (action modes), and so manage a particular situation. for instance a complex process should be probed, sensed, then responded to, with the ultimate aspiration being to reduce the business process to an ‘IKEA flat pack solution’ — IE. one that may be complicated, but uses good (known) practice to solve.
The UKRI business process prioritisation matrix shown here used Cynefin framework to identify the technical approach that would enable the ‘commodification’ of each business process by moving them from complex (right side) to simple (left side). One interesting aspect of this matrix is the clustering of business process’s that have interdependency — which was becoming a potential blocker, until their relationship had been graded by the same Cynefin framework.
I’ve subsequently run a Risks & Assumptions workshop with Ofgem, using the same Cynefin framework. The feedback I’ve received from this session would indicate that it’s not as usable as a gauge of risk. The team had problems with switching mode from risk identification, and ‘how might we mitigate this risk’ on the same board.
TLDR: I’m sold on the Cynefin Framework as a tools for reducing risk, however the project team need careful coaching and the context needs planning for best results.
