Reflections on "Rethinking Lean Service"

I just listened to an interesting podcast by John Seddon - but really coming from the other side of most people in this community, in the sense that I'm a technologist (with some interest in the public policy agenda, but as a citizen only) and already an "Agilie" convert with some marginal interest in "Lean" (specifically with whether this might be an overlap with some of the technology methodological thinking (related to, say, the "Getting Real" ideas perhaps)  and a technologist). 

What this revealed to me is that there is a lot to be learned from the approach of Taiichi Ono for Technologists (and no doubt, if Seddon's critique is accurate, public body service providers as well), and that indeed this does have some overlap with the (less well tested and proven) approach of the Getting Real crowd.

But it also pointed out the dangers of accepting this "Lean Tools" approach, which appears to be (again taking Seddon at his word) a misapplication of Ono's procedures, rather than his approach. 

The three things that I really resonated for me (though by no means the only ones) were: 

1) 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).

2) 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”) - The parallel for me in  software development is the need to see progress in customer/user language and user-perceptible value (business value)  when developing rather than try to measure progress using internal and invisible technical milestones.

3) Lastly, the injunction, to "understand your organization" was very resonant, from an organizational function (not really in terms of software per se). Although I'm now operating in primarily micro- and virtual organizations  (temporary teams), my experience of previous larger organizational workplaces, and my readings in workplace ethnography and consultancy, makes me feel that the job of understanding "what is done" at an organization, or understanding the nature of the value delivered (whether under the banner of TQM, Lean, or a return to Ono's original thinking) can be a very subversive task and one which threatens the identity of the organization. I do not think this can be treated as simply the task of management without pointing out the resistance that an organization may bring to an "understanding" attempt (-- the kinds of resistance that organizations display are not unlike the pyschological defences of individuals - the Tavistock approach as detailed by Organization in the Mind). After all, if the understanding is the same as the representation of the organization to itself, then there is no new understanding. On the other hand if the understanding challenges the organization's self-representation, then this takes on the form of a "ego-attack" on the organization, which is bound to defend its notional boundaries. 

I'm not sure how relevant my software-design based reflections on this podcast will be to the public service focus of this community, but just interested to see how far these cross-disciplinary resonances will go.