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).

Sensemaking based employee satisfaction surveys for happy employees

7 June, 2012

Sensemaking based surveys supports organizations that wants to engage all their employees in strategic and tactical decision making, innovation and knowledge generator.
We at TOP innosense make this promise a guarantee.

Everybody knows those standard surveys which state for example that the satisfaction rose from 6.7 last year to 6.8 this year. Everybody a bonus! But what these types of old fashioned surveys lack, is the actual engagement of all staff in the overall and daily strategic and tactical decision making, innovation and knowledge generator if the company. What a waste!

How to accomplish this? Simple by using the Cynefin framework and the supporting Sensemaking® software.

Managing an organization or any sized group of people is a complex task. There are too many stakeholders, events or other types of modulators that interact continuously and unpredictable. Any change can only be explained on hindsight. So starting with a predefined plan on any level (strategic or tactical) is doomed to fail.

Sensemaking lets the organization continuous listening to the (coffee machine) anecdotes or micro-stories. It enables all employees to enter their thoughts and ideas. The gathering is either written or spoken text, a picture or a photo. The anecdotes are provided additional meaning by the original authors. When also external stakeholders are invited to enter their thoughts, ideas and opinions in the Sensemaking database, the organization has an in depth knowledge on what is at stake below the surface,

Cynefin shows how to addressed and manage complex problems. Experiments supports learning and identifying in which direction the company and it’s strategy flows. Because of the agile approach, the company is continuously and fluently able to manoeuvre effectively.

Anyone in the organization is able to see the stories entered (continuous monitoring). Because the process is real time, your story is read and used tomorrow. This enables quick adaption of decisions directly after decisions have been made. This in turn enables adjusting decisions early in the process, when the cost or repair is still low, or the impact still limited.

What of all the above is the result on the morale of the employees? I guess you know 😉

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.

a winner approach to innovation using early adopters in your customer-base

5 June, 2012

Many organizations fail to integrate the mass user community in their innovation programs. SenseMaker® is a tool which enables you to do just that. Use technology early adopters to co-drive your innovation program to impress the big-mass of regular users.

Early adopters are proud people. They love to prove to pragmatists and conservatives the use and fanciness of gadgets and new technology. They also have continuous new idea’s for even fancier and more hi-tech gadgets and functionality.

SenseMaker enables you to continuously interact with these early adopters to extract all their combined ideas and innovation opportunities into the Sensemaker database. When this innovation-gathering process is integrated with an agile development environment you are able to bring those idea’s to the early adopters within a few weeks.

This very simple mechanism generates 2 major marketing opportunities for your organization. First it gives you a close connection to the early adopters as you prove over and over again you listen and deliver. Your organization can be trusted.

The other major advantage is that for the pragmatists and conservatives under your customers, you become this innovative company which is again and again able to surprise the market.

A simple and therefore highly effective marketing mechanism. SenseMaker at the heart of your innovation program using the power of your customer-base.

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.

Why software projects needs Sensemaker®

22 May, 2012

Agile software development enables software developing organizations to deliver functionality at regular and small intervals. In order to do this effectively the organization needs to understand the needs or problems of the customer. But what if the customer does not know exactly what he needs/wants or if there are (too) many customers to be satisfied? In this blog I’ll explain how Sensemaker® provides a solution to the afore mentioned challenges.

In Software projects input (requirements) is not generally generated from the public. Intern experts (architects, domain experts, business analysts, ..) provide input to designers and programmers. In many areas this methods is working fine.
However, there are domains (e.g. civll society market) in which the domain experts need input from customer representatives to provide them insight in what functionality needs to be build. If this is input not provided, the delivered software is not successful with unsatisfied customer(s).

Sensemaker enables large scale and fine tuned listening. No matter how many customers, where on the globe they reside and what language they speak, you can easily collect their user stories (fragments in Sensemaker terminology) or feedback.
Sensemaking method provides means for the customer to add value to their stories. This added value is part of the core functionality. Without interference of your local domain experts, you get the knowledge directly from the fragment-providers. The added value is used to structure the gathered fragments. This way it provides input to you local functionality builders.

The Agile-software-development and Sensemaker combination enable large scale feedback loops. The input-build-deliver-feedback loop can be as short as 3 weeks. The loop-size is determined by the sprint-size. Sensemaker provides realtime feedback.

Because Sensemaker provides multiple views on the collected fragments it becomes possible to release functionality per location or customer-type.

In short, Sensemaker provide software development organizations the power to listen continuous and real time to hundreds of thousands of customers. Listening also enables feedback on delivered functionality (after each iteration or sprint). The organization effectively knows exactly the needs, wishes and constraints of each and groups of customers.

Chinese Medicine, process change programs and Cynefin

15 May, 2012

Many change programs fail due to a lack of understanding the real pain in the organization. Many change programs just repeat a trick that worked earlier. It is like a doctor telling you that, without proper examination, he treats you the same way he did previous patients.

In China, the original Chinese medicine is applied complementary to the Western medicine. Learning about Chinese medicine is like taking a trip into ancient knowledge management. The appreciation of the knowledge of our human body, the plants and herbs (which are all provided by nature..) forms the basis and power of Chinese Medicine.

When I write complementary I do actually mean complementary. In a Chinese hospital a patient chooses at entry which treatment he desires. During ‘Western’ treatment acupuncture or a herb-treatment is added, to reduce pain and trigger the internal body recovery system.

Our typical process change programs are typically Western oriented. We analyze were we are (what the illness is) where we want to be (cured) and what the path to cure is.
In this approach we ignore the nature part of the system we are about to change. Living human beings which, typically, show complex behavior.

Luckily, like Chinese Medicine, we have an approach to make sense of our complex organizations we are about the change. The anecdotes people tell at the coffee machines, during lunch breaks of after-work drinks, contain valuable information to define a appropriate cure-path.

For this reason we use a method in which we collect as many anecdotes as we possibly can. By listing to these anecdotes (story-collection) we learn what the system/body/organization tells us. It provides the means to appropriate leverage decisions and actions.

To enhance the level of detail and to ensure anecdotes are properly understood, we let the people themselves provide meaning to their anecdotes. This enables realtime collection without ‘expert’ interference.

Supporting Sensemaker® software suite provides the automation side. Enabling the management to get the needed level of understanding on their organization.
Like the doctor in Chinese Medicine, the management team now understands where to apply pressure (acupuncture) or to strengthen the healing and energy level (herb-cure).

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.