Posts Tagged ‘cynefin’

Giving customers their legitimate place in software development.

26 August, 2013

Being really lean means that only that functionality customers use (and are willing to pay for) is developed and released. That means being so agile, that trends and patterns in customer needs/wishes and problems are continuously understood and drive service/product development and delivery.

For this the ‘voice of the customer’ needs to be continuously monitored. The result of the listening is to be analyzed and integrated in the development life cycle (e.g. product backlogs).

As not all new functionality or innovations originate from customers, also the ‘voice of the internal-experts needs to be continuously monitored. This knowledge, experiences and ideas is integrated in the development life cycle as well.

In earlier blogs I wrote in Customer Sensor Networks. Being the same subject, it lacks the natural place in the present developments in agile software development methods. By lack of a better word I use in this blog the term CusDevCus which stands for Customer-Development-Customer. With Development I mean the complete development lifecycle including Marketing, Sales, Product Management, Development, Release and Operations, ect. I am open for any better term.

Core elements of CusDevCus are:

  1. Integrated customer feedback (or external expert feedback) into the development life cycle loop to create integrated feedback,. Integrated feedback
    1. is unlimited in size, the larger the amount of participants, the more effective the next release,
    2. gains insight in trends and weak signals for present and future functionality,
    3. is generated in the form of testing developed functionality as well as new (unrelated) ideas.
  2. Integrated employee (as internal experts) feedback with the same aspects explained under the integrated customer feedback and
    1. open to all employees, continuously…
  3. The feedback combines both quantitative and qualitative information.
  4. Each feedback is signified by the feedback provider. This provides navigation through large amount of feedback.
  5. The Product Owner analyses the feedback-patterns. The combined quantitative and qualitative information enables both a deep understanding of the explicit functionality-feedback and the high level patterns.
  6. Because the feedback is integrated in agile development methods (like Scrum, Kanban, OpenUP, ..) experimentation of new functionality is possible in a semi-real environment using real customers.  This seriously reduces R&D and Sales and Marketing effort and optimizes organizational learning.
  7. CusDevCus fully builds on devOps, BusDevOps lean startup and other agile evolutions.
  8. CusDevCus is based on open feedback in the form of narratives. That means there are no preformatted testforms or questionnaires for feedback.
  9. Of course the open format feedback does not eliminate the need for professional testing!

10. CusDevCus focuses on different user groups. Different user groups have different needs. They reveal different uses (or no use) of functionality.

In my view the above described next step in agile (software) development is a natural one. The main question is whether companies are able to make the mental shift to integrate the customer as described in the software development lifecycle.

Customer Sensor Networks

12 March, 2013

Agile software development has 2 major positive attributes: the short release cycle and the possibility to integrate release-feedback rapidly in the product backlog. In this blog Customer Sensor Networks (CSN) are explained as a mechanism to integrate the Agile software development life cycle with customer feedback effectively.

CSN enables insight in what functionally is needed or wanted. To understand customer needs can be a challenge. In many cases customers do not have any idea what is possible in terms of functionality.

What is possible is in the heads of the developers, architects., analysts or product managers. But what is technically possible is not always wanted or needed by the customers.

The short feedback loop with a short time to market, enables product management to ‘test’ how features are accepted by (parts of) the customer-base. Implementing CSN lets the organization understand effort- and cost-effectively what functionality customers are willing to pay for. It is a good idea to involve the marketing strategy in the development life cycle.

Which customers to select is based on their expertise or area of interest. A variety of customer-types increases the variety of feedback. Innovators will appreciate other aspects then customers in the early or late majority groups. Which profiles you select, will be based on the business and business objectives.

Customer Sensor Network

Figure 1: Customer Sensor Network implementation.

The CSN explained here is based on Sense Maker® software of Cognitive Edge.

The CSN uses an online collector website which pre-processed the information for the product owner and the DevOps teams. Pre-processing is done by the CSN and based on the information provided by the customers.

The Feedback analysis consists of functional evaluation and an emotional aspect. The functional aspects cover things like how features are used or what is missing. The emotional aspect lets product owner en DevOps team members understand what (missing) functionality does with customers. The emotional evaluation is important to understand and support marketing aspects of the product.

Techniques like private beta’s or feature flags enable teams to manipulate releases to different test- or customer groups.

Figure 1 also shows typical takt times in a CSN system. Takt time and wait time lets the DevOps team and product owner optimize flow and adjust overall throughput time with the expectations of the different test groups. This example shows a sprint of 3 weeks. The test period is set for 1 week. Then the feedback is evaluated 2 weeks after the DevOps team finished work. Depending on the expectations of the customer test groups, the waiting time for the customer groups to learn what the effect of their testing has been, might be too long.

Using customers in the development life cycle presents some challenges to the organization. Aspects to take into consideration are incentives and how they (in)formally integrate in the communication plans. Incentives may differ per customer type. For example, for innovator’s their name can be listed on the product website as contributors, or they are invited on some regular basis to the development site to discuss with the DevOps teams and product owners. The early and late majority groups can be given a free license of the product.

CSN provides an effective organizational and team learning mechanism. New idea’s can be tested rapidly and (cost-)effectively. CSN triggers a business approach to Agile development. Developers, maintenance people, product management and marketing all learn as a team what it is that makes their customers happy or dissatisfied.

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.

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.

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.