LSSC 2012 was very, very different – challenging a ton of sacred cows, trashing some long-held ideas and giving me a bunch of new thoughts and understanding. The format was perfect: seemingly flawless organisation; amazing speakers, including some that we wouldn’t have heard if we weren’t in Boston; a Lean Camp unconference where I actually felt panic at not being able to attend all the sessions; long breaks giving us plenty of time to talk, network, reflect and synthesize ideas; innovative sponsors whose presence added value; lightning and ignite talks with hours of brilliance compacted into small spaces of time (thanks for letting me rant instead!); great venue, food and service and of course the fantastic mix of attendees.

Here are some of the joyous nuggets that I learnt and the people from whom I learnt them, paraphrased for your quick enjoyment.

Hillel Glazer: Demand pulls most of us to start projects, but it only really works when it pulls us to finish them and produce something. For that, we need to work on capacity. David Joyce echoed Hillel’s sentiments in his talk when he told us to stop disbanding teams right when they’re at their most productive. That’s part of the problem.

Steven Spear: If you can’t make predictions, you lose your ability to be surprised, which means you can’t learn. This spawned a Twitter conversation with Karl Scotland and others about complexity and whether expectations apply in the complex space, which helped me with my ignite talk. I really love Karl’s take – that we should at least predict impact if not outcome. Steven was talking about nuclear reactors, which I hope are a little more predictable than the software we produce.

David Anderson: It turns out that the community is doing more than just software these days, so the Lean Software Systems Consortium has rebranded as the Lean Systems Society. It’s modelled on the Royal Society, and I’m honoured to be named as a fellow. Particularly interesting was David’s comment that they’d observed the behaviours and values of the community, and drawn up their Credo or value statement accordingly – not the other way round! Talk about making process policies explicit…

Michael Kennedy: From TPS – “Product development is not about developing cars, it is about developing knowledge about cars.” Michael showed how sharing knowledge across projects can help us to build quality in. He showed how Toyota explore new ideas, resolving complexity while developing expertise before using them in production, which falls right into place alongside some of the Cynefin conversations that have been happening in the UK, as well as Dan North’s call for Deliberate (as opposed to accidental) Discovery. One excellent quote: “They’re only standards because they’re the best we can do right now. Engineers are expected to break the standards. Managers decide which standards they want to be broken.”

Gregory Howell: It turns out that the construction metaphor we’ve been using in IT doesn’t even work out in construction! One study found that 85% of construction managers had underestimated the complexity of the project. Pushing people to go faster isn’t as useful as working on the interfaces between people. The stories he told mostly centred on slowing things down and increasing quality and fluidity of hand-offs in order to go faster.

Robert Charette: All exchanges of goods and services are exchanges of risks and opportunity. Robert used the example of a plumber who’s taken on risk by investing in his own skills. He has an interesting model for risk and particularly market share, and challenged us to think about the kind of things which might end up bringing a company as successful as Apple down.

Jim Benson: If you have a repetitive task, record the metrics for how it went each time on your kanban board. Jim was talking in terms of Personal Kanban, but I can see how that could be useful for eg: retrospectives. Already added the “exercise” column to mine! Jim also taught one table at the Brickell Key awards that if you play buzzword drinking games with the Lean & Kanban crowd, you’re going to get what you measure… dangerous stuff. Congratulations to both Brickell Key winners, Jim and Arne Roock.

Mike Burrows: Limit WIP in portfolio too. Mike also suggests limiting the amount of money carried in the portfolio, allowing you to have a few big projects or several small ones. Richard Hensley apparently thinks a similar way. Karl Scotland shared another of Mike’s suggestions: limit dots in progress. Put dots on the cards every day they’re in progress and you’ll be able to see the flow very clearly.

Karl Scotland and Larry Maccherone: Our data is really dirty. If you start using 2-sigma thresholds to make SLAs, you’ll probably get stung. It doesn’t follow a normal distribution, in part because developers simply don’t update the statuses on time – they’re too busy doing the work! Outliers are also interesting. Rally has some neat tools to show you where your percentiles really are, but they’re in competition with Lean Kit’s lounge with its hot dogs and ice-cream. Lean Kit definitely win the prize for brand awareness this trip.

Yochai Benkler: This was the most mind-blowing talk for me. It turns out that our desire to collaborate is partly genetic, and only prevalent in 60-70% of the population. The industrialised world is slowly moving towards models in which we *do* collaborate – it does actually form part of our evolution, and making collaboration the norm can help – but our innate desire to collaborate can easily be disrupted by extrinsic rewards and punishment for failure to collaborate, amongst other things. Motivating people to collaborate is way more complex than we thought.

This is only part of the learning I take away from LSSC 2012. Already signed up for LSSC 2013 – hope to see you there!

There are notes underneath each slide which are a cut-down version of the kind of things I talk about. I’ve even left the exercises in, with a description of what I do in each.

I am releasing these under my usual favourite licence – Creative Commons share-alike. That means that as long as you attribute me, and are similarly generous with any derived work you make, you can use the slides commercially and base your own work on them.

Yes, that means that if you want to, and you feel qualified to do so, you can use the slides, run the course and get paid for it. If you don’t feel qualified, feel free to experiment. Just please give a nod my way when you do!