Before we go ahead and start developing features for the high-value, high impact stories we need to stop and look at the bigger picture. As we covered in part 1 of this series, taking 6-12 months to build a software solution is too risky. But what if the problem is big and complex and will take a long time to build the solution? You know that it is going to take a great deal of time and effort, but you also know you cannot afford to take a long time to get your product to market. So, what do you do? First, you need to identify, reduce, and eliminate the highest risks of the solution.
For example, let’s assume you believe there is a large untapped market that will see a great deal of value from your software. Conquering this market could generate high revenue, but the problem that needs to be solved is difficult and expensive. You know how you are going to solve it, but you really need to determine whether customers will buy the software that you are building to solve their problem. This is the hypothesis you need to test first. If you go ahead and invest time and effort building the software you’d better be sure that customers are willing to purchase it.
A great way to determine whether customers are willing to pay for software is to use the mechanical turk model. That is, put a human in the box and pretend it’s a machine, rather than build the machine first. Test this “software” out in the market, with your team as the humans providing the service behind the software facade. If people use it, then you know there is a market for it. If not you haven’t wasted time and money building something that customers will not use, or worse buy. You have only spent the time taken to run the experiment. The key here is not to build anything big or risky without testing the market first.
Always produce working software is one of the key tenets of Agile development. While Lean Startup talks of the Minimum Viable Product or MVP. When you combine the two methodologies, you build something that works, but it is built with the minimum possible functionality. This also allows you to build fast and to rapidly get the product into the hands of the customer. This allows you to gather data on the success of your changes as soon as possible. This rapid loop allows you to respond to the customer needs faster than ever before.
In the old days of waterfall development, detailed specifications were written on what software needed to do and how it should do it. These were written in order to assist the development team, so they could focus on writing and testing software to specification. Unfortunately, the problems and issues would often get lost in translation and wouldn’t solve the problem the users were having. In addition developers would spend a great deal of time ensuring that the specification was met exactly, wrestling with the details that were often not actually relevant to the main issues. As a result projects would run past deadlines and users would not use the final product.
So how do we avoid this? It comes back to the user stories we talked about in part 1. The story explains the customer issue in such a way that the entire development team understands the issues, and can then take their expertise and apply it that to the issue. The software developer knows the most efficient way to build something, so they apply their development knowledge to build software to solve the problems as efficiently as possible. In addition, QA uses their expertise in testing to make sure that the software solves the issue and doesn’t introduce quality issues. This allows the development team to build fast and get solutions to the customer as rapidly as possible. This build/release cycle should be 2-4 weeks. If it’s longer, it should be broken down into smaller steps. By getting the software into the hands of the user as soon as possible, you can see if the problem is being solved, and make adjustments if necessary.
So how do you get your development team to run as fast as possible? Follow these simple rules:
● Trust your development team to deliver on what they committed to. Don’t micromanage them, and let them decide what the best way to implement a particular feature is
● Don’t interrupt the delivery of a release to have them work on something unless it’s preventing your users from doing something that was already delivered and it has prime business importance
The next step in our continuous loop of building, analyzing and learning requires us to be able to measure the effectiveness of what we’re building. As you build you need to make sure you can measure the effectiveness of this new functionality and what qualifies it as a success or failure. For the software you are developing, the key metrics you are looking to affect are the Customer Success Metrics. We will cover these and the learnings from your testing in the next blog post.
About the Author:
Neil Davies is VP, Engineering at LeveragePoint. Previously, he was an Engineering Manager at Monitor Group and Logica CMG in London. He is the architect of the LeveragePoint platform, and a passionate advocate of Cloud Computing, Semantic Technologies and open-source projects. Mr. Davies holds a BS in Computer Science from the University of Nottingham.
Photo Credit: Exit Business via Compfight cc
