What are you doing on your project? A tricky question with so many replies; coding, planning, problem solving? We approach portions of a programming project in different ways; what drives our different approaches?
A comment on a previous post discussed the need for using the right tool for the job I agree; we need the tools that are applicable to the circumstances we face.
So we need a model of the different aspects of work we do in very general terms so that we can apply our model when we need it. Cynefin is a sense-making framework, derived by David Snowden et al, describing contextual complexity and how people act within different contexts. Why introduce this framework rather than some other? Cynefin links how people react to the context of what they know to characteristics of that context. For the purpose of our discussion I’m going to summarize; do take time to read ref 1. Cynefin introduces many insights and Refs 1 and 2 are worth reading.
We’re going to refer to Figure 1 ‘Cynefin Domains’ diagram from ref 1. In the bottom-right we have the domain of known-knowns. Cause-and-effect relationships are known and undisputed. Best-practice techniques are effective in this domain along with standard operating procedures. The decision-model is ‘Sense-Catogorize-Respond’.
Let’s compare the Known-Known domains with a model of a software project. What activities could we associate with this domain. Bug-triage come to mind. We have regular meetings to review bugs associated with our software. We test and record the bugs (Sense), set priority and severity for each bug (Categorize) and then set a plan for dealing with the bug (Respond).
Another example is a Gantt chart (Ref 3). Typically our Gantt charts are a visual description of a work-breakdown structure (WBS) and WBS shows how tasks depend on each other. So WBS is a statement of expected cause-and-effect. Know cause-and-effect also describes Waterfall methodology.
Above the ‘Known-Knowns’ we have the domain of the Knowable. We may not know everything in this domain, but, if we expend effort we can discover things. Snowden et al assert people typically don’t expend time and effort discovering things and, instead, rely on expert opinion.
Using our Gantt chart example; in the software world, as many have experienced, the expected cause-and-effect rarely occurs. Weekly schedule review meetings are an example of revising schedules to reflect what we learned and have placed into the domain of Known and update our Gantt charts! Another tactic is to provide estimate variances on Gantt charts. A common expectation is that estimates will improve over time (Ref 5). By providing estimates we’re acknowledging we don’t completely know about the work-in hand and we use estimates to express our level of uncertainty.
The decision model in the Knowable domain is ‘Sense-Analyze-Respond’. In my opinion this is the manner in which most software projects execute. We don’t know all the implications of implementing features (we don’t know all the features) and we undertake a program of adding code and then observing how our system operates. Unit-testing is an example of this approach as is build-and-test and continuos integration. A key measure of ‘Sense-Analyze-Respond’ is the rapidity of a response. Both unit-testing and continuous integration aim to provide a response of the order of minutes.
For this blog-post we’ll look at Scrum and it’s context. Cynefin gives us the two domains of the Un-ordered; Complex and Chaotic. Complex’s decision model is ‘Probe-Sense-Respond’ and Chaos’s decision-model is ‘Act-Sense-Respond’.
One of Scrum’s tag-lines is ‘Control Chaos’ and it appears in one of Scrum’s web-sites (ref 4). I’ve been wary of the claim that chaos is being controlled. From a Cynefin perspective Scrum occupies both Un-ordered domains because Scrum’s sprint/retrospective feedback loop approach fulfills the needs of both domains decision-models. In Cynefin terms Chaos is being changed to Complex/Knowable or Known; whether or not that constitutes ‘control’ is open to debate.
Before we move on we need to look at Cynefin’s fifth domain; the domain of disorder in the centre of Ref 1 Fig 1. Snowden et al use the disorder domain to illustrate why decision makers (managers, project managers and programmers, us) can disagree on what domain they are in. Cynefin provides insights into the effect of people’s different perspectives on a situation with the observation that it’s easy for people to identify the extremes of any given domain but hard to definitely agree on subtleties of domain characteristics. For example; I may believe a project is in the Complex domain but you may believe everything is in the Known domain. The insight from the Cynefin model is that interpreting the Disorder domain is a matter of personal bias. From a software development perspective this manifests itself as disagreement on the approach to solving project-related issues; a lack of consensus.
So do we use the right tool for the job? Given Cynefin’s domains we have tools and techniques that are applicable in a given domain; e.g. WBS for Known/Knowable, Scrum for Complex/Chaotic. In an earlier post I mentioned Ken Schwaber’s statement that 30-35% of Scrum projects succeed and I wondered what happened to the other 65-70% of projects. Cynefin gives us a powerful vocabulary for describing the knowledge we have about a project, but, given my brief descriptions here we haven’t touched on other facets of a software project; specifically the people involved and the organization hosting the project. To get a thorough answer to our ‘right tool for the job’ question we’ll have to factor-in people and host-organization. The effect of people’s bias on interpreting the Disorder domain opens an interesting line of inquiry for the future.
At the beginning of this post I posed the question ‘What are you doing?’ Now I can re-state the question in two parts: On your project, how much is known and how much is unknown? Are you adapting your approach based on what you know and what you don’t know?
Here some questions I’ll be addressing in future posts:
Can we specify what a self-organizing team should aim at? One big criticism of Scrum is that telling a team to ’self-organize’ isn’t enough. Is it possible to provide guidance on how a team self-organizes without compromising the intent of internally (self) structured organization?
Can we synthesize new development techniques that are better adapted to each Cynefin domain?
Where are other Agile methods applicable? Could we map them to Cynefin? E.g. the ‘Tracer-bullet’ (ref 6) technique would be a ‘Probe-Sense-Respond’ approach associated with the Complex domain.
How do we know which domain we’re in? How do we shift from one domain to another within the context of a software project?
References and links:
1.
http://www.research.ibm.com/journal/sj/423/kurtz.html
“The new dynamics of strategy: Sense-making in a complex and complicated world
C. F. Kurtz and D. J. Snowden”
2.
http://tinyurl.com/yoda8h
A Leader’s Framework for Decision Making
David J. Snowden, Mary E. Boone
3.
Wikipedia, Gantt Chart
http://en.wikipedia.org/wiki/Gantt_chart
4.
Scrum website
http://www.controlchaos.com/
5
The Cone of Uncertainty
http://www.construx.com/Page.aspx?hid=1648
6.
http://www.artima.com/intv/tracer.html
Tracer Bullets and Prototypes
A Conversation with Andy Hunt and Dave Thomas, Part VIII
by Bill Venners
Posted by robertmacgregor 
Posted by robertmacgregor 
Posted by robertmacgregor 
