2 Fundamental ↑
No. 2 — Acknowledge Uncertainty
We humans often feel a tendency to portray ourselves as knowledgable, competent and masterful, especially when our work is being observed and judged by others.
However, there are situations in which we are none of these, and feigning certainty in these situations is not likely to lead to positive outcomes.
Dan Snowden’s Cynefin framework offers a useful guide to differing approaches that are appropriate for situations with varying degrees of certainty.
The Cynefin framework suggests four different approaches, starting with situations of high certainty, and proceeding to situations with progressively lower degrees of certainty.
In Simple situations, the appropriate approach is to Sense, Categorize and then Respond, making use of an established best practice.
In Complicated situations, the appropriate approach is to Sense, Analyze and then Respond, making use of expert knowledge.
In Complex situations, the recommended approach is to Probe, Sense and then Respond, allowing new knowledge to emerge.
In Chaotic situations, the appropriate approach is to Act, Sense and then Respond, learning and adjusting as you go.
Another way to think about these four categories would be to use the following terms:
Mechanical – In the simplest of situations, a mechanical or proceduralized response is most appropriate. For example, a user requests the addition of a new field to an existing screen in an established application. Usually only a brief discussion is required to determine which field type is to be added to the database, and which sort of user interface widget is to be added to the screen.
Analytical – In more complicated situations, some serious analysis is required. Let’s say we want to add some new functionality to an existing system, to help a user track a package after an order has been placed. Various questions naturally arise. What sort of information should be presented to the user? In what form – a textual display, or a map? And when should the information be provided – only when the user requests it, or at other times as well? This is more than simply a case of plopping the request into one of a few predefined categories.
Experimental – In complex situations, analysis based on existing knowledge is not enough, and some experimentation is called for. Let’s say your design team comes up with two very different user interfaces to accomplish a new task. Which of them will be preferable to most users? In a case like this, it’s appropriate to build a prototype of some sort, and perform some usability testing to allow new knowledge to emerge.
Crisis – In crisis mode, something unexpected has happened, and there is no opportunity for analysis or experimentation – immediate action is necessary. For example, your new system has been deployed for a week, and then suddenly crashes, for no obvious reason. In a situation like this, clearly someone needs to take charge and begin taking action without the luxury of waiting for much analysis or experimentation.
From a Knowledge Management perspective, it is useful to think about gradually moving particular situations down this scale, towards greater degrees of certainty. Once past an immediate crisis, then experimentation may be used, and once the results of experiments are known, then expert knowledge may be built, and once all possibilities have been categorized, then procedures may be written, or perhaps even automated, to deal with similar situations in the future.
On software development projects, it is critically important for everyone, but especially leaders, to acknowledge a legitimate spectrum of uncertainty, and to be able to draw from a palette of differing approaches to deal with these varying situations.
When considering the application of the Cynefin framework to software development, it is important to remember a few salient points:
Simple, mechanical tasks should generally be automated, or codified by standards and procedures, and so your developers should not be spending a lot of time in the simple, mechanical corner of the diagram.
Any project worth doing will be attempting at least some things that have not been done before, at least by this particular team, and so there will be some things in the complex, experimental quadrant.
In practice, it is often difficult to discern the difference between complicated and complex – between situations requiring experimentation vs. situations in which analysis is sufficient.
This idea of acknowledging uncertainty has far-reaching implications, and should be kept in mind when considering the following big ideas as well:
- Uncertainty partially accounts for the The Inconvenient Nature of Software Development;
- The balance between analysis and experimentation is one more dimension along which Software Development is a Balancing Act;
- The ideas to Automate Repetitive Tasks is another reason why your development team should be spending little time performing simple, mechanical tasks;
- When you Use Things Already Known to Work, this is one way to minimize the amount of complex, experimental work your team has to contend with;
- Show Rather than Tell is one way to validate the success of your analysis;
- Plan-Do-Check-Act is a structured means of implementing the “Probe-Sense-Respond” approach to experimentation;
- When you Shorten Feedback Loops, you help to validate that you’ve done sufficient experimentation;
- When you Understand the Arc of Your Project, it’s important to have a sense of how much complex work requiring experimentation is still in front of you, and to get that behind you as early as possible;
- The need to manage uncertainty is another reason why Entrepreneurial Leadership is needed for software development.