Cynefin is a decision-making tool, helpful in deciding what kind of decision to take in a particular context of a situation. It can be used both at a strategic level and in these series of articles I am offering ideas on how Cynefin can be used as a tactical decision-making tool by Scrum teams while doing day-to-day work.
There are several areas in Scrum where Cynefin can be applied to aid in the decision making process. It can be used in refinement to decide on the type of action to take based on classifying the context of the problem being solved.
Today, let’s discuss on the use of Cynefin day-to-day in a Sprint while doing the work. And while at it, I shall also point you to some learning concepts on what the various Cynefin domains are and what is a typical action to take in a given domain. In future articles, we will explore how to apply Cynefin techniques to refinement, retrospectives, and other areas of Scrum.
Various types of decision making require you to identify which domain you are in and how to apply appropriate action when you have identified that you are indeed in that domain context. For more information on the Cynefin domains and the framework, please refer to the Cognitive Edge video below at the end of the article.
Let’s start with the “Clear” domain – The clear domain earlier was known as the Obvious or the Simple domain.
How to identify?
This is the domain of what is called the “known knowns” – Let’s say you have a piece of work (SBI, User story, etc) where the team is completely clear in how to do the work. One or more members of the team know how to do the work, have done similar work before and therefore there is no expected ambiguity to do the work. The work is fairly straight forward.
How to decide on the type of response?
In this case, there is no “rocket science”, the team are all agreed that is is clear, so the response is “Just do it!”
Anti-patterns to look for
If the work is only easy for an “Expert” on the team and all members of the team cannot do it in an obvious way, then the work is really not “Clear” or simple. There is a teaching opportunity here for the team’s expert in that situation so that such work can be truly simple in the future for any member of the team. In such a situation there are few options as recommended below:
- A junior member of the team could take on the work with a peer-review after the work is done with the “Expert” on the team. After all this work is simple, so what really can be disastrous with delegating this piece of work?
- An “expert” on the team can pair with a “junior member” of the team to do “pair programming” in order to talk through and teach the work as the work is being done – a great opportunity to pass on learning while doing.
- If there are many members on this team who cannot do this work, and the work is actually simple, the “expert” on the team can use “mob programming” techniques to partner with other team members to swarm this to completion – another great way to spread the knowledge to rest of the team.
In the next article let’s see what we would do when a piece of work is “truly complicated” – what does this mean and what would be an appropriate response?