In today’s blog post we will start to look into the common symptom; “We deliver customer value too slow”. This feeling is a very common feeling in any organisation, especially when working with features in software product development. But, also in hardware development companies where the lead times normally are very long, which is a big reason for the waterfall way of working.
Asking why, many times on “We deliver customer value too slow” gives these three symptoms on the same level.
- “The delivery packages are too big”, which was a big problem in software product development with waterfall way of working, but which has been much easier since the introduction of Agile software development, where the focus is on smaller deliveries, features. With the introduction of Daily Build and Continuous Everything, there should not be any more reluctance to release often, since it is much easier than before.
- “The system product is not built on a modular platform”, can of course be the case in software product development*, but is more important for hardware product development, where cars are a good example with platforms that can be valid up to 15 years. The modules all have clear interfaces and parameters to follow, which means that as long as the interface and the parameters is followed, the modules can independently be made better, cheaper, cleaner, smaller, etc. And before a platform is consumed, the development of the new platform is already started. This is a type of Parallel Concurrent Sequences/Disciplines, that is of very high importance to understand and that we discussed in this blog post.
- “The project phases are in sequence”, which is the typical waterfall way of working approach. This will automatically give a long lead time, that was ok in the old and slower market, but is too slow for today’s market.
If we put the symptoms achieved so far in a picture structured like the Prefilled Problem Picture Analysis Map, it will look like this.
We continue to ask why on these first two symptoms and then we come to the following root cause, “There is no setup for incremental build of SW MVPs / HW/SW platforms with modules”. That is a common root cause at software and hardware development companies, and need of course be differentiated to other root causes that decreases the Flow Efficiency.
When asking why on the third symptom, we get the root cause “There is no setup for parallel work”, which is normally the case in a silo organisation with waterfall way of working. It is important to understand, that in order to work in parallel, we also need to nourish T-shape and short chains of interactions, which are prerequisites for parallel work to be efficient. And when deciding to accomplish parallel work, both the transmitter and receiver of work, need to have the prerequisites to handle a change from sequential to parallel work, so we not get bottle necks somehwere in our value flow. Se also this series of blog posts, elaborating on sequential and parallel work.
A part of the Prefilled Problem Picture Analysis Map with the chain of symptoms for “We deliver customer value too slow” will then look like this:
This was all for this blog post, and in the next blog post in this series we continue with the next symptom, “We get slower and slower for every feature we are adding”. C u then.
*This depends a lot of what kind of software it is. a) If it is software situated on a hardware consumer product, that has a very fast life cycle, like a mobile telephone, the need of a modular platform is lower, but also depends on the ability to reuse the software on the coming hardware. b) A software situated on a hardware platform that will live for decades, with a continuous release of new hardware modules, also need to have a modular architecture. Otherwise the risk is high for a crappy systemization, which will make the implementation time longer and longer for every new software release, until it is not possible to make any new releases.