Archive for the ‘complexity management’ Category

Predictable & resilient programs

15 November, 2013

Too many efforts get lost in complexity or frustration.

“I wish we had known before, what we know now; we never would have started this project”

“Why don’t they listen to us?” asked the project manager himself about management

Many programs keep their focus regardless changes in the system around them

We live in a world that is dynamic and always in motion. That’s a fact. So, how can we know today, what will be the challenge of tomorrow? The answer is simple: we do not know, unless…

Starting a program is to achieve some goal that was defined yesterday. How do you manage a program that aims to achieve something that may or may not be changed while you do your utmost best to get there? How can you early recognize a changing goal that you targeted?

Organizations need to be able to apply a kind of rocket that is guided to it’s moving target by means of laser. Listen2Change offers this management guidance. We provide the laser beam that the decision maker transfers into an adjusted focus, based on new knowledge of the target and the system.

A program in a system influences the system and is impacted by unpredictable agents in that system and events outside that system.

We visualize the influences and resulting changes on regular basis (daily, weekly, ..). It enables weak signal detection to identify risks or opportunities.

For this we use short anecdotes from all stakeholders in the system. Each anacdote-teller adds predefined ‘tags’ or signifying data to their anecdote. The signification provides navigation through the hundreds of anecdotes. it unleashes understanding detailed changes and impact from the perspective of each participant.

The underlying assumption is that people exchange information via stories. The stories are triggered by open questions and gathered independent from each other.  The complete set of stories provide a true reflection of the  reality. As it is continuous it truly provides your laser beam towards a moving target.

The method provides any program or mission the means to start without a clear understanding of the final result. This result will emerge from the running program and its impact in the system.

 

Cynefin en Kanban == niet planbaar met optimaal resultaat ==

30 January, 2013

Meer en meer worden Cynefin en Kanban met elkaar in verband gebracht. En dat is niet zo gek. Immers, beiden zijn een manier om naar complexiteit te kijken. In deze blog ga ik in op de gecombineerde kracht van beide. Gecombineerd geven zij een organisatie een niet-planbaar-optimaal resultaat.

De kern van Kanban is het inzicht krijgen in de capaciteit van waarde leveren aan de klant. De hele keten wordt hierbij betrokken. Door de deel-performantie van de verschillende stappen op elkaar af te stemmen, ontstaat een optimale doorstroming op organisatie niveau.

Dit inzicht en manier van werken vormt vervolgens het uitgangspunt voor continue verbeteringen en aanpassingen. Het (gevisualiseerde) inzicht bij alle betrokkenen geeft het continue verbeterproces een natuurlijk karakter.

Cynefin is een model dat 5 probleem domeinen definieert: obvious, gecompliceerd, complex, chaotisch en disorder. Ik verwijs naar http://en.wikipedia.org/wiki/Cynefin voor een meer gedetailleerde uitleg.

Proces verbeterprogramma’s of de implementatie van Lean/Kanban in een organisatie zijn beide typische voorbeelden van complexe problemen. Complex betekent dat er geen directe relatie bestaat tussen oorzaak-gevolg. Het resultaat is niet planbaar en is alleen terugkijkend verklaarbaar. Dit in tegenstelling tot een probleem in een gesloten systeem (gecompliceerd en simpel). Daar zijn oorzaak en gevolg door analyse of categorisering te voorspellen.

De Cynefin aanpak voor complexe problemen is door gebruik van de gecombineerde kennis van experts, inzicht te krijgen in de mogelijke oplosrichtingen. Deze vormen de basis voor de volgende stap. Het starten van safe-fail `(niet fail-safe) probes. Door een continue en real-time feedback loop wordt de impact van elke probe zichtbaar. Succesvolle probes worden versterkt en uitgebreid. De niet succesvolle probes worden gestopt. In een zich ontvouwende werkelijkheid wordt een (niet gepland) optimaal resultaat bereikt.

De gecombineerde kracht zit in de opbouw van kennis over de capaciteit van de organisatie en het begrip van de mate van complexiteit van de taken (zowel in bouw als management). Het leiderschapsteam kan op basis van deze kennis en begrip de organisatie stimuleren tot continu leren en verbeteren. Het vormt de basis voor de strategie en de continue aanscherping van deze strategie.

How SenseMaking creates learning organizations by effective change programs.

8 June, 2012

The natural approach for effective change programs is full involvement of and guidance by all involved key-players. Combined with a natural learning approach this leads to effective continuous change programs and a learning organization.

What is different related to old-fashioned centrally and top-down managed change or improvement programs is the emerge of the outcome during execution of the change program. Based on the learning path, new nearby objectives are defined.

Sensemaking creates learning organizations in just 6 steps.

1    Entry criteria
Use the 6 steps only if your problem belongs to the complex domain. Obvious and complicated problems are bests solved by using standard solving techniques. See the Cynefin model for background information on the different problem domains.

2    SenseMaker design
SenseMaker® facilitates continuous, small and large scale, fine-tuned listening to all stakeholders (clients, employees, external (non-)experts). The design of SenseMaker is essential for a successful change or improvement program. A correct design ensures that the right information is distilled. An incorrect design provides not the information that the next steps need in order to be effective. It leads to frustrated stakeholders as their voice, thoughts and ideas are not heard or implemented.

3    Initial workshop
The initial workshop both validates the SenseMaker design and generates a vision of possible solutions. These possible solutions provide the first steps towards learning. Typically a Cognitive Edge method like Future Backwards is used to facilitate the workshop.

4    Experiment definition
The outcome of the initial workshop is used to define a first set of low-key-low -profile experiments. The costs and duration of each experiment is kept to a minimum. None of the experiments is expected to provide an ultimate solution to the problem.

Each experiment is described in the form of actions and indicators for feedback-signals that indicate positive or negative change. By generating additional context information, management is able to understand early (weak) signals. In this way initial actions that show promise are extended while negative indicators trigger recovery actions and choose of alternatives approaches.

5    Learning by experimentation
The initial experiments provide learning opportunities. Learning is generated both from the experiments participants and by the feedback loop continuous and real-time generated by all stakeholders using SenseMaker.

6    Emerging change
Outcome of each experiment is evaluated both by means of it’s direct outcome or delivery and by means of the feedback mechanism. Those experiments that both deliver on outcome and receives good feedback are re-evaluated for strengthening and to be continued. Those experiments that fail to deliver are stopped. Notice that learning may trigger new experiments.

Step 5 and 6 is a continuous loop. New problems or emerging insights will most likely trigger new experiments. A learning organization is created.

The above figure below shows a graphical view on experimentation in a learning organization. In the emerging process of learning, more and more practical knowledge is generated. This enables more stable experiments. By reducing the risks of failing experiments, the size (€) and duration (T).

Cynefin-agile requirements development using SenseMaker®

6 June, 2012

In a previous blog I wrote on Lean and Agile software development with Sensemaker.
In this blog I’ll further explore the actual use of Sensemaker for initial development of requirements for software projects. I also explain the process of distilling high level requirements into detailed user stories.

In standard fail-safe software development environment, requirements development is a steps-wise process from high level business- or user requests into smart allocated product component requirements.  This is a process which intertwines with constructing a Work Breakdown Structure. This breaking down enables the project to determine a high level overview on the work to be done. It is the vision of what the end product is about, without yet knowing the functionality in detail.

At this point the project decides on the approach to develop the functionality (e.g. scrum, waterfall, etc.) and how this is delivered to the customer. Typically if the environment is both complex in terms of number of requirements, the number of stakeholders involved and the frequency that requirements change, a Cynefin-agile approach is recommended.
If the set of requirements is limited and clear from the outset, just use the waterfall method or, if you can’t resists, apply agile-scrum.

In order to apply the cynefin-agile approach the use of signifying large quantities of requirements in SenseMaker is recommended. Using SenseMaker involves signifying the requirements or user-stories. Signifying can be done by the providers of the user stories, or by SenseMaker. It reduces the overhead of handling large amount of stakeholder input significantly.

Signifying provides a structure that enables the development team to view large amount of entered stories from different viewpoints. (during maintenance of the delivered product this method provides strong innovation opportunities).
Analyzing the signified set of requirements/user stories provides the product backlog.

Another element of cynefin-agile are the so-called experiments. In early stages of new development, neither the stakeholders, nor the development team have a clear picture of what is to build. So in stead of the standard fail-safe approach an Safe-Fail approach is opted.

Safe-fail provides an development environment based on learning. Only by learning the development team and other stakeholders are able to gain an understanding of the capabilities and opportunities to be developed. Experiments are started on some selected user stories from the product backlog. Mark that failures of some experiments are expected! This failure provides the must needed learning. Learning provides valuable insight in the risks and innovation possibilities.

The functionality delivered after each sprint or increment is evaluated by the team and stakeholders. Experiments are either stopped or enforced. In such way, all parts of the vision can be addressed.
The delivered functionality is co-created by the development team and all stakeholders.

Using Sensemaker® enables development teams to apply the cynefin-agile approach of safe-fail software or product development.

Out-focussed (domain-novice) facilitation in Sensemaking projects for better results

31 May, 2012

Last week I participated in a very interactive and useful workshop on Sensemaker®. Sensemaker provides a platform to gather, process, and visualize knowledge. Part of the discussions in smaller groups went on the application of Sensemaker. One of the discussed aspects was the possible result of Sensemaking projects in the context of the customer. In this blog I’ll defend a bold statement: “the ‘novice-domain’ or ‘out-focused’ facilitator is more likely to provide surprising or unexpected results then the field-expert of in-focused.”

Underlying to this statement is the pure uniqueness of Sensemaking projects. It enables large-scale fine-tuned listening to an unlimited number of people. It provides decision makers, innovation seekers and researchers in general, a method to distill hidden or weak information/knowledge. This is based on the Cynefin framework and the Sensemaker Ecology, Also check Dave Snowden’s blogs.

Before going into details some explanation. In 2006 I learned out-focussed coaching in personal and team potential exploration programs. Out-focussed means that as coach (or facilitator) you do not need to understand the underlying problem being discussed. As coach you focus on the convictions of the coachee.

An example: Let’s say I coach Peter. Peter’s question is his effectiveness in his team. In the coaching session he recalls a difficult situation in his team. In stead of asking him to explain the situation (to understand what happened) I ask him what he wanted to get out of the situation, what prevented him to achieve this and what he can do different next time. As Peter doesn’t need to explain the situation (which he already knows), we save time and address the problem at hand directly. 
At the end of the session Peter leaves with a better understanding on his own actions and convictions. The result would have been much less if I coached in-focussed. Asking questions on the situation; what his history was with the team; explaining similar situations I had been; etc.

My statement is that out-focussed (of novice-domain experts) facilitators, are able to generate more surprising knowledge and results on the subject then domain experts who integrate their expertise during the whole project. Of course the out-focused facilitator needs to be an experienced and knowledgeable (big) group facilitator. He also is an Cynefin and Sensemaking expert.

During Sensemaking workshops and in the configuration of the Sensemaker tool, an out-focused facilitator is able to extract and use more and more unexpected information from the participants. By being out-focused the facilitator is also not tempted to steer the outcome of the evaluate the (intermediate) results himself. The latter is described as being in-focused.   
Out-focused Sensemaking expert enables knowledge, insights, answers and innovation ideas to emerge. Any intervention (a word, a proposal, a gesture) from the facilitator, is a risk that this unexpected emergence of knowledge is subdued.

For the same reason, using internal Sensemaking experts is not advisable as the risk is even bigger. Unless of course the facilitator is not an domain-expert and is free from internal (political) strings.

Lean development: from safe-fail design to safe-fail experiment

24 April, 2012

Safe-fail design is tricky and almost impossible. Safe-fail experiments using the Cynefin-model and SenseMaker®-tool suite provide a much better solution.

Safe-fail-design is nearly impossible because the design-team takes early decisions which are only much later delivered to customers. When decisions are made early in the development life cycle, not all aspects, related to that decision are known. It is more then likely that issues pop up much later. Correction of faulty early design decisions becomes a costly, frustrating and sometimes technically tricky issue.

Safe-fail experiments work best in complex environments. Complex environments have many stakeholders, of which many have different backgrounds and therefore different needs, wishes and constraints. All these have to be incorporated somehow in the total set of requirements.
In this fast moving world, stakeholder needs, wishes and constraints, never stay the same for a long period of time. The designer(s) have to take this into account. But how?

As earlier mentioned, the Cynefin-model provides a solution placing design-problems in the complex domain. The linked solution of complex problems is to experiment on a small scale with different possible solutions. Those that work are continued and strengthened. Experiments that does not work are simply ended. Lean Development incorporates experimentation.
Using lean development, the complete development team designs, builds, tests and delivers a small (set of) functionality within 2 or 3 weeks. This way an environment for experimentation is created for the development team to find out if they actually do have a correct common understanding on the meaning of the needs, constraints and wishes of the stakeholders. This enables safe-fail experimentation.

This solves the first part of the problem. The team is able to deliver to the stakeholder that functionality that the team believes is exactly what the stakeholder needs. If it is not, the team has learned a valuable lesson against low cost. The stakeholder is content that the development team listens to his needs and that they take him seriously.

Now to the aspect of the huge amount of stakeholders and their variation. Additionally stakeholders may not be located near the development team, and they might speak different languages.
Also typically stakeholders do not know what they actually want to have. They do not know what is possible. And if they know all the aforementioned, they often lack the words to bring across exactly what they need to the design-team.

Story telling is a proven way to share information on a complex problem. By letting stakeholders tell their (vision and user)-stories, they focus on what is important and critical for them. Stakeholders add additional meaning to their requirement specs (through SenseMaking). This eanables the development team to identify and evaluate patterns that are present in the metadata to understand the requirements in the stories and priotize them. The software and the characterization process supports different languages.

Combined, the 2 approaches provide a solution for organizations to handle many critical stakeholders who move with their views and opinions in this fast emerging world.
Safe-fail experiments support functionality to emerge during development.

In a later blog I’ll describe how to get from a vision-level of user stories to a user story which a development/sprint team can deliver in one sprint.

How to address project complexity

5 April, 2012

In an earlier blog I wrote on complexity in project management and the Cynefin© model.
Target of this blog is to deepen the understanding in applying Cynefin©–based approaches to complex projects.

My appliance of Cynefin© is pragmatic. As I am not a theorist, I might get things wrong, as long as it works for projects.

A problem is either simple, complicated, complex or chaotic. A fifth type is disorder, which stands for such problems of which we can’t tell in what domain the problem belongs. In this blog I don’t address disorder problems.

The figure below is a graphic representation of the Cynefin© model from Wikipedia.


Simple problems are characterized by a known and well established cause-effect. Don’t waste any time, just plan de corrective action as you know it’s outcome.
E.g. if a team member lacks experience in a specific task, you send him to a course or training, or assign an on-the-job coach.

When developing simple software functionality, any development type will do (e.g. waterfall or iterative).

Complicated problems cannot be solved in the same manner as simple problems. For this an expert or team of experts analyze the problem to provide a solution. A typical complicated problem is how to structure known data in a database or set up a project in a stable problem domain. The project knows its stakeholders. Once the set of requirements are defined they are more or less stable. Project, organization and customer are confident in a positive result.

Regarding software functionality, also complicated problems may be addressed by any development type. Although here the risk for change and (upfront) unknown additional problems, might call for a iterative based development. Iterative based development enables emerging functionality, thus reducing late and fundamental changes in design and code.

When projects face complexity as well as many and largely unknown and varying requirements, both customer and organization are faced with a big uncertainty and risk regarding the outcome of the project. The high level work breakdown structure is largely based on expected work to be done. Estimations on effort, resources and needed time to determine project costs is at this point a major guessing game.

Typical for these large projects is that only at the end of the project, both project, customer and organization are able to explain how and why the project evolved as it did. Project outcome emerged from running the project. Prediction up front was not possible.

These projects are typically located in the complex domain with a probe-sense-respond approach.  In practice this means that at project outset, the objective is provided together with the why. Then the project set’s out to identify the major business value and starts working on these.

In order to identify as much needs, wishes and constraints as possible a narrative approach can be applied. In this initial narrative phase the project sets up a website where all stakeholders are invited to share their stories. The stories are provided a title and provided additional meaning (or signifying). Note that up front it is not known how many narratives or requirements are necessary. This is only know in retrospect.

The stories form the basis on which the project defines a detailed set of requirements. Because in these types of projects many requirements emerge only during project execution, these basic set of stories are continuously revisited at regular intervals.

In software development typical iterative approaches with high level of stakeholder involvement is used for these types of projects. It becomes directly very clear that both on the stakeholders side as well as on the organizational side, embracing slow-growing certainty and emerging understanding of project deliverables, is critical for success.

In the complex domain project outcome emerges from project execution. The problem domain is known and understood. Complexity is based on the fact that at the outset, not all needs, wishes and constraints are known. Even stronger, perhaps not all stakeholders are at that point known.

Projects in the chaotic domain are projects in an unknown uncharted domain. There not yet any experts to tell the project what is the best approach. So the defined approached is act-sense-respond. Just start working in any direction, ensure the involved cost, time and risks are limited. At regular intervals the result is evaluated. Positive outcomes are strengthened or continued. Negative results are stopped.
Slow but certain the project learns and builds expertise. Both customer and organization support and learn with the project.

For both the customer and organization, the challenge is how to fund these types of projects. I will get back later in this aspect. I’ll also address the use of narrative in requirements definition in a later blog.

Warning. As in all models it is important not to follow the model but to understand it. Applicability works as long as it works for you.

Nut van gedocumenteerde processen en afspraken; op het werk en thuis.

2 April, 2012

1 zelfstandige heeft weinig reden om (veel) processen te documenteren. Redenen die ik kan bedenken zijn checklijstjes en de stappen voor weinig voorkomende werkzaamheden. Bij het laatste voorbeeld voorkomt het opschrijven wat je moet doen, dat je het later mogelijk opnieuw moet uitzoeken wat nu ook alweer precies de stappen waren en waar je informatie de vorige keer hebt bewaard.

Een alleenstaande kan doen en laten wat hij wil. Eten wat hij wil, muziek luisteren enz. Het is wel handig als hij bankafschriften bij elkaar bewaard. Het invullen van de belastingaangifte gaat ook gemakkelijker als de informatie hiervoor op bekende plekken te vinden is.

2 mensen in een team moeten al veel afstemmen. Waar staat welke informatie, begrijp ik jouw informatie, op welke manier informeren wij elkaar en kunnen wij afgaan op wat eerder is afgesproken? Hier geldt dat je of iedere dag met elkaar overlegt over alles wat van belang is. Zo niet, dan werkt het gemakkelijk als jij weet waar je collega zijn informatie bewaard. Ook is het fijn als hij dit altijd op dezelfde manier doet.

Een koppel moet meer afstemmen dan een alleenstaande. Wat wil jij? Waar ben jij hoe laat? Wat gaan we eten? Doe jij boodschappen? Waar heb je die brief gelegd?
Het is duidelijke. Wil je geen ruzies en frustraties dan is het handig dat er afspraken worden gemaakt en nagekomen.

3 of veel mensen in een organisatie moeten overeenstemming bereiken op welke manier zij samenwerken. Frustratie over dingen die niet (juist/tijdig) gedaan worden liggen op de loer. Afspraken moeten continu worden herijkt om te zien of zij nog wel doelmatig zijn.

Een gezin met kinderen is een groot deel van de tijd bezig werk en andere betrokkenen (ouders, vriendjes, school/kinderopvang, werk) met elkaar af te stemmen. Afspraken zijn hier nog belangrijker omdat de verschillende stakeholders niet te verenigen zijn. En dan wordt nog één ding duidelijk. Het maken alles afdekkende afspraken en deze vastleggen, blijkt ineens niet voldoende te zijn.
Kinderen veranderen, regels die gisteren nog (of juist nog niet) nodig waren, blijken vandaag niet meer nodig te zijn. Ook de omgeving blijkt ineens onvoorspelbaar te zijn. Het vastleggen van afspraken is ineens een complexe aangelegenheid. Vaak blijkt alleen achteraf wat de manier van aanpak was geweest.

Zo kom ik op 2 conclusies:

1, alles afdekkende regels maken niet noodzakelijkerwijs een ‘werkend’ en gelukkig gezin. Binnen de grenzen van wat mogelijk is geniet je van de vrijheden en veiligheid die door de afspraken worden gecreëerd.
Dit geldt ook binnen een professionele omgeving. Mensen en de omgeving bepalen welke (typen) regels en afspraken nodig zijn. Dit kun je niet 1-op-1 aan een model ophangen.

2, is bij een gezin complexiteit te managen door liefde, vergevingsgezindheid en improviseren, in een professionele omgeving is dit (veelal) niet mogelijk. Hier zijn technieken voor het omgaan met complexiteit nodig. Deze technieken geven inzicht in de mate van complexiteit en passende manier van aanpak.

How to deal with complexity before it kills your project

29 March, 2012

We live in an unpredictable world. Our relationships (family, friends, society), our products and organizational structures are complex. This complexity is ignored by most of us. On every level in our lives we ignore this complexity and act as if all our problems are simple.
On the same playing field we manage most of our projects as if they act in a fixed, stable environment. But every project manager knows that at project start most of the requirements are unclear, our (fixed) budget is wrong. No wonder project members and customers are frustrated and our project managers burned down!
I had my fair share of contribution to this situation. As a CMMI expert I told organizations and project managers how they were expected to run projects. Based on the knowledge of today, I sincerely apologize.

Projects
Typical projects deal with dozens, if not hundreds of stakeholders. Each of whom has personal-, team-, organizational targets, (limiting and changing) convictions, (hidden) agenda’s, political agenda’s etc. You’ll get the picture on how growling difficult it is for any project manager to successfully deliver a project.
To worsen things, projects (and organizations) are managed as if people, like machines, are capable of programmable repeatable executing intelligent tasks.
The solution then is to treat projects as complex systems. For this we need language and solutions capable dealing with complex problems.

Cynefin©
The solution to handle complexity and uncertainty, is to recognize the solution method  for the problem at hand. For this reason the Cynefin© model is helpful. Cynefin© describes 4 domains to categorize problems: simple, complicated, complex and chaotic. Depending in which domain your problem situates, it provides mechanisms to deal with the problem.
In the simple domain has a clear relationship between cause and effect. The problem is addressed by sensing the problem (I can’t read), categorize (it is dark) and respond (switch on the light)
Problems in the complicated domain require some form of investigation. Typically you would hire or go to an expert to get it fixed. This is done by sensing (my arm hurts) analyze (doctor identifies a broken arm) and response (applies a plaster bandage).
In a complex environment (covering most of the project management problems) the relationship between cause and effect is not known up front. It can only be determined afterwards. Therefore the approach here is to react by means of probe (try a small subset of requirements), sense (let the customer evaluate), response (redo if not ok, else continue with next subset).
The chaotic domain is not a domain where good or best practices work. Here acting is done (stop the traffic) sensing applied (2 cars, 1 truck, 5 injured) followed by response (you call for more support, you do traffic control, you attend to the wounded).

Scrum
Scrum in its core is essential an approach for complex problems. It is time-framed method in which a team addresses a subset of the total customer requests. At the end of each sprint the customer evaluates the delivered part of the solution. It applies the probe, sense and response approach from the Cynefin© model.
Introduction of scrum on project level only, without appliance of agile principles in other areas (e.g. product management, portfolio management), the positive effects of scrum will soon vaporize.

Software development and project management
Joseph Pelrine explains in his paper “on understanding software agility” 1 that most software development problems are situated in the complicated domain, whereas project management problems are mostly situated in the complex or chaotic domain.
This further supports the above statement that organizations need to apply lean principles on management then only on software development.

deal with complexity
In a next blog I’ll get more practical and discuss methods to support an agile approach in software development.
For more information about applying Cynefin based tools and methods I refer to TOP innosense. TOP innosense is a network partner of Cognitive Edge in The Netherlands.

1) On Understanding Software Agility—A Social Complexity Point Of View E:CO Issue Vol. 13 Nos. 1-2 2011 pp. 26-37