Ralph Stacey de l’Université de Hertfordshire a mis au point une matrice qu’il nomme « The Stacey Matrix ». Cette matrice permet de prendre connaissance du degré de complexité d’une situation selon le niveau d’incertitude et le niveau d’accord face à la situation.
This will be the last post in the series about process visualization in professional services, specifically within the context of applying the Kanban method and one of its core practices, visualization. Earlier in this series:
How to understand the process as collaborative discovery and enrichment of knowledge and to visualize accumulation of knowledge and not operations and handoffs. Note that we depart here from the notion that a process is an algorithm made of prescribed steps. We explore the process as it actually happens through imperfect decisions and actions of people working in it. The first post in the series included an example and more examples followed (1, 2) How to map processes and create such visualizations with groups of people. To keep this post relatively compact, I only included the recipes here. Observations and learning from applying this approach in practice
Now it’s time to write about the thinking behind the knowledge discovery process, the mapping techniques I presented, and the explanation of what I observed by applying them.
Simply put, we have to respect the complexity of the system – and the group of people working together to perform some creative tasks to deliver their service is a complex adaptive system. Basic understanding of the Cynefin framework is essential here.
Driving adaptability through transitional or chaotic periods: How to stay the course and keep up when everything about the landscape and market is changing?
In today's world of rapid change, growth and competition, we need new tools for maximizing our business's ability to calmly weather the storm and stay on course. You'll learn strategy and tactics for not only maintaining your strategic direction but also find out how to effectively capitalize on the chaotic climate; all without change-fatigue from your teams.
Beta Codex, ou comment rendre le travail à nouveau efficace Comment mettre en œuvre des cellules décentralisées, innovantes et autonomes, pour faire face aux c…
If the governance is in the Chaotic domain, do not think that using Scrum or any other Agile technique will solve your problems; what you will end up with is Acephalic Agile, as described by Andy Wilson’s post. You must solve management problems with management, not methodology.
Perhaps we can summarize this in the following table: Governance domain Disorder/ Chaotic Complex Complicated Simple Development domain Complex/ Complicated/ Simple Crisis management (of governance) Scrum Up-front planning Anything Disorder/ Chaotic Crisis management (of both code and governance) Crisis management (of code)
I have had an interest in David Snowden's Cynefin framework for understanding complexity for some years now, and so it has been really interesting to read his blogs on how he is updating the model and adding a finer layer of granularity. He has made the latest versions available on Flickr under a creative commons…
Over the past few weeks, I introduced you to a sense-making model developed by Dave Snowden. His Cynefin framework can serve as a map to give you some orientation in challenging situations of decis…
Application of the Cynefin Framework to show suitability of Scrum to certain types of projects or situations.
Mickael Ruau's insight:
Checklist for ascertaining whether a given situation is “Complex”
The following characteristics provide an opportunity to determine whether the given situation, problem, opportunity or project falls into the “Complex” domain of the Cynefin framework, thereby making it suitable for Scrum.
Is there an opportunity to explore to learn about the problem, then inspect and then adapt? YES / NO?
Does the solution require an innovative / creative approach? YES / NO?
Can we create a safe-fail environment for experimentation to discover patterns? YES / NO?
Can we increase the levels of interaction / communication? YES / NO?
Is this opportunity for a solution to emerge? YES / NO?
Is knowing in hindsight acceptable? YES / NO?
Is the situation more unpredictable than predictable? YES / NO?
How can Cynefin enhance management in the face of chaos and complexity? Cynefin intro Cynefin proposes certain principles that decision makers can apply to understand and take action (practice) in different types of situations, viz. involving simple, complicated, complex, or chaotic systems. For starters, you may like to watch David Snowden, the inventor of Cynefin…
The software industry has a dismal track record when it comes to predicting and planning in the face of uncertainty. There are a significant number of biases that prevent us from learning, including cognitive biases and compensation structures. Statistical approaches to predictions can be successful if we expend the effort to create learning-based models such as Monte Carlo simulations. Highly uncertain environments are best exploited using the iterative learning models inherent to Agile methods.
Extremely uncertain, non-deterministic environments are best exploited by the incremental learning model of hypothesis testing (Hypothesis-Driven Development) and learning to embrace the discomfort associated with uncertainty.
The definition of DevOps, offered by Donovan Brown is "The union of people, process, and products to enable continuous delivery of value to our customers." It accentuates the importance of continuous delivery of value. Let's discuss how experimentation is at the heart of modern development practices.
Mickael Ruau's insight:
Hypothesis-driven development is based on a series of experiments to validate or disprove a hypothesis in a complex problem domain where we have unknown-unknowns. We want to find viable ideas or fail fast. Instead of developing a monolithic solution and performing a big-bang release, we iterate through hypotheses, evaluating how features perform and, most importantly, how and if customers use them.
Template:We believe {customer/business segment} wants {product/feature/service} because {value proposition}.
Example:We believe that users want to be able to select different themes because it will result in improved user satisfaction. We expect 50% or more users to select a non-default theme and to see a 5% increase in user engagement.
Every experiment must be based on a hypothesis, have a measurable conclusion, and contribute to feature and overall product learning. For each experiment, consider these steps:
Observe your user
Define a hypothesis and an experiment to assess the hypothesis
Define clear success criteria (e.g., a 5% increase in user engagement)
Run the experiment
Evaluate the results and either accept or reject the hypothesis
Repeat
Let's have another look at our sample release with eight hypothetical features.
When we deploy each feature, we can observe user behavior and feedback, and prove or disprove the hypothesis that motivated the deployment. As you can see, the experiment fails for features 2 and 6, allowing us to fail-fast and remove them from the solution. We do not want to carry waste that is not delivering value or delighting our users! The experiment for feature 3 is inconclusive, so we adapt the feature, repeat the experiment, and perform A/B testing in Release X.2. Based on observations, we identify the variant feature 3.2 as the winner and re-deploy in release X.3. We only expose the features that passed the experiment and satisfy the users.
If you don’t understand you cannot adapt – If it works just keep doing it; however what to do if it stops working. Then you are out of your depth and since you did not understand it in the first instance you cannot effectively cope with it
Cookbook – Everyone can cook with a cookbook given the right kitchen with the right tools and all ingredients are available. However, if you lack tools or ingredients you need a ‘chef’ someone who understand the theory and knows the practice. By that time the cookbook is useless to the novice.
Consciousness is a distributed function – the brain, nervous system, hormonal system, … all have an impact in how we work. Consciousness is what a knowledge worker works with.
Body of Knowledge – BoK requires theory and practice. You need the theory and 2-3 years of practice (nervous system) to acquire the skills. Apprenticeship and serving time is key. Theory and practice combined are called praxis. Praxis makes perfect.
Mickael Ruau's insight:
Exaptation – using something for something else – far more successful then adaption. Exaptation requires granular elements for recombination. Adaption causes slow change; exaptation is a far more successful strategy for innovation.
Architecture in Software – needs to allow for exaptation. Fairly fine grained objects, good scaffolding allow for free interaction and combination. Software development is a service based provision.
Taking a linear process and drawing it as a circle doesn’t make it non-linear (ditto not faster) – Scrum-er-Fall
Coherence – not perfect data but usable, semantically meaningful. Often we have to make decisions on data which is coherent but not absolute.
People make decisions based on ingrained patterns on past experience – whatever data available, it will be filtered by past experiences.
Complex Adaptive Systems (CAS) cannot be eliminated – we have to manage the non-linear causal dependencies and resulting turbulence in unordered systems.
Meaning exists between the gaps of people, not the people themselves – it is the interaction what counts, the relationship between is more important then the things themselves. Don’t change the person, change the way they interact. Manage networks, the vague gaps between things
Agents are anything that reacts within/withon a system – people, ideas, groups, myth
In the Simple domain – agents are fully controlled
In the Chaos domain – no constraints on the agents, wisdom of the crowds; chaotic system have value but they are complicated to create
In the Complex domain – beneficial coherence through boundary management and attractors. We manage the emergence. (Emergence requires less resources then other processes). You can only understand it while interacting with it.
The Simple domain is adjacent to the Chaos domain – If an unordered problem is approached in a Simple fashion it will transition straight to Chaos through an catastrophic event.
We like order, like to conform
The more bureaucracy the more informal networks in an enterprise
Hindsight doesn’t lead to foresight
Stupidity and Intelligence with Deception are the same thing.
Cynefin Review Part 7 – Finding Your Place on the Framework Welcome to the final part in my Cynefin Review series. Now we have defined the dynamics at a high level of detail, it is time to find out where you and your organisation sits on the model for the problems that you face daily, There i
These are the projects where there is a (lethal) combination of uncertainty about the value of the project and the execution of the project (how to deliver the value). In other words there is a combination of human uncertainty and technological uncertainty. Typically, these are projects surrounded by conflict, disagreement and ambiguity. It is exactly the combination of human uncertainty and technological uncertainty that is the breeding ground for rapidly cascading failure in these projects. Typical projects in this domain are large projects with substantial re-architecting of the existing infrastructure or capabilities.
Many development projects (that should be in the extension domain) also end up in the sensitive domain because of lack of trust between the customer and the supplier or lack of knowledge of how to set up such projects (E.g. setting the project up as a waterfall instead of iterations). Often times organizations move themselves into the sensitive/chaos domain by not properly aligning themselves around a common purpose. Whatever the reason for this – lack of trust, lack of vision, lack of management know-how -, in the end it leads to local optimization.
Still, often times the chaos/sensitivity comes from external factors. As in the large re-engineering project that was mentioned above. The organization is confronted with a rapidly changing technology landscape and needs to adapt its (large and complex) software to that and at the same time there is a high pressure to deliver new features as the competitive pressure in the market grows. It needs to change the engine of the car while driving at 100mph so to speak.
Role defining – setting job and task descriptions Decision-making – find the “best” choice Tight structuring – use chain of command and prioritize or limit simple actions Knowing – decide and tell others what to do Staying the course – align and maintain focus
Roles, Tools and Approaches for Complex
Relationship building – working with patterns of interaction Sense making – collective interpretation Loose coupling – support communities of practice and add more degrees of freedom Learning – act/learn/plan at the same time Notice emergent directions – building on what works
Chaos; Beyond complexity lies chaos. Of course one doesn’t need to look too far in the management world to see examples of chaos within management systems. The global financial system, which many may have previously considered to be a complicated system was clearly a complex system on the edge of chaos, before the actions of a single bank helped to triggered the global economic chaos in September 2008.
Chaos is by its nature very hard to control, yet some would argue that real innovation emerges on “the edge of chaos”. According to the Cynefin framework what is needed to move a system out of chaos is some action, which will either exacerbate the chaos or move some of the chaos into more manageable complex or complicated environments that can then be dealt with.
It is within the chaos domain that the importance of leadership is apparent, where some one, just one person is needed to take a lead and attempt to encourage the crowd to follow their lead. It is also said that such leadership is instinctive to some folk and perhaps cannot be taught/learned.
We now move on to explore Cynefin within the context of Information Technology
Cynefin-and-Information-Technology Amidst the complexity simple patterns emerge
The Cynefin framework helps make sense of when and why we use different design methods - e.g. When is up-front research essential and when is it overkill? When…
So how do you ensure that your team doesn't form a system that is dumber than its parts?
Policies and procedures are a solution appropriate to the Simple realm - they assume that the correct action is simply to read the script and carry out the action. Yet our work is mostly conducted within Complex, not Simple, problem domains. So is it any surprise that the emergent interactions of numerous simple Policy documents within a complex environment can generate unexpected and frequently unwelcome outcomes?
It seems obvious to me that we need to depend more on sensible, guided, decisions and we need to rely less on inflexible, unpredictably-interacting processes and policies. Encouraging decisions guided by evidence, gained empirically within your specific problem space, rather than simply implementing blind policy is one way to ensure that you manage a team that is at least as smart as its parts.
Using the Cynefin, leaders are enabled to better understand how to approach whatever is happening. This blog aims to help you understand the framework.
Now there are purists within the Cynefin fold who argue that physics states that chaotic is a lower energy state than complex and in their field they are correct. But here we are talking about human systems and those are open not closed. The nature of humans is that we create connections and constraints intuitively as well as deliberately and we do so very quickly. To create a system with no effective constraints, a state of near randomness takes a lot of energy both in creation and to sustain the state. Liminality allows us to create additional transitionary domains and I’ll be interested if Rob attempts to draw them and I may attempt it myself. However for the purpose of this post I want to address the three liminal states within Cynefin. If you want the visualisation look at the green areas in yesterday’s post.
Between complex and complicated (one way) In the main areas of the complex domain we understand what is possible (or plausible) through parallel safe-to-fail experiments but as patterns emerge and stabilise we enter the liminal domain. We now have a sense of what is possible and we can radically limit the range of our experiments but we still need to carry out more testing, iterate to test understanding and so on before we can make the transition too complicated. When we make that transition its a big commitment so we need to hold as long as possible before doing so. I show this one as open as towards the left the gradient between complex and complicated is shallow and easy to traverse, while as it approaches disorder it is steeper. Within Disorder (two way) The big moment of insight for me when I finalised the liminal version was the realisation that it resolved the nature of disorder. In the green area we are in transition between domains, its a moment of legitimate uncertainty and tension in which we ontological uncertainty (not the case in the two liminal states above and below) and there are many directions we can take. In the grey area we are adjacent to the catastrophic fold as we have no idea of what domain we are in, and we have no idea that such ignorance is an issue. So the liminal area is transitionary, the other area is inauthentic disorder. Between chaos and complicated (two way) This is shown as a closed state in contrast with that between complicated and complex. The reason is hinted at above – to create chaos a state of no effective constraints is difficult and costly. It requires boundaries to project it and it is always in danger of collapse in either direction so careful maintenance and frequent scanning are needed – this is a high energy requirement but powerful for innovation and distributed decision making using wisdom of crowds methods in products such as MassSense,
The boundary between chaotic and obvious is not liminal as there is no transition it is sudden. It is two way, but one way happens with greater ease. Climbing back up the cliff is normally a mistake, easier to shift into the liminal domain with complexity and then start the cycle again – but I will deal with that when I map dynamics onto the liminal version of Cynefin tomorrow.
By the way – I suspect the exploration of liminality will generate a lot more ideas and posts over the next couple of years.
Alicia Juarrrero famously coined the phrase like bramble bushes in a thicket to describe a complex adaptive system and it is a title Kurtz and I used in this paper which represents early thinking on organisational design and networks. In a complex system you need to define your identity focal points and manage your connections, rather then get out the flow charting template and create excessive structure. Bramble bushes bear fruit, but also prick the unwary; structured flow diagrams are safe in the sense of the absence of novelty, the absence of risk and the absence of imagination.
To get content containing either thought or leadership enter:
To get content containing both thought and leadership enter:
To get content containing the expression thought leadership enter:
You can enter several keywords and you can refine them whenever you want. Our suggestion engine uses more signals but entering a few keywords here will rapidly give you great content to curate.
Your new post is loading...
Scoop.it!
