Agile in software development: Cynefin perspective
According to Agile Alliance, Agile is the ability to create and respond to change. It is a way of dealing with an uncertain and turbulent environment. In software development, Agile is known as a set of frameworks and practices, based on certain values and principles. Yet, this sounds a bit theoretical and vague, isn’t it? Early in my career as a Business Analyst, I used to often ask myself how to put the theory into practice. What kind of problems is best to solve by applying Agile? When to apply Agile in software development? Should I always try to promote Agile in my projects? Then I came across the Cynefin framework and it all made sense. I started applying it in my work, as it gave me the answers. In this article, you will learn how to apply Cynefin to better understand problems. When to apply Agile in software development?
What is Cynefin?
Cynefin is a sense-making and decision-making framework, created in 1999 by Dave Snowden. The framework divides the system in which we operate. It makes decisions into four main domains – Obvious, Complicated, Complex and Chaotic. This allows you to understand where you are in the complex adaptive system. What form of experimentation you should be using to make decisions at that time? When talking about software development, Cynefin helps you understand the type of problem you are trying to solve. Thus, it makes it easier for you to choose the right method. Whether it's a more conventional (waterfall) approach or an iterative, empirical approach (agile).
Cynefin domains and Agile in software development
Obvious
The first domain put us in a simply ordered environment. This is where we face the so-called “Known-Knowns”. Those are well-known problems with expected output and workaround. The cause and effect are obvious, and the decisions have a simple pattern – “sense-categorize-respond”. Only one solution to the problem is possible, also known as best practice. Simple / Obvious problems make use of templating and off-the-shelf tools and solutions. Usually, those problems are easy to solve and automate. We can take order processing as an example. The worker receives an order, categorizes it (respond) and follows company standards and procedures (best practices).
Complicated
In the second domain, we are facing “known unknowns”. The connection between cause and effect may not be so obvious. Some form of analysis and expertise is needed to solve the problem. The decision process here follows the scheme of “sense-analyse-respond”. In other words, you need to assess the situation, do some analysis (with the help of experts) and decide on the best response. It is important to note, that, unlike the previous domain, here we have a few possible solutions to the problem – good practices. For example, building a house is a complicated problem. Yes, there is no single house type suitable for all environments. However, with the right level of analysis and team of experts, you can come up with an ordered plan (response). In the IT domain, think of tailoring an off-the-shelf enterprise business solution to meet a particular use case. Take for example an ERP implementation project – you have the software, yet, a thorough business analysis is required to fine-tune it. Here, popular project management frameworks like PMP and PRINCE2 come into play. They imply the application of good, well-known practices.
Complex
In the third domain, the uncertainty continues to grow. We are facing unordered systems or the “unknown unknowns”. Here we don’t have information about the connection between cause and effect, we need to collect data. The recommended decision-making process is “probe-sense-respond”. We need to try to do something (experiment), understand what happened (gather feedback) and then respond to it. Most of the time, we are dealing with such problems in the context of software development. This is also the domain in which, we at Accedia are usually solving problems for our clients. When you start to build a new software product, there are many uncertainties and a hundred problems. That’s why you cannot just create an end-to-end preliminary plan (like in the complicated scenario). To get a sense of the problem and cut the risk, you need to start validating the thesis and assumptions (probe) in small cycles (increments). After each iteration, you receive feedback and respond. Does this sound familiar? Yes, you are right – this is the domain in which Agile methodologies like Scrum shine and add value. If we look at the definition of Scrum, it addresses complex problems empirically. This means that decisions are based on what is already known and experienced. That’s why Scrum is so effective for solving problems in the Complex system domain. It just provides you with all the tools to experiment and learn more about the system, sprint after sprint.
Chaos
The fourth domain is characterized by a total disorder. The relationship between cause and effect is absent. Here, no frameworks or good practices apply. We don’t have time to do experiments, to collect and analyze information, but rather we must act. That is to get a better understanding of what is and is not stable, and then to turn a chaos problem into a complex one. The proposed strategy for chaotic problems is “act-sense-respond”. This context is often related to emergencies. For example, introducing an unknown bug into the latest production release. In such a scenario, you have no choice, but to act immediately. Oftentimes, these are the situations when we discover novel practices Usually, Startup companies operate in the context of a chaos system. Some of them fail as they are not able to turn the chaos into a complex situation, or even better - complicated or simple.
To sum up
Cynefin is a great framework that can give you a different perspective. It helps you better understand what kind of problem your company is dealing with. Finally, it allows you to make more informed decisions about whether you should use an iterative approach and apply Agile in software development or stick to a more traditional approach.