Posts Tagged ‘lean development’

Applying customer sensor networks (CSN) in Lean Startup and DevOps teams

7 March, 2013

The Lean Startup movement addresses the issue to match product functionality to market demand. For this a contextual external customer feedback loop needs to be implemented. A customer sensor network using SenseMaker® provides online, real-time and continuous contextual feedback, closing the feedback loop.

SenseMaker uses an online collector website that lets customers provide feedback by means of narratives. Each narrative gets a title. The customers also provide additional meaning to their narrative. The system categorizes feedback based on the meaning given by the customers. This avoids overhead during analysis for the organization. The SenseMaker analysis software supports the evaluation of the feedback. Enabling effective and short evaluation time. This feedback mechanism enables evaluation of large amounts of feedback from different customer or user groups.

The analysis software provides both quantitative and qualitative evaluation. The quantitative aspects provide insight if functionality acceptance level. The qualitative aspects provide deeper insight in innovation opportunities. For example alternative or unforeseen use of the functionality. On the other side of the same scale, the feedback points to a risk or threat. For example that the new functionality is not well accepted by early innovators.

Customer sensor networks integrate with Lean Startup pilot experiments and DevOps private beta’s. It also provides for DevOps implementation the needed internal and external feedback for development. The internal feedback from operations to development is useful in case when the DevOps consists of multiple team in different locations.

CSN makes it possible that for some types of development, product management joins DevOps teams to form ProDevOps. This really reduces overhead and transition costs. It enables a whole new approach to app development in a true Agile manner.


SenseMaker is a Cognitive Edge product linking micro-narratives with human sense-making to create advanced decision support, research and monitoring capability in both large and small organisations.


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.