Can you recognize systems and what approach is the best one for each?
Ralph Stacey with his ‘Stacey Matrix’, helped us in recognizing the main system typologies, what characteristics they have and how to cope with them. This matrix is quite simple.
The X-axis of the matrix represents the level of certainty on how the system works. More specifically, what are the relationships and the linkages between the cause and effect: in few words the behaviors of the systems in response to predefined stimulus.
The Y-axis represents the level of agreement on the system’s behavior just mentioned, among us: group of people or project team.
When a system has a finite set of responses, which can be easily related to an input, it means that the relation between cause and effect are clear. These systems are called simple systems, which can be approached with the best practices, taking advantage of previous experience.
If you are wondering you should use agile with projects related to those systems, I suggest NO. It is not necessary.
If we only move the slider along the X or Y axis, diminishing the level of certainty or agreement, we fall into the area of the complicated systems. These system are less predictable. They still continue to be understandable, but not in advance and only after a deep inspection, looking at its internal mechanisms and rules. With systems like these ones, we can apply good practices, which help you to get closer to the solution.
Let me give you an example: think for a moment of a watch.
If you aren’t a watchmaker, a watch is something, at least for me, very, very complicated. But I’m certain that if we spend time analyzing its gears, wheels, screws and how they are related each other, sooner or later, we will be able to disassemble and reassemble it, let’s say, “quite easily”.
If you are wondering you should use agile with projects related to those systems, I respond SOMETIMES IT COULD HELP.
Moving far from certainty and agreement, it arrives a place that is called “complexity land“.
Within this land cause and effect cannot be nor predicted, neither analyzed, but only perceived in retrospective.
In such a land we must be awake, attentive and plan for few steps at a time.
What is most important, then, is to analyze the results of any action, in order to decide whether to continue that way or change our plans accordingly to the feedback obtained. If you are wondering you should use agile with projects related to those systems, my answer is YES, YOU MUST.
The successful pattern here is:
- break complexity up in small chunks,
- plan iteratively for each chunk,
- inspect the results,
- adapt your future plans accordingly to the feedback just obtained.
Finally it arrives the realm of the chaos.
A realm where certainty and agreement are foreigners and the only approach here is to explore such a realm. The only suggestion I can give you here, is good luck!