Why different types of work matter
This blog post contains a chapter from my book and is one of the most important Agile topics you need to understand. Not knowing when to apply Agile methods results in significant waste and can cause conflict. I experienced this recently when running an Agile transformation with a team working on scheduling mainframe batch jobs. This work was fundamentally unsuitable for Agile methods. They were very concerned about me pushing an iterative and incremental approach onto them. I didn’t do this because I recognised the type of work they were doing.
This chapter is applicable even if you aren’t scaling. Many of the chapters are similar to this, in that you don’t have to be scaling Agile to get value from them. Each chapter starts with a problem statement and shows you how to solve it.
If you want to know more about the book and how I wrote it, please see this link.
Chapter 9 - Not understanding the type of shaping needed
One of the frequent misunderstandings of Agile methods is when and how to apply them. Let's say I'm working on a VAT calculator that has a set of business rules to follow, should I apply the same way of working as someone who's building new screens for a customer? This can be summarised in our problem below:
The problem of not understanding when it is most appropriate to apply Agile methods
affects organisations that are delivering products to customers
the impact is confusion with the value of Agile and how to implement it successfully
Introducing the Cynefin Framework
The Cynefin ® Framework was invented by Dave Snowden in 1999 and its initial application focussed on how a manager should act (or make sense of) situations with different levels of complexity. It has since been broadened beyond management.
This sense making technique, helps you analyse your situation using domains. Each domain helps you to work out the most appropriate way to act. This model can be extended to help us understand the different types of work we will encounter and how we should deal with them. In the Cynefin Framework below you can see 4 main domains. We'll now look at each in turn and see how they can help us.
Cynefin Framework as at February 2021 by Dave Snowden – thecynefin.co
The Cynefin® Framework as of February 2021—reproduced under Creative Commons Attribution 4.0 International licence from Cynefin.io (2021).
Applied to our work
How I am using the framework is not universally agreed upon, but I find it helpful, and those I have taught have as well.
Clear
Here in the clear domain, we have a simple task like updating a colour scheme on each screen. The problem is easily understood and can be optimised, leading us to a "Best Practice" single solution. We can create repeatable processes here. Project planning using a Gantt chart with tasks and resources will be a good solution to managing a backlog of work. As the work is clear, we wouldn't need much analysis to solve the problem.
Here's how to use the full framework
sense - Gather details about the problem
categorise - Identify it as a known type of problem
respond - Follow the best practice solution
How to manage this work - Consider a basic Gantt chart with the typical delivery time allocated to each piece of work. You should not need to break these pieces of work down into a lot of detailed tasks.
Complicated
I'll start with an example to help explain what this domain means. Let's say I'm building a VAT rate calculator. I have created calculators before and know the options I have that will work. I could perhaps create a separate program for the calculator or add it to an existing one. I may have different ways of deploying it, to its own server, or as part of an existing one. As an expert, I can do analysis to figure out the solution. The fact that there can be more than one solution means we will choose the one that's most appropriate. In the model, this is defined as "Good practice".
If I do a lot of work in this domain the introduction of Agile ways of working with its focus on emergent design, rapid feedback and user testing may seem nonsensical to me. In fact, when working in domains where people are doing repeatable complicated analysis Agile methods may add unnecessary overhead. An example of this was an Agile transformation I ran in a bank, it had a mainframe team who were writing complicated scheduling jobs. The idea of breaking these down into smaller deliverables, like user stories, and incrementally delivering and testing parts of them wasn't helpful.
Here's how to use the full framework
sense - Gather details about the problem
analyse - Analyse the problem and work out the best solution
respond - Build the best solution
How to manage this work - Gantt charts with detailed tasks work well in this domain. Make sure you set aside enough time for analysis. Incremental delivery, which means delivering something in stages, is a good option if it is possible. We can also run this in a scaled environment where each team's work is planned out in detail.
Complex
In this domain, we can't use analysis alone to give us the right solution. We are in the realm of very tricky problems that can't easily be analysed, such as those requiring customer opinion. In this domain, we are firmly in the best area for Agile methods. This strongly relates to the Agile value, "Responding to change over following a plan". We should be using feedback to achieve better outcomes by building, learning, and changing as we go.
One of the main reasons analysis fails here is that people don't know what they want until they see it. The biggest mistake that was being made over and over again was to deliver products with an uncertain outcome (complex) as if it had a certain one (complicated). Now it isn't that you don't receive the feedback, it is just the high cost of getting it late. Imagine a customer waiting a long time for version 1 of a completed product and them not liking it, or worse still, not being able to use it.
This can still happen when people are using "Agile" delivery methods. This is where we actually practice analysis based techniques under the guise of Agile. For example, we could be doing analysis and creating a big backlog of user stories up front, then building them in 2 week iterations, and finally, after several months we go live. This is when the customer sees the work for the first time. There is no test and learn here, we are not practicing Agile at all, even though we may be using some popular Agile artefacts.
So how do I know if I'm in this domain? We can use the assumptions mapping technique. This looks for assumptions across:
Feasibility - can we build it?
Desirability - do people want this?
Viability - does the business model make sense? i.e. can we cost efficiently build and run this?
If we identify desirability assumptions this provides a strong indicator that we're in this domain. Anything that requires a customer's opinion means we cannot use analysis to determine the best result. We need to test with the customer, ideally early. Testing our feasibility risks should also be considered, especially if they would take a long time to solve them using analysis. One common test and learn technique is building a technical prototype in a timeboxed spike.
How to manage this work - This is where you should use Agile delivery methods. Use techniques like assumptions mapping to understand where your main risks to success are.
Here's how to use the full framework
probe - Run experiments to better understand the problem and suitable solutions
sense - Gather key findings
respond - Adjust the solution based on key findings
Chaotic
In this domain, we need to fix something quickly and don't have time for a long test and learn cycle. Something could be badly wrong and we need to apply multiple fixes fast to hopefully find the right one. This isn't very common when building features, and would more likely be in situations like when a live server is crashing, or when we have a hacker who's got into the system. We may then act by deploying multiple fixes simultaneously to see which works. "Novel practice" is found here, where new or interesting solutions arise.
Here's how to use the full framework
act - Do something quickly to see if it fixes a problem
sense - Gather key findings
respond - Adjust the solution based on key findings
From Complex to Complicated?
Agile is often described as value driven where scope is variable with cost and time fixed. In traditional delivery methods, the focus is on being plan driven, where scope is fixed and time and cost vary. In reality, plan driven and value driven often end up with a desire to fix all three, but Agile in its true form would vary scope simply because it does not seek to do all the analysis up front.
In Agile we seek to fix cost and time, which means we must have some level of certainty in order to do this. This is why identifying and removing the big assumptions up front is so important. Leaving these big risks to be tested after we have fixed our timescales will add a significant likelihood of blow out. Working through these risks up front allows us to move towards being able to fix time, and even though we should still be practicing test and learn, it is not as radical as questioning the whole solution. With these big assumptions removed, we are still unlikely to move back into the complicated domain and therefore go back to relying solely on analysis.
Cynefin Framework and scaled Agile
As we can be running a really complex set up when scaling you should always consider how much up front analysis you do. Even if you are in the complicated domain doing all the analysis up front can be very expensive. This is just the sheer effort of getting everything right in one go. In this case break the work down into smaller parts, then incrementally analyse and deliver it. If you have many teams contributing to an end-to-end process look to get this integrated early. The analysis required to get large scale systems working end-to-end can be very time consuming. Therefore, delivering end-to-end functionality with a test and learn approach is highly recommended and will significantly reduce timescale risk.
Summary
The Cynefin Framework is a powerful tool for understanding the situation you are in, enabling you to act appropriately. I find this very valuable for aligning teams on why Agile matters and when it is best to use it.