After parts one and two, this is the third and final installment of this series discussing an approach to software production. In many ways, this is the part that is often misunderstood in established businesses but it is vitally important. This is the part where I discuss how we actually measure the value being created by our new system. A system that can’t deliver business value is hardly worth investing in.
By now, we have a solid framework from which we can start validating the fruits of our labour. We are co-creating, integrating early and releasing quickly however we still don’t know whether anyone actually needs our product. It goes without saying that products must be validated early on in the piece. That is, it is critical to seek feedback about the new product, in some form or another, from the target markets who we anticipate will use the product.
Many new businesses start with a comprehensive plan of what they are looking to achieve and how. Although this detailed planning provides comfort and makes project justification easier it is in large part a wasted exercise. New products are just too uncertain to make such detailed planning useful. Instead, starting from a broad project vision we use the principles explained in this article and we back them up with customer validation and adjust where necessary.
Although validation is no guarantee of success, it does reduce the likelihood of waste. Not only are we validating that we are on the right track, we are more importantly finding out whether we are on the wrong track. Consider how many products have been built at considerable expense in the absence of validation only to fail after launch because no one actually wanted the product. The number of projects fitting this bill is endless. Again, consider how much time, effort and money could have been saved if the product was validated early on in the development cycle. The product strategy could have been pivoted towards a new direction or even abandoned entirely. Validation is about introducing a customer focused feedback loop into the development lifecycle. Develop, validate, refine, repeat.
Earlier it was mentioned that we are no longer measuring deliverables against scope and schedules. This extends to the measurement of project success. You might be surprised to read that delivery of the scope is no longer a measure of success and that we do not treat the velocity of user story completion as a KPI in our development - it makes no sense. Our experience is that this is counterproductive to quality software production because it perverts the incentives for well factored, well tested code that meets or exceeds the customer’s requirements. With a focus on velocity, humans naturally tend to take shortcuts to meet deadlines. Moreover, as managers, in this mode we tend to start making estimations and promises that we can’t meet as time starts to become the focal point of the daily routine. If you deliver a project on time and within budget but the software does not do what the business had envisaged then who has the project been a success for? (hint: it’s not the customer or the end user)
As many software developers have painfully learnt, software development timelines are often a waste of time and estimating the time it takes to deliver a complete piece of code for a feature can be difficult. It takes practice and an acute awareness of your project domain and even then developers will tend to be well off. With this in mind we take a different approach that we reason makes far more sense in terms of considering software as an integral part of a business strategy and operations.
We look to measure success against KPIs which reflect the value our software delivers to the business. For example, growth in sales, increases in margin, increased conversions, etc etc. As soon as our clients can let go of the traditional mindset of scope and delivery and move onto business value delivered, project sponsors can only then start to understand the value they are receiving. By focusing on KPIs, feature creep is also minimised. Does it add value and does it increase the KPIs? If not, it may be that the requested new feature will be an overproduction which will provide a limited increase in value.
At Futurice we generally measure two things. Firstly we measure which features are of priority and we work on aim to deliver those first. Working closely with the product owner we are able to ensure that the things we deliver are the things the client needs now and which things the client attaches greatest importance to.
Secondly, we take actual business metrics to measure the success of our projects. For example, sales growth, margin expansion, conversion rates, etc. We could have the fastest project delivery ever but if we are not improving our business metrics then what are we really doing? This is how we wish to be measured. That is, measured by the business impact our work delivers. We are confident to stand by this.
The result of this is that we tend not to promise project delivery dates and for many organisations this will be difficult to understand. Reflect on this for a moment. We do not work to delivery dates. Instead, we work to deliver the features we can produce in the allocated time and budget.
There is another benefit of the KPI driven approach. A focus on priority driven deliverables focuses a client's mind on what is important whilst allowing us to start focusing on the quality of our work over the quantity of our work. This means we focus more on well factored code that is easier to test and scale. The net result of which is a sustainable working pace, higher productivity, better quality code and ultimately more meaningful software.
Over part one, part two and in this part three I have presented a simple and modern approach to software production that we have used to achieve outstanding results across projects. It is heavily customer driven, it is iterative and it is sustainable across both short and long running projects. Just as important, it encourages close collaboration between teams, project members and clients. In our experience this Agile way of working has been of great benefit to us and it is a large part of our success. For the readers of this article, the beauty of what has been presented here is that it is both repeatable and reproducible across a broad number of domains.