Another reflection after listening to Seddon on “Rethinking Lean Service”
Seddon argues that you need to let the actual problems (that disrupt your delivery of value) dictate what activities you perform, and what processes you set up. This implies that you need to be brave enough to allow problems to occur (and have a way of catching and solving them). It means (in software terms) that you must not pre-optimize (of course!) but also not pre-solve, problems you haven’t yet had (even if these occur in 90% of similar projects), and also not pre-create functionality you haven’t yet found a request for (again even if these occur in 99% of similar projects). This is related to the software principle of YAGNI (You ain’t gonna need it) and DTSTTCPW (Do the simplest thing that could possibly work).
This problem-oriented flow is similar to the principle that Seddon characterizes as “Demand-driven” development, for which he stipulates that it is critical to differentiate which kinds of demand represent value, and which actually flow from “defects” and represent waste. For me, in software design, this is an understanding of user/customer/client requirements - these are demands, and some of them follow from the need to generate extra user-value (a needed feature), but some of them actually indicate defects in the existing system. It’s critical as a software designer to be able to differentiate these two, or you may end up building a monstrosity where new features are introduced to correct old mistakes. (I could give common examples but instead will choose one that I find really instructive: the example of the No Kahuna team who chose to remove a feature to fix an apparent defect in their webapplication - This is the right and brave decision even if I personally relied on that feature, and my team didn’t see a defect - and as Nathaniel pointed out in his comment - a very rare event in software development)
(adapted from part of my post on The Connected Republic)
Thanks to Mark for encouraging me to listen to this great podcast of John Seddon rethinking “Lean” and going back to its roots in the Toyota / Japanese miracle
Some notes:
- Customer pull, worker pull. Let workers improve (and own!) the processes.
- Let the problems you encounter determine the processes you set up.
- The measures in use must relate to the customer (“For any flow, we measure the end to end timing as it is experienced by the customer”).
- Let demand drive the system. Which kinds of demand represent value, which waste (that determines your response).
- Study your organization as a system
Really fantastic and very valuable for working out what I have been learning over the last two or three years.
I remember trying this out before though. “Study your organization as a system.” But what if you discover a system that is not consonent with how the organization represents itself to its customers, or worse (and more likely) to itself.
