The Pask Committee have given the Gordon Pask award to me this year for deepening existing ideas and coming up with some pretty crazy ones of my own.
I can only do this because of the fortune I have in my communities, including some great coaches on either side of the pond, the Extreme Tuesday Club, Thoughtworkers and alumni, and the wonderful online communities in Lean and BDD.
My communities give me a safe place in which to play and get feedback. I am a member of a community of thinkers, and if I should happen to be a catalyst more than others, I consider that to be a tribute to those who have inspired me. This is as much a measure of your success as of mine. Thank you all.
I’ve been invited to speak at the Lean Software and Systems Conference in Atlanta, April 21st to 23rd 2010.
BDD, often described as “TDD done well”, is strongly aligned with Lean
principles. It’s a pull-based approach to delivering software that
matters through the whole software lifecycle, from vision to code. It
minimises rework and over-delivery, bakes quality in, and is founded
on respect for people in their various roles and the language that we
use to collaborate and communicate. BDD has its origins in NLP and the
Sapir-Whorf hypothesis: the idea that the words we use affect the
cognitive model of our work. It decouples the learning associated with
TDD and Acceptance Testing from the word “test”, using the more
natural vocabulary of examples and behaviour to elicit requirements
and create a shared understanding of the domain.
In this talk Liz will introduce BDD, show how to model it using PDCA,
and talk about how its practices can provide quicker feedback and help
us to turn a vision into reality faster.
I’ve been working on this talk for a few months, and hope you enjoy it.
This has been a very special year for me. I’ve been fascinated by Lean principles for a while, but only recently had the opportunity to do some serious study into them and try out the related practices and tools. It’s also taken me some time to work out how strongly aligned Lean Thinking and BDD are. The community around the Lean and Kanban movement has been very welcoming and respectful this year, and I’d urge anyone who is interested to make their way over to the Limited WIP Society, where some excellent blogs, articles and examples of Kanban boards etc. have been collected for your accelerated learning.
We held a bag-stuffing event at Agile 2009, and used it as an exercise in applying Lean techniques. (Hugo Corbucci and Hamlet D’Arcy both posted excellent write-ups of this). One of my proudest moments this year was when some of the Limited WIP and Kanban community asked me to stand up afterwards as someone who could be approached with questions about Lean and Kanban. I’m an effective Agile coach, but my knowledge of Lean still felt new to me at that point. To have this kind of validation meant a lot to me.
I appreciate those of you who have helped me in this journey for your extraordinary patience in teaching me and providing feedback on my understanding. You know who you are.
I’ve been invited to submit a talk to the Lean and Kanban conference in Atlanta, on how Lean principles have changed the way in which I approach TDD (which of course is BDD for me).
For those of you on this side of the pond, I’ll be rehearsing this talk on November 9th at Skills Matter. This is a free evening, and there won’t be any podcasts or slides released – so it’ll be your only chance to see it this side of April!
Book here if you want to attend.
Please remember that if you’ve booked and can’t come, someone else may be waiting for your place – so send Skills Matter an email to let them know, and they’ll get in touch with the waiting list.
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.”
Just talked to Olav Maasen who’s been running around all day, getting sound engineers and sponsors excited about Eric “Guitar” Davis and the Troublemakers.
Version One and Accelinova have proved themselves truly Agile companies by responding to change quickly enough to sponsor them, and Chris Matts is chipping in too. Thank you very much! This is going to make a wonderful banquet even more awesome.
The Agile 2009 conference has been an incredible experience. As with last year, I find myself overwhelmed by ideas and lacking in sleep.
The workshops have gone well – thanks for the kind and useful feedback! It was a pleasure to meet Pat Maddox and watch him work. Seeing what’s happening in the BDD space with JBehave and Cucumber is also rocking my world. The little bit of code I wrote back last year is now out there, being used successfully in enterprises across the world.
My favourite experience of the conference has been the Programming with the Stars. I’ve enjoyed judging it enormously, and the quality of the performances from the contestants has made me look at my own development habits in a different way. I’m not sure I could have pulled off the “one hand each, no mouse” kata that was sprung on them today!
I’ve actually got to see some of Chicago while I’m here, too! Some kind friends took me out to Chicago Blues last night. The band were awesome. So awesome, in fact, that there is now a movement afoot to get them playing at Agile – either tonight, or at Agile 2010 in Nashville. I’ll be watching this with interest; I’m curious to see if there are any obstacles, what they are, whether the Agile fans can make this happen.
(Just as I typed this, a friend came up and told me that it looks close for tonight! That’s astounding… given that some of the people involved in making it happen didn’t get to bed until 4am… Thanks to Chris, Bonnie et al for setting it up!)
Here’s the myspace site for the Troublemakers and their gravel-voiced, energetic singer, Eric “Guitar” Davis. I’ve got a lot of souvenirs from this conference; very happy that their CD is amongst them.
I got a bit experimental with my mind maps at the Agile Coaches’ Gathering. I think it was a combination of the amazing and inspirational people, the fantastic choice of venue and the glorious weather that got me feeling so creative. Some people have asked me to put them up on the wiki, so here they are.
Comments