Musings on Holistic Software Development
Tag Archives: architecture
It’s pretty pointless building things that your customer doesn’t need or want.
The first steps necessary in understanding how to deliver value to the customer:
1. Identify the value. – This must be done from the customer’s perspective.
2. Identify how that value is actually created.
Lean thinking describes this as identifying and mapping the value stream – the activities that are performed to create customer value.
The value stream must be understood from end to end – from customer need to customer use. Taiichi Ohno described this as understanding the entire process of product development from customer order to receipt of cheque.
In large organisations it can be difficult for a team to gain direct access to, or even identify its customer. I’ve been working with teams in a large systems of systems environment. In this organisation the work that a team does is passed successively downstream to the next development team in the value creation process, each team in turn adding their part to the system.
In this organisational model it seems to many in the development teams that their customer is just the next team downstream. An additional effect of this organisational pattern is the explicit handover points in the value stream which cause transactional behaviour invoking Conway’s Law which influences the resulting system architecture, interfaces and communication paths.
For most teams, in the linear handover pattern, the actual customer who uses the system is invisible to all but the last team in the chain, it’s no wonder teams can’t identify their end customer or indeed see the value they create. This scenario is often made worse by the role of the customer being represented by a technical authority figure who is, with all best intentions, trying to coordinate the efforts of the teams to create the technical solution. This is a compromise that misses the point of directly engaging the customer in defining the solution.
A better way to organise to deliver complex systems of systems is to use Integration Streams which not only makes the customer explicitly visible to the development teams but provides the mechanism to scale complex agile delivery.
Begin examination of the value stream from the customer end where actual business value is realised. This is important as it avoids the problem of mistakenly identifying downstream teams as spurious customers in an extended and complex value stream.
Be certain to ask your consumers the “4 tests of value”.
Be wary of anecdotal evidence of working practices and product usage, including metrics. No matter how convincing these metrics look there is no substitute for actually going to see for oneself. There is no better way of understanding the value of your product than seeing it in use by the consumer.
When you have an better understanding of the value stream there are some hard questions to ask regarding the activities and processes you’ve identified:
Activity that contributes directly to customer value is valuable and should be maximisedActivity that contributes indirectly to customer value should be questioned and minimisedActivity that does not contribute to customer value is waste and should be eliminated
Value must only be considered from the real customer’s point of view, determination of value from any other perspective will result in local optimisations at the expense of the Value Stream, the customer and your organisation.
A customer focused mindset, continually questioning the value of each work activity is key to getting the most out of the feedback loops in continuous improvement methods, driving an organisation to maximising delivery of real customer value.
How much of the work you do is actually delivering customer value?