Posts Tagged ‘requirements development’

Human Sensor Networks

13 March, 2013

Michael Cheveldave from Cognitive Edge wrote a blog on human sensor networks. It is excellent reading material. This blog contains the highlights of Michael’s explanation, with references to Agile IT development and DevOps.

By changing human sensor networks into customer sensor networks, I merely focus on the application of CSN in IT Agile development life cycles. You may easily argue to keep human sensor networks, as also own employees or other relevant stakeholders provide feedback using the CSN system.

Michael explains the role SenseMaker® plays in delivering organizations the value of human sensor networks.

… by engaging a large number of people in the process of making sense of their everyday experiences and observations, and allowing meaning to be effectively layered on such experiences we stimulate a network of agents in the systems to make sense of the system themselves.

By integrating different customer groups in functionality definition we will

  • easier and sooner understand real customer needs
  • build a fruitful relationship with the customer-base
  • create pro-active sponsors at the customers of the product
  • enable the customer-base to better understand their needs, and innovative possibilities that the organization can provide
  • better understand which private betas to be tested by which user group type
  • better understand collected quantitative data by means of this qualitative data

… think about how traditional approaches often emphasise the value of external experts or selectively privilege a small team within the company on such strategic decisions.

The decision making process which functionality to build and release

  • focusses more quickly to that functionality actually needed by customers
  • enables, together with feature flags, different features to be released to different customers types (based on their needs)

Sales and marketing collect valuable information on their targeted customer groups. Information is achieved cheaper, faster and more reliable then based on traditional marketing research.

The approach (a human sensor network AK) allows for the executive team to tap into the distributed cognition, intelligence, scanning, and knowledge of a broader network in a way that effectively informs key strategic decisions.

Reading experiences, ideas and frustrations from actual users, exposes product management, marketing managers and developers to the impact of their initial ideas on what functionality is needed. When well guided, the team will quickly and easily understand existing patterns and needs. Future releases are more effective and efficient.

The ultimate result is a learning organization. People from different organizational silo’s co-interpret and co-decide based on both trends and contextual information. This leads to an organizational wide understanding of and believe in the business goals and opportunities.

Advertisements

Applying SenseMaker® in scrum projects

2 July, 2012

In earlier blogs I showed how SenseMaking software ecology and the Cynefin model support Agile development. In this blog I’ll explain how to SenseMaker® supports gathering large amounts of user stories or feedback. These stories are input for the product back log and the product vision.

SenseMaker® enables software developing organizations to involve large groups of users or customers in both the requirements gathering phase and the maintenance phase. This gives them an advantage over their competitors. The input and feedback ensure that the new functions are adequate and fulfill a concrete demand.

Story tellers enter their stories on website. After entering their stories they are asked to provide additional meaning to their stories. This provides for valuable additional information. This is called signification and forms the core of the requirements gathering process. The signification framework is tailor-made. It structures the hundreds or thousands of stories in such a way that the development team is able to analyze them effectively.

In a next step the development team(s) analyze the entered stories. During the analysis the team transfers the raw user stories into a product back log. The backlog reflects the concrete demand of the users and customers. As the categorization incorporates a prioritization the development teams knows which functionality is to transferred to the sprint team first.

Emerging functionality
Once the sprint teams deliver their first functionality to the users, SenseMaker enable real-time feedback. This mechanism allows end-users to evaluate and try out new functionality and provide instant feedback. Because of the automated and real-time feedback mechanism the development is able to deliver only functionality for which is a real demand. It is also possible to try out new stuff end-users have not seen before.

The above described mechanisms provides a great advantage for the organization. First it doesn’t waste valuable development capacity on irrelevant functionality. Second, both first–end-users and developers feel appreciated as their ideas and thoughts are directly used. Thirdly because the organization is able to produce new functionality in a lean and flexible manner, the organization gains the recognition being innovative and customer-centric.

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.