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

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.

Advertisements

Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: