John Seddon's Bristol University talk

This was a very enjoyable talk from a very good speaker. There was quite a lot of overlap with John's 2010 Øredev conference keynote but it was well worth going. There's something about seeing someone speak in person. The occasional thing they've said before suddenly somehow makes more sense.

Here's what I jotted down, in no particular order:

• MBA - maybe best avoided.

• If you give it a name [eg Lean] then managers will think it comes in a box.

• [failure] demand went up. It should have been a signal.

• Telephone work is not a separate part of the system.

• Understand the problem - build understanding into the system.

• Cost is in flow - not in activity.

• If you measure cost, cost goes up.

• The only plan is get knowledge.

• Culture change is free [because] it's a product of the system.

• Experience is not the same as knowledge.

• Change is emergent. Don't think 'we can't make a change without a plan'.

• Trust is not a point of intervention. It's a consequence.

• You don't learn counter-intuitive ideas in a classroom.

• Taiichi Ohno - "he never explain".

• Don't persuade. Make them curious.

Those last three reminded me of the old chestnut about acting your way into a new way of thinking rather than vice-versa. John's point was that if you are trying to teach a counter-intuitive idea (a new way of thinking) then it's probably not such a good idea to start from the current way of thinking. That's trying to cause a big change in someone's behaviour (something counter-intuitive) by persuasion alone. Much better to get them to experience what you want them to experience directly and then they'll start to naturally think differently without any persuasion at all.

John also emphasized that service organizations can change fast because they don't make anything. That made me wonder to what degree his message applies to software-development (in isolation) since software developers very definitely do make something.

Kanban 1's Game Notes

Some notes from Kanban 1's Game's I've played at a few clients sites...

First, some teams have been exploiting the splitting rule. If they have a 4-work-item with 2 bugs on it, they simply split it into a 3-work-item and a 1-work-item and put both bugs onto the 1-work-item and then abandon it, and carry on with the bug-free 3-work-item. They have to check for bugs on the abandoned buggy 1-work-item but otherwise it doesn't affect velocity. This is obvious in hindsight but I hadn't foreseen it. It is amazing how simple rules can create complexity when used in combination. To counteract this I introduce a rule that when you split a work-item into two smaller work-items both new work-items get the bugs. So, for example, if you split a 4-work-item with 2 bugs into a 3-work-item and a 1-work-item, then the 3-work-item and the 1-work-item both get 2 bugs.

Second, the way backlog work-items are created (without any 1's cost), and then moved onto the first table (also without any 1's cost) creates another unintended (from my point of view), but nonetheless very interesting possibility that a few teams have also recently exploited. What they've done is simply created masses and masses of backlog work-items and immediately pulled them all onto the first table. They effectively move the entire backlog onto the first table. The price they pay for this is having to check for bugs on every work-item. Naturally lots of bugs accumulate on the masses of work-items on the first table. However, this does not directly affect the velocity since they can simply any abandon any buggy work-item on the first table and pull in a newly created bug-free backlog work-item at any time.
So I'm currently wondering if it's better to have to pay a 1 to create a backlog work-item and possibly also pay a 1 to move a backlog work-item onto the first table. I think this will be effective for two reasons

• it simplifies the backlog rules a bit since I can now drop the rule that backlog work-items have to move onto the first table in strict creation order.
• I can allow 1's thrown from any table to create backlog work-items. This will give players on tables other than table 1 something to do during the early days of the sprint.

It seems clear to me that the game should somehow take into account the total number of bugs on all work-items on all tables. I'm pondering that.

Thirdly, rather than recording the bugs on an index-card paper clipped to the work-item, simply use the paper clips! Two paper-clips on a work item (as in the photo) means two bugs. Much simpler. Again this is obvious in hindsight.