Lean StartUp

from on 19.03.2015
0
Lean StartUp

Of all the practices that have to come together to create a piece of software, the engineering of the requirement may very well be the most difficult and least understood. A requirement is somebodies need or want, but it is not a product or a solution. Requirements Engineers are creators of artefacts that define needs so that a product can be implemented. A solution can obviously only be useful, when the requirements are captured accurately and therefore the elicitation of the requirements has to be the success criterion for Requirements Engineers. Once the wants and needs are captured, engineering the solution is rather well understood.

However, wants and needs are complicated concepts. They are full of perception and are subject to external influences. We can easily be mislead into having certain wants, and they can be distorted by social pressures such as the Jones’s new car or the latest ad we saw on TV. This does not only affect complex socially constructed wants like status symbols. People struggle to accurately identify their most basic needs: The average UK household throws away £60 of perfectly good food every month. Mostly food that we thought we needed when we went to the shops, but then found out we did not.

If Requirements Engineering around the rather simple and repetitive “what’s for dinner” problem is hard, you cannot expect anyone to accurately tell you whether a particular software feature solving a complex problem is a real requirement. Most people will think they need far more than they actually do. As for the food shopping problem, they tend to think they do have all these requirements, but once you build solutions, many of them end up at the software equivalent to the back of the fridge.

But, if people cannot tell us what the true needs are, Requirement Engineers will have to guess which ones are real and which ones are superfluous. One way to approach this task is to become great at guessing, and many tools support us with this: We use Brainstorming and Lateral Thinking, create personas, we switch from “The system shall …” to “As a [role], I want to”, we map stories, we try MoSCoW, we show and tell regularly, etc. This way, we receive better requirements and improved priorities and our perceived success rate increases significantly. However, it is difficult to measure by how much, because these techniques are at their core heuristic and designed that domain experts eventually reveal their knowledge and wisdom and tell you what the requirements are. Since 64% of software features are rarely or never used (Standish group, 2002), Requirements Engineers may not be as successful as they could be. They tend to err on the safe side and also capture most things in order not to forget something important. But as with the food example, this is an expensive approach that has negative impact on quality: We end up having fewer resources for the things we do need, when we invest in things that we end up not using.

The fundamental idea of Lean Startup is to address the difficulty of having to engineer requirements in times of uncertainty. Sometimes requirements are well known, such as for regulatory, safety or compliance demands. Sometimes there is a limited user base for an application, who know what they need. Sometimes a well known and widely used legacy system has to be reverse engineered. Lean Startup is a better fit where a vision is implemented, and where there is a risk of insufficient demand for a product. It is also helpful when the domain experts have an abundance of requirements for software features to choose from. Lean Startup’s empirical approach to engineering will put these ideas to the test, before accepting them as given.

So, how does it work?

“If a man will begin with certainties, he shall end in doubts; but if he will be content to begin with doubts, he shall end in certainties.” —Francis Bacon (1605) The Advancement of Learning, Book 1, v, 8

You still use the established ways to identify wants and needs, but you regard requirements as speculative assumptions that need to be put to the test. Let’s say, you were asked to create an application that offers free online programming courses and your customer is convinced that there is a high level requirement for this idea. You set up an experiment that is designed that their hypothesis can be falsified. For this, you could get out of the building and interview some students, some pensioners or anybody else you think may be relevant. But even better than relying on what people will tell you is observe what they do with this idea. You could create a trivial application, just a landing page with no functionality, and advertise it as offering free online programming courses in order to direct some traffic there. If your advertising does not produce any clicks, the idea probably was not that good after all and your experiment has failed. This may be disappointing for your customer, but you have saved them from building a sophisticated application that people would have ignored. However, if the experiment has attracted a few hundred people, great – you are looking at a real requirement!

Let’s get a few steps ahead. You carry out an experiment offering free courses for various programming languages to subscribed users. It turns out that enough people are prepared to enrol and share their email address with you and you have confirmed that you have a market! You proceed with an experiment offering a JavaScript course and enough of your subscribers sign up for it. Now you know that there is a specific requirement for JavaScript. You offer a first lesson and you hit your targets again! You offer a link to a future live exercise environment that will allow people to try out what they have learned in the lesson. Let’s assume your users make no attempt using it.

This setback does not have to shatter all your customer’s dreams just now. As in a real laboratory, some experiments fail for technical reasons. Maybe you just did something wrong? Maybe the idea is good, but the link simply was not obvious enough? There is only one way to find out, and this is by setting up another experiment with an improved interface to coax people into navigating to the exercise environment that you intend to build next. You might have various options to improve your user guidance, and you could set up A/B testing to find out which one works best. Should your experiment succeed now, you have proof that the requirement exists, or that you have managed to create it with your improved interface.

The important thing to remember is to only ever start implementing a feature once you have demonstrated that there is sufficient demand for it. This is the Lean in Lean Startup: Only observed demand pulls in implementation work. Traditionally, we are pushing our implementations onto our users based on assumed demand.

I'm pivoting to another man

 

Back to our example. Should all your improvement attempts fail, there really is no market for your feature. But at this point, you have enough data that the core vision is great and people use the application. Even though the exercise environment may have been part of this vision, you can safely let go of it now. In Lean Startup language, you pivot.

You can invest the time you saved by not implementing a feature that nobody would have used and put another idea to the test. When you have a number of validated assumptions, I am sure your Requirements Engineer will have identified plenty of ideas of what could be tried next. Perhaps you change your strategy from on-line programming courses to giving one to one tuition. It could be something very different: Flickr used to be a MMORPG with an image sharing feature. The game apparently wasn’t that good.

The good

A methodology drives system architecture. In a world, where you do not have to prove that individual requirements actually exist, there is no incentive to implement a mechanism to get confirmation. When you have faith in your Requirements Engineer, why implement a way to monitor how customers use your application? If you are using a Lean Startup approach, you will need feature toggles and analytics for your A/B testing. You will also need continuous deployment in order to drop experiments and improvements in and out of production at runtime to check whether they work. It may seem to you that allowing your team to do this was madness. But if you have a process that takes 3 months to get a change from inception into production to only then find out (if you care to look) that nobody uses the new feature – isn’t that madness?

In this sense, Lean Startup is an enabler of good architecture and practices. However, creating a Lean Startup environment that allows you to carry out experiments may seem expensive. But you will avoid implementing many useless features, and this is where you save time and costs.

The bad

Clearly, Lean Startup was created with a start-up context in mind. Unfortunately, this is a bad marketing mistake. In many organisations managers take technical decisions, and they are unlikely to even consider an approach labelled Lean Startup, because they operate in established industries. But there are technical difficulties to use it in legacy environments as well: You will have to revise the version control and branching strategy. You might have to come off a heavy weight application server. You will have to learn how to use feature toggles and how to get usage data out of your application. You will also have to find a way to get a change into and out of production in minutes.

But in fact, this is comparatively simple. It is far harder to change a non-lean non-startup culture that is endemic in many organisations. You also can’t be a little Lean Startup by using Google analytics in a legacy environment, just as you can’t be a little bit Agile by having a daily standup once a week. You may find that you have to change the culture of your organisation to enable Lean Startup, and that is hard.

The ugly

You have to turn your users into guinea pigs. In classical Requirement Engineering, you almost elevate your domain experts to the rank of High Priests sitting close to the Gods and you crave for them to share their views with you. In Lean Startup, you still seek their advice and inspiration, because they do indeed possess knowledge and wisdom. But you use the requirements they give to you to design experiments and you do not regard them as commandments. Your experimental data will end up invalidating some of their assumptions, which they may not appreciate.

You will also have to take care about your early adopters. It is not nice to navigate to a feature you are interested in just to find out that it might be built at some point. Your users might not understand what you are trying to achieve and they could end up being alienated by having been turned into the specimen of an experiment.

Conclusion

Requirements Engineering has not had its Enlightenment. It is stuck in the Dark Ages where truths are expected to be revealed. Requirements Engineers have developed and used an abundance of techniques to elicit revelations from their domain experts. It turns out that in many situations revealed requirements go beyond actual needs and sometimes miss them at all. In an enlightened Requirements Engineering function, the role of the Requirements Engineer changes. To be successful, they will still interact with domain experts. They will still use the same heuristic techniques to get ideas what the requirements could be. But they will put given requirements to the test using experiments and science. They will have to learn not to trust authority beyond putting in the effort of setting up an experiment that confirms or invalidates their views.

Lean Startup is a first approach to give Requirements Engineering an empirical method. It may not be the best possible or the last. Like Agile, it is not only a technique in the toolbox, it gives Requirement Engineering a fundamentally different approach.  

Write a comment

Your e-mail address will not be published or shared with third parties. Fields marked with * are required.