Lean Product Development: Sleepwalking to Electric Sheep



The original book behind Blade Runner, Philip K. Dick’s Do Androids Dream of Electric Sheep? was set in 1992.

When it comes to modern change approaches – particularly those that come from IT, like this reference from ThoughtWorks – then I believe in 2014 we’re not only dreaming about electric sheep, we’re designing and building them.

It’s time to wake up and realise that change is first and foremost about people and the work they do. And so we need to fully involve them in shaping that work and changes to it. Technology is essential to delivering change but isn’t a good way to lead that change.

My heart sank a little when I read a recent ThoughtWorks article on Lean Product Design in Practice.

It’s not that the article isn’t good – it is – it isn’t that ThoughtWorks don’t do a good job – by and large (in my experience) they deliver great technology – and I’ve nothing against Lean Product Design (or Development) itself – indeed it’s good that it’s getting a wider audience even if it’s hardly new.

No, my heart sank because to me this was just a better way to do the wrong thing:

My Twitter response to the original article

Not surprising, I was soon asked to explain myself, but I can’t think of a way of doing that in a single Tweet, so let’s see if I can instead explain it here.

Truly valuable change is about much more than technology

An electric sheep

It’s a familiar story:

Awkward inefficient and slow-changing processes underpinned by ageing and inadequate tech.
People succeeding despite the systems that are supposed to support them.
Along comes a big initiative to transform it through an expensive investment in technology.
Everything will be great, yeah?

No.

Too often the new technology is delivered and it is better but it misses an opportunity to completely transform how the work is done. By then the money has been spent and life is better but a once-in-a-generation chance to radically improve the products or service, its quality, the life of those who deliver it and reduce costs at the same time has been missed.

It is worse than that: because some positive change has been delivered, many people don’t even know that an opportunity has been missed. The project is hailed as a success and the champagne coldly flows.

Approaching change from an IT perspective simply doesn’t sufficiently challenge the existing work and its practices. It cannot. That’s not the fault of those delivering the IT, not the fault of the BA, HI and UX experts passionately trying to deliver the best solution and it’s certainly not the fault of the users or their managers.

It’s the fault of the system – not the client’s systems – the fault of a System of Change that tries to separate Product Development and Product Delivery, a System of Change that thinks because change is dependent on IT then IT must be the way to deliver that change.

The Build/Run Split - Alive and well in the Change World

A classic “bad model” for IT itself is the separation of “Build” and “Run” teams, often advocated by people who should know better.

Too often the new technology is delivered and it is better but it misses an opportunity to completely transform how the work is done

This destructive model separates two groups who are (by definition) interdependent and gives them wildly different motivations underpinned by Kill Performance Indicators. The Builders want to maximise change and the Runners want to minimise it. Cue an unproductive fight that only delights competitors.

Agile and Lean development methods are often seen as the antithesis with their learning-focused, incremental, cross-functional and iterative nature. But, if their boundary is technology – and not the complete system of work – then they are simply indulging in a better way to do “Build”. “Run” is all the stuff not driven directly by the technology – which can not only be a large part of each user’s day but more importantly creates the requirements that shape the technology in the first place.

Rapid and repeated feedback from users is not the same as them being part of the team. Studying how other people work is never a substitute for the deep knowledge of those that do that work day-in and day-out*. Consulting users on incremental improvements and better ways to do existing tasks are not the same as taking big leaps to completely recast the nature of the work.

With the best of intentions the common outcome is a far better IT solution constrained by old assumptions about the work and the best way to deliver the products and services of which it is part.

How can this be changed?


Merge Product Development and Delivery

Have real users as part of the development team

Sit the development team where the users work

Make it a project that aims to transform both work AND technology

Support change teams with outside expertise but don’t limit that expertise to technology


Ownership means people are a part of their own change


There’s another important reason that users should be on the product development/delivery team: Ownership.

Those who do the work should be in control of how it is being changed and improved. They are the experts on what they do. They will certainly need help but change should never be something “done to them” by others.

But “replacing technology” is the wrong thing to do – the goal should be to both transform the work AND introduce better tech

Taking this approach reduces resistance to change and leads to better changes. It’s no longer a 3rd party expert trying to convince the front-line – it’s their own colleagues who are deeply engaged in the change.

There’s often a tendency to resist this – if you’ve hired someone to replace your technology then that’s exactly what they’ll try to do. The more control they have over it the more they can control their risk and exposure. That incentivises them to minimise their engagement with the non-technical aspects of the work and to put technology first and your business outcomes second.

But “replacing technology” is the wrong thing to do – the goal should be to both transform the work AND introduce better tech. When you do that you’ll more than likely need less technology (at lower cost) because you eliminate whole processes.

That’s why transformational projects initiated by CIOs so often run into problems. They need to be bigger than the CIO – they need to touch and change a whole bunch of divisions – and that’s where they founder.

Getting this right takes strong leadership from the top and that can be hard to find. But without it, trouble lies ahead.

Success....but why?


Please note I’m not saying that people don’t succeed with approaches like Lean Product Design in the ThoughtWorks style. They do.

But I think they succeed when they actually do a lot more than is described in the method: they succeed when they’re able to trigger much wider change, when they’re able to co-opt users into the teams to drive and direct that change, when they can get users and their communities to step-up and own that change; when they’re able to make it about transforming the work and not just technology.

And I’d prefer that to be explicit and acknowledged – it’s part of the method.

Thanks for listening.

Hopefully it is now clearer where I’m coming from. Would love to hear what others think.


*NB: There are some exceptions to what I’m arguing – for example in cases where the nature of the work is something everyone is familiar with: e.g. consumer goods and simple common services. But most work is complicated (or even complex – see Cynefin) and requires specialist domain knowledge to optimise.

Posted in Agile, Leadership, Lean, Ownership, Service Design.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>