Almost every single (commercial) software product we’ve ever worked on has been driven by at least one of two simple goals; to grow revenue or to stay out of court. Occasionally far-sighted software sponsors realise both with the same solution, but more frequently, one takes priority. Business aims to grow by increasing market share, reaching new customers in new markets with products that offer a better user experience, or by replacing current systems with more efficient (and more profitable) workflows. “Staying out of Court” is shorthand for bringing operational workflows up to a standard dictated by the current and future regulatory landscape. As the financial services industry is one of the most highly regulated and dynamic industries globally, very often it is regulatory change that has been the compelling event that initiates software projects.
Innovation software engineering (the use of Lean-Agile and other innovation engineering methods) systematically designs in the ability to organically adapt the mission of a software programme throughout its lifecycle so that software sponsors can realise more than just a response to changing regulations. It incorporates at its core, the fact that business value is both dynamic and time-sensitive.
Business value and needs are, as a general rule, almost never captured in traditional, fixed software requirements specification documents. The challenges with using business requirements documents are manyfold. Not only do software specifications fix the need at a given point in time, they determine the solution (rather than the business problem to be solved (or the value associated with solving a business problem). And they introduce a barrier to access, isolating the business problem to be solved from the technology team solving the problem. Complex project planning and effort estimation focusing on tasks (rather than business value) further adds to the disassociation of the problem.
Instead, innovation software engineering focuses on deconstructing business value into the smallest possible discrete components, such that each packet can be assessed, actioned (just-in-time) and delivered uniquely whilst maintaining a direct and immediate relationship with that business value. Work packets that maintain referential integrity with business value have huge consequences for software programmes. Prioritisation, implicit understanding of how a feature should behave, acceptance (ie. sign-off) all become simple, trivial activities. Delivery teams learn become highly synergistic, performant, efficient, effective. The time saved (and number of meetings avoided) by adopting this method of working makes it well worth adopting.
The additional benefit of maintaining a close connection between business value and software feature is that many unnecessary features can be discarded earlier because the cost of doing so outweighs the business benefit. We can expose the 20% of software that 80% of users will use, avoiding building bloatware and maintaining focus on an elegant and valuable software experience. Jeff Davison at ThoughtWorks has written a paper for Good Requirements that cites a lot of the work that Chris Matts and collaborators have been doing on behaviour driven development.
The final part of the puzzle here is that business need, and by implication any software solution that exists to address that need, often remains unexposed, even when we attempt to describe it in words. In general, people are intrinsically experiential, emotional and social beings and we often find it challenging to express complex problems (and solutions) without the experience of the problem immediately in front of us. Prototyping software and delivering value incrementally enables us to explore next-steps by focusing on immediate value-shortfall, using methods such as storytelling and feature injection.
The time-sensitivity of a feature is one of the most important (and yet least well understood) aspects of software value. This is particularly the case for financial services, where fast delivery is critical in both maintaining regulatory compliance and securing commercial advantage. Most projects need to deliver “on time”, yet most fail to do so. Don Reinertsen cites research that 85% of product managers simply do not know what the cost of delays to their product are. Moreover, business value (versus time) is not a linear or even a plateau shaped graph. Business advantage generally diminish over time if value in software is not delivered early; as products change from being a pioneer to just another entrant in a crowded market.
The importance of being fast is amplified by building the wrong product; now the product has to compete not only with other products but also against its own complexity. Essential to avoiding this problem is to rapidly build-in tight, efficient, and clean feedback loops with customers, to gauge and expose need based on solving real customer problems, rather than imagined ones. This approach has consequences around maintaining optionality in product decision making but more importantly, as Helmuth von Moltke the Elder famously led us to, no business plan survives its first contact with users. Von Moltke’s other famous axiom, “Strategy is a system of expedients; it is more than mere science” focuses our attention on the translation of knowledge to practical life, the improvement of the original leading thought in accordance with continually changing situations.
Or as Mike Tyson eloquently puts it: