One of the big elephants in every development room: developers refrain from speaking to customers. Most development teams see their work as ‘developing code’. They don’t see their work as ‘developing great software that users truly need’.
I’m a big fan of lean startup. I’m also a big fan of scrum. I think lean startup is a fantastic addition to any scrum team; it addresses the elephant.
Scrum tells a team that they’d better work in iterations. It tells them that the product backlog is the input for each iteration. But it doesn’t tell them where the backlog items come from. That’s the role of the product owner. While I believe it’s good to split that role, it also has drawbacks. The PO talks to stakeholders, users and is responsible for product success. The team assumes ‘what’ needs to be built is not theirs to influence; they influence ‘how’ they build it. But that’s the catch: this distances the development team from ‘reality’.
In the lean startup, the whole (startup) team gathers around ‘validated learning’. Their goal with each release is to learn as much as possible from users. Towards that end, they create MVP’s: an early version of a new product that allows a team to collect the maximum amount of validated learning (learning based on real data gathering rather than guesses about the future) about customers. They decide what their assumptions are about the users and their product; they define hypotheses to ‘test’ these assumptions; they decide as a team what MVP can provide data to learn whether their assumptions are right.
The lean startup gives the impression we’re talking about startups; small teams of young guys wanting to build the next big thing. But that’s not the case. Lean startup is being used in the biggest companies around the globe (GE, Intuit, Toyota). And it’s not only about ‘startup products’; the process can be applied to any big functionality in your software or any process improvement in your company. The core idea is understanding what people actually want, not what we think they want. Imagine a development team with every individual wanting to understand what their users actually want. Would that team produce better results than your current team?
In your next sprint, start with a short 90-minute session before the sprint planning. Take your top 3 user stories from the backlog. For each of the user stories, go through the following exercise:
The goal in a lean startup is to minimize waste. What typically happens is that development teams just ‘develop the user stories’. Nobody will question whether this is the right functionality to build (because we assume the PO knows that). In reality, most of our user stories originate from managers. They communicate to the PO. Their ideas stem from their own thinking. Oftentimes, they don’t stem from real user needs. So if we allow for those ideas to enter our development cycle, how much waste are we really building? From all the user stories built in the past 6 months by your team, how many are being used by customers today? How many of those are truly bringing value to your users? And how do you know?
With the above process, your team challenges everything. They’ll go out to test whether the feature is required by users before building it. If they don’t, they’ll build the feature, release it to users and THEN find out whether they need it or not. Any feature built that nobody uses represents waste. How much waste is your team building?
