Sergey Shishkin

software craftsmanship in practice

Lean Startup For Your Agile Toolbox

I was at the local agile meet-up when the same old topic of Scrum dysfunctions and a lack of process guidance arose. In my opinion the ability to act in absence of process guidance is really a sign of a competent practitioner as opposed to a “certified process follower”. Without clear prescriptions the richness of one’s own toolbox is essential. Recent study of the Lean Startup methodology and especially the read of Running Lean by Ash Maurya gave me some more ideas of what to do when the process of choice is silent.

Missing User Roles

“As a [role] I want [feature] so that [benefit].” The most important part of a user story is not the feature but rather the user role and the benefit he wants to achieve. It has been proven effective for ages in the agile world to put personas in the user stories, but customer development makes it obligatory. You have to know your customer segments and their must-have problems in order to provide benefit to the user. If your user stories don’t mention a particular customer group and a problem (which you’ve validated qualitatively), chances are you’re building some sort of waste. Note that “working software” and “definition of done” is all waste, if the problem it solves is not worth solving.

Backlog Prioritization

Juggling backlog priorities is often compared with art, politics, black magic, blind guesses, coin flipping – with anything but a scientific method. One scientific approach to prioritization would be to eliminate risks highest first and thus accelerate learning. After qualitative validation of the biggest assumptions it’s time to verify them quantitatively. So building an experiment for quantitative verification of the riskiest hypothesis is clearly the most important thing right now. And if the simplest possible way to build that experiment is by giving a working software in the users’ hands, great.

When building the solution one increment at a time, constantly trace the features back to the customer segments and their problems. Is this feature a part of the minimal viable product for that particular segment? If not, chances are you’re building something for a new customer segment which has to be validated and verified first.

The lean canvas (and its ancestor, the business model canvas, for that matter too) is a perfect tool to capture two important aspects of of a product idea: cost structure and revenue streams. A product idea can have multiple revenue streams, one for each customer segment. Analyzing which feature contributes to which revenue stream can make prioritization a lot easier.

Acceptance Criteria

This is the new definition of DONE: You’re done, when you’ve validated, verified or denied a hypothesis. The difference between validation and verification being that you validate qualitatively and verify quantitatively. Registering either a positive or a negative signal when talking to people is qualitative validation. Turning 10% newsletter recipients into paying customers is quantitative verification.

Look at the build-measure-learn principle. When defining the acceptance criteria for a user story, think about learning first. What hypothesis are you trying to verify and what measurable metric to use for it? If nothing comes to mind, chances are you’re not developing, because development implies learning.

Systems Thinking (In Closing)

It’s really about the holistic view of the value chain. You can pretend to be doing Scrum or some other agile method just in the IT, but local optimization will inevitably bite you in the ass. Customer development techniques are a powerful tool to help a product owner with his homework – backlog grooming and prioritization. Keeping a constant eye on the aspects of the lean canvas helps making uncomfortable decisions with a reason and confidence.

[Update 11th Oct 2012]: Improved wording used for the user story.