Lean in

Feeling fuzzy

tom.hopkins — Thu, 06 Mar 2008 02:30:00 GMT

David Armano, from Logic and Emotion, spoke on the first day of Mix08.

It's a new presentation from him 'From the long tail to the fuzzy tail'. It's not really related to the long tail, it's about his theories about how mixed teams should fit together and that we are all becoming 'sun-shaped people'; 'T-shaped people' and so on (which there's a lot about on his blog).

People, he argues, need to be more open to ideas, more broadly skilled and more prepared to bump around inside multi-disciplinary teams. They're compelling ideas with which I think most of us can identify with the problems we're trying to address.

One of those problem that he kept coming back to was a powerful dislike of the waterfall process. His argument is that in a world of ever changing fads and the need to be quicker, we've got to be able to get started faster and the 'control' which waterfall-style process creates is illusory.

This is all good stuff that I think most of us can get on board with in broad terms, but does it really address the issues that are stopping organisations from acting in this way?

A desire to be flexible, open, quick etc is easy to find in most organisations. It probably works well in a NY web design agency to talk about simply starting to form some quick teams and get going but how do we organise teams for this principle and how do we create atmosphere's where people can work that way. How do we in practice subvert the hierarchies that push people into silos, that create command and control approaches.

David presented this image (also found on his blog):

David's answer seems to be to do away with waterfall and get mixed teams on their way.

Great to see this sort of advocacy coming from what might at first seem an unlikely source. My concern is that we end up taking bits of what we know as the agile approach and trying to use them to run the whole team, as well as software development.

Agile is an approach which has been created from a lean way of thinking to solve a particular problem (software). To build a framework for the whole creative endeavour of digital creation, we need to restart at the lean principles and develop them in detail to all our processes. Some technical architecture can be re-factored at low cost (and virtualisation, another theme of Mix, increasingly enables this). But others can't. The reason that Twitter couldn't grow is because they'd picked the wrong platform choice or architecture. And chunks of the design process are the same.

Front-loaded 'everything planned up front' waterfall is wrong for lots of well known reasons. But there is a danger that by trying to implement agile 'always iterative' across everything we do, we are, in fact, reneging on our responsibility to plan what we can know, or what will be expensive to re-factor. Agile already makes provision for this of course, and the line from lean is not 'decide as late as possible', it is 'decide as late as is responsible'.

Failing fast

tom.hopkins — Tue, 31 Jul 2007 23:31:00 GMT

Training courses may be an unlikely source of inspiration but I was on one last week and I found some quite out of the blue. We were practicising presenting arguments and the chosen topic was when Agile development is right and when waterfall is right. Actually - except where all that matters is writing a contract - I don't think waterfall ever does win but that's a debate for another time.

James came out with the line that waterfall is a "fail late" methodology.

What a great line that is.

For those of you who've not be dosing up on the books, a brief explanation. Waterfall is in many ways the "classic" project management approach. You spend ages upfront cooking up a plan, making sure you've thought through every detail and potential contingency. You then tuck in and do whatever it is your doing (software development for the sake of this argument). Finally you review you work and make sure you ticked all the boxes. It sounds great. But the reality is that - especially in complex project like software, it often fails to deliver on what was wanted at the start of the process, and almost certainly fails on what is wanted and needed by the end of the process.

The argument goes that it was simply asking too much up front. If such a flawless plan is possible at all, it's going to be a Hurculean task, and - as we all know - things change rapidly, especially when you've got the real feedback of a great development team on what can be done and what should be done.

A feature of waterfall methodology is that whilst the mistakes will be made throughout, the crunch point where we all have to admit we're up to our knees in doodoo happens at the end (sometimes many months or years after the project started).

Increasingly, companies are recognising the need to fail fast and move on. It has even become a bit of a mantra in the VC and marketing worlds.

Of course, that doesn't mean you have to mean failing completely and utterly, having some sort of monumental car crash disaster. It might mean picking up a potential customer need and trying to solve it, and seeing how it goes down. It might mean looking at a feature to improve shopping conversion, or an extension to Facebook.

Do we aim for failure. Of course not. Is there disgrace in failing? No, to err is human. But if you're going to do it, you should at least get it over and done with as quickly as possible.

Unblocking drains

tom.hopkins — Sun, 17 Jun 2007 04:15:00 GMT

I've been reading the excellent Clued In, following recommendations from Una and Richard who both saw Lewis Carbone discuss the ideas at Mix. Amongst several thousand other amazing thoughts in that book is a reference to The Real Heroes of Business: ...and Not a CEO Among Them.

This amazing idea in that book ("real heros") is that many organisations have amongst their staff customer service champions of the sort you could never deliberately hire. These are people who will do anything to deliver customer benefit for the organisation but they are rewarded with vague contempt and apprehension. This is also a strong theme in MTCTW: making staff directly responsible for zero-defects and for finding and resolving issues (this being a classic area where mass production failed, with the sign and symbol being that only the managers can stop the line in a mass-production factory; any member of staff can in a lean facility).

Look at Agile Software development, and we're taking things even further. The primary thinking behind lean methods in software and lean methods in NPD is that the whole team needs to be creative and enpowered to solve problems as they come up - taking immense pride in the solution.

The example given in "Real Heros" is of a New York Roto-Rooter driver. Roto-Rooter is a drain cleaning specialist with a particular product set (like Dynarod in the UK). They had a particular route driver called Alan Wilk who was passionate about customer service. He identified several major problems. One was that due to the nature of the work, staff would turn up still unclean from their previous assignment. Another was that often the room with the blockage would end up looking a little discheveled after the Roto-Rooter man had called. Completely off his own back and against company policy, he installed a rudimentary shower in the back of his van to solve problem number 1, and carried around cleaning materials and an air-freshener to solve problem number 2. Neither of those things was recommended or supported by his employer.

Two things are going on here, both of which are fascinating. One is designed the product around the customer (albeit on the fly) and one is noting that the people who know what the problems are (and what the solutions are) will most often not be the people in the board room.

It's not an example of a solution but it's definitely more evidence that - given the right framework and respect - it is the staff who will drive customer insight and understanding, and - as we'll go on to talk about alot - if the customer thinks it's better, it's better, no matter what the technical service delivery might be.

The machine that changed the world

tom.hopkins — Sat, 09 Jun 2007 21:11:00 GMT

(NB a version of this post appears on Usable Interfaces)

I've been reading the fantastic The Machine that Changed the World. The book was first published in 1990 by a team of economists from MIT in response to the whacking which American car producers were receiving from the Japanese.

It had been widely assumed that the system the Japanese were using to simultaneously deliver higher productivity, higher quality, quicker plant turn around, faster product development and greater innovation were deeply rooted in particularities of Japanese culture and ethos. Anyone who has visited Japan will know that the culture is dramatically different from the west with significantly greater emphasis placed on the role of the group and social responsibility. Weren't these the factors that were allowing the Japanese to beat the US at their own game - large scale car production as it had originally been devised by Henry Ford in the 20s?

In fact, Womack et al. establish through detailed investigation of the Toyota Production System (TPS), as well as detailed on-site analysis of many US, European and car plants, that the new ways to produce automobiles on a large scale - dubbed "lean production" - are in fact simply better than the "mass production" techniques we are all taught to believe are best-in-class. Whatsmore they can be implemented anywhere. The proof being the American owned and Japanese owned lean-production plants which now exist in the US and Europe.

Unlike mass production, lean production returns responsibility for the smooth running of the factory to the staff that actually work on the production line, it places an emphasis on immediately removing all defects and minimising waste, involves customers in the design process and it is based on the understanding that it is not always best to try and make all project decisions in advance. It is a revolutionay way to look at processes and governance.

I strongly recommend the book which covers all of this in a very digestible manner and is very engagingly written too.

I've been introduced to all of this by the adaption of these principles to software engineering (the Agile Movement) at Conchango but I'm starrting to see it everywhere in every industry and so that is what this blog is going to be about.

And if you're still thinking this is all about cars. Think again. Here a story about the Wii whipping the PS3. The PS3 is (despite being Japanese) a classic product cycle development. Wii is innovation. Innovation requires lean thinking.

A tale of two blogs

tom.hopkins — Thu, 17 May 2007 20:51:00 GMT

It's a most 21 century peculiarity. You get a new job and you'd like to participate in their blogs, but you already have one that you quite like writing under your own name - although you already don't spend enough time on it. Or, as with the dilemma Anthony found himself in, you've got your own blog (which in his case is extremely successful) and you also get asked to write for a publication (in his case Brand Republic). What do you do? It would be wrong to post the same ideas on both sites, and drawing borders between the two is difficult.

Well I'm hoping in the long term I can bring these two blogs together, but for the time being, I'll restrict this one (which ranks above my private one in Google, even before anything has been posted!) to talking about lean production systems (see next post for a lot more on that) as that is one of the most fascinating things I've found out about since joining the business, which has really impacted on my thinking about many things. Usable Interfaces will remain for observations around marketing, user experience and strategies in the digital market place.