UK Lean Conference 2009

I recently attended the UK Lean Conference 2009 and here are my observations and thoughts...

----
General theme of focusing on value rather than waste, that waste is not as useful a metaphor for software development. If you focus on value then waste drops out as a side-effect.

My thought: The reason why there is so much talk about eliminating waste in Lean manufacturing is because there is more opportunity in removing waste than there is in optimising value-adding activity. Focusing on value to force out waste seems to be another way to looking at the same issue.

I agree that a better approach to thinking about waste in software development is to ignore the traditional manufacturing categories and simply look at our context and think for ourselves. If patterns emerge, they should be our own, not translations.

----

Chris Matts made a statement asking why would we share knowledge as having exclusive knowledge provides competitive advantage.

My thought: We share knowledge because it is important to society and it challenges us to improve

----

This is something that I first heard from Rich that IT is usually in a unique position of having visibility of the entire value stream. I consider it an accidental visibility. Does this mean that IT should take responsibility for value streams? Probably not but an effective IT organisation should try to encourage that visibility and management to the rest of the organisation.

----

There are two types of value streams in software development. One where the unit of value is implemented customer value. One where the unit of value is knowledge. We need to pay attention to both.

----

Front-loading knowledge is not just about the problem space, but also the solution space.

----

Don Reinertsen gave an example about how smaller batch design document review was better than doing it all in one shot.

My thought: Are you really an engineer if you believe that reviewing a document is equivalent to reviewing a design? That's what popped in my head but I'm thinking about my context (software) and it may not hold for the one he's thinking of (hardware).

----

Paraphrasing David Andersen (imagine strong Scottish accent)... Use a time-based cadence when coordination/transaction cost is high, otherwise use event-based triggers.

So for example, I might have event triggered retrospectives and event triggered story prioritisation meetings... unless it's too expensive to coordinate like that, in which case we might schedule it weekly, etc.

----

There's a general theme that people need to understand their own context, which I agree with. However, from my experience, the problems aren't actually that unique.

----

Alan Shalloway on Creating a Model to Understand Product (and Software Development)

If you ask most teams how long it would take to rebuild the product from scratch (with no changes in features), you usually get a number that is 25% of the original time. This suggests that 75% of the time is spent figuring out what to build.

Software development tends to have more market risk than technical risk. I immediately thought of ESBs when he said that but he's probably correct.

3 types of value:

• delivered value
• improving delivery
• understanding customer value

From the practitioner reports, he noticed that there's a common theme where because teams focused on process, not people there was less of a climate of fear and therefore the teams moved faster to a culture of continuous process improvement.

My thoughts:

Expose knowledge first -> improvement

People make poor decision not out of spite but out of ignorance. Therefore improve knowledge by exposing information and you should tend to see better decisions being made.

Don't worry about transformation, just help people see.

----

Jeff Patton on Lean Product Discovery

Internal customers => "caged"

External customers => "free range"

Jeff showed some shots from Florence of how even sculptors iterate on designs using soapstone before going to marble.

Mentioned "storyotypes" which I have not ever encountered before even though it's been around for a few years.

Instead of using % done on features which incorrectly implies that everything must be built, instead assess the releasability of features using grades (i.e., A+, B-, C, etc.)

Someone distinguished between positive iteration (learning something) vs negative iteration (already learned but knowledge didn't stick)

"It's a prototypes until it ships" -- paraphrasing Alan Cooper

"The idea of high fidelity and low fidelity in prototypes is silly. As far as I'm concerned there's only right fidelity and wrong fidelity." -- paraphrasing Bill Buxton

----

People talk about software not being X or Y with the implication that there is nothing to learn from X or Y.

Note that Toyota is not a grocery supermarket and yet a supermarket inspired kanban.

----

John Seddon

Only the predictable is preventable, trying to prevent the unpredictable causes chaos

Model the Check. A different way of presenting PDCA to focus on gather knowledge before creating a plan. Really this is just clarifying what PDCA is supposed to be.

Culture is a product of the system.

1. Study the system (IT = system condition)
2. Improve the design of the service
3. Pull IT into the design

----

Phil Badley on Business Improvement Through Transformation

Train for demand, not for role.

Focus on knowledge, not performance.

Don't sell, don't push => generate curiosity (this is the same message as Seddon which is unsurprising since Vanguard was consulting with Phil)

----

Don Reinertsen on 2nd Generation Lean Product Development

There are no bad tools, just bad times to use them.

If your approach is based on facts and the facts change, your approach automatically changes.

----

Random thoughts:

Where does the demand for certification come from? Why?

Elitism is morally and practically wrong.

----

Kenji Hiranbe on Kaizen at Toyota

People are the most effective vehicle of knowledge.

During the discussion, Martine Devos was concerned about all the managers (actually improvement team members) monitoring and hanging around the worker who was part of the work cell experiment. Someone pointed out that this wasn't oppressive but was in fact a demonstration of an obvious support structure that we typically do not see in organisations. That team is there to support the worker, not to tell her what to do. Kenji also pointed out that everyone in the factory were part of the same village so everyone pretty much knew each other and there was inherent trust that may be atypical for most organisations.

----

Hal Macomber on Target Value Design

I always thought the Lean Construction Institute was about custom houses but it turns out it's about much larger construction projects like oil refineries and hospitals.

"Separating planning, execution, and control is bullshit"

The schedule doesn't authorise work; someone needing something authorises work.

Make commitments at the last responsible moment. This is a refinement over the previous "decide at the last responsible moment"

Referenced Fernando Flores and the importance of deliberately building trust.

If you give me an open field, I'll do half-ass planning.

----

Marc Baker on What is Distinctive about Lean?

Nothing much here that I wasn't already aware of except that 1 vial of HIV is worth 10 million GBP. I'm assuming there's something particular about how the vials are prepared.

----

Hal Macomber says that if the client wants a "low-key transformation" then he'll refuse to engage because those will fail.