The Lean and Kanban conference was hugely fun, with phenomenal speakers, passionate attendees and as many disparate topics as could possibly be imagined falling under the Lean umbrella.

I particularly liked John Seddon’s approach, which I’ll boil down to “Apply common sense before tools”, as well as his highly descriptive and colourful narrative style; Don Reinertsen’s challenge to understand and apply a science-based approach; and the stories from the many practitioners who shared their adoption techniques and learnings.

I also loved seeing 12 people there either employed by or working for my current client. They take the effort required to transform an organisation seriously, while making it as fun as it can possibly be. I’ve thoroughly enjoyed working here for the last couple of months. Their focus on learning, and the strongly aligned culture and values that people here display, have made my work both simple and fascinating.

I took away a few Big Things from the conference, some of which I’ll be doing more of, and some of which I’ll be changing. Here they are:

Visual Representations

Software is highly abstract. If we were actually building cars, we’d be able to see what’s going on. As it is, it’s electronic, and hidden. Making things visible (and tactile) provides a mechanism for seeing constraints, a physical central point around which people can congregate, and a more effective radiator for anyone outside the team who might be interested. I’ve realised how much I’ve been missing as a coach because I can’t see the flow of the projects, and am now fiercely encouraging the teams I’m involved with to move to cards / post-its, even if it’s a copy of the electronic system.

The Kanban boards we’re using don’t necessarily look exactly like the ones used in manufacturing. That’s OK. Alan Shalloway had some methods for knowing whether the right things were visible or not – anything which causes queues, impairs flow, allows us to discover waste. John Seddon made me realise that we need to know where the problem is before we apply the tools which make it visible, or else we risk optimizing in the wrong place. Just about everyone suggested learning from any mistakes we make in this area.

Product Development vs. Production Line

A lot of the techniques which are used in the production line are designed to minimise variability and achieve a smooth, even flow of similar components in a system. This doesn’t necessarily map to software very well. I’ve already talked quite a lot about this difference, and where the production line metaphors might be applicable. I also tend to emphasise the need to learn as part of continuous improvement. When we’re producing new software, the learning aspects are more important; we want to learn from variability rather than minimise it.

This was something that I felt very powerfully anyway. Hearing the same message from people who are well respected by the community improves my confidence.

A lot of the things we think are wasteful, aren’t

This came particularly from Don Reinertsen’s talk. He used the metaphor of TCP/IP to demonstrate that single-item flow may not be efficient in some situations, and that we have to consider the transaction cost; that even Toyota have some queues, and some batches. I’ve shuffled one of his earlier books, “Managing the Design Factory”, up to the top of my reading list (it’s already on my shelf!) Looking forward to reading about the maths, too.

I was pleased to hear Don mention Real Options. The idea of keeping options open, and particularly of paying to defer commitment, is becoming a huge enabler. I’d love to get this to the point where I can value options more accurately. It’s already helping teams defer decisions at my client, particularly around tool choices and architecture / design. I’d love to have better ways of measuring the cost of deferring against the value of the options it provides. This plays very well with Feature Injection – keeping our decisions around the analysis open for as long as possible, and minimising the analysis WIP – which also plays nicely into the Kanban pull system.

Manufacturing techniques do not map exactly into the Software world

Alan Shalloway switched it round first – it’s not that Lean principles come from Toyota, as much as that Toyota comes from Lean principles. The actual practices we derive from those principles will therefore be different. He separates practices into three different areas – Lean Science (flow, cadence, pull, systems thinking, etc.), Lean Management (leadership, coaching, visual controls), and Lean Knowledge and Stwewardship (kaizen, people and process improvement).

I think the over-application of manufacturing practices – or the assumption from non-Kanbanites that this happens – has formed part of the difficult communication between the Scrum and Kanban communities lately. We’re still mostly about the people and empowerment, honest.

Automated tests are crucial

Or, as Alan said, “Don’t let anything into your stream until you know how to get it out of your stream.” He talks about exit criteria, rather than acceptance criteria. Other speakers also brought up the need for automated end-to-end testing. This focus makes me happy, since it’s very well aligned with BDD (Dan would say ‘essential’). Having seen testing become the constraint on almost every one of the projects here, I’m going back to those roots. We’ve got some work ahead of us to sort out appropriate environments, engage the infrastructure and maintenance teams effectively, and find tools and harnesses to help us.

The alternative is an escalating cost of change as testers struggle with growing code-bases, often generated by teams still learning to create high-quality, zero-defect code. I don’t buy the arguments about “just a three-month project” or “prototype”, since I’ve seen these turn into full-fledged enterprise applications more often than not.

People, people, people

I know that most of the Lean and Kanban community are also involved in Agile, and are highly respectful and people-oriented. I was initially surprised at the focus on tools and practices, maths, metaphor, terminology and process.

That was when I realised that this community – even more so than most of the Agile communities I’ve been involved with – are hugely respectful, communicative, collaborative and fun-loving. They don’t talk about people much because it’s all about the people.

What particularly struck me was the lack of discussion about failure, either at a team or a personal level. Sure, speakers talked about learning, but rarely about that team that could never have delivered because of their lack of skill or that manager that stopped us doing the right thing, both of which are story-patterns I’ve heard a lot in the Agile community. Beneath every speaker’s message seemed to be an assumption that any team can achieve amazing results; that people are capable of adapting to situations, learning new skills and chipping in; that innovation is not merely possible, but natural. I’m revisiting my earlier thoughts about teams needing to be disciplined to try Kanban out – the things I’m hearing suggest that’s my novice approach at fault, not the team’s.

Amongst the rarities is John Seddon, who uses some fairly colourful language to describe a number of systemic problems he’s seen. I couldn’t pin him down to criticism of a particular company, team or individual, though, apart from one: “The only reason you employ someone like me,” he says, “is so that you don’t make the same mistakes that I did 20 years ago.”