The story is used in Scrum and other methodologies to suggest that only “pigs” – the people whose bacon is on the line – should have the right to speak in stand-ups. This deliberately excludes management.

Yesterday, Dean Leffingwell spoke on the subject at Agile 2011. He pointed out that the practice calls out the chickens as the “bad guys”. “Wrong!” he says. “These are the people who run the company.” Quite aside from some cultural implications of calling people “pigs” – it doesn’t go down well in countries which consider pigs to be unclean, for instance – excluding management from stand-ups can be disrespectful at best, and damaging at worst.

I finally decided to be done with the Chicken and Pigs analogy and practice after a roleplay organised by Derek Wade, in which the manager had something very important to share – something that would have reduced the stress the team was experiencing, as well as the workload, the weekend’s overtime, and the risk to delivery that was approaching our fictitious team.

The manager started to speak. “I…”

“You’re a chicken,” the Scrum Master announced. “Next!”

Let’s not.

I’m told that it’s too late to get the Pask sorted out for this year – we’re Agile, but not that Agile! Please keep nominees in mind, though. Many members of the committee are talking and are keen to keep the award in some form, so chances are it will be back next year. Watch this space.

It’s that time of year again that the Pask committee meets at the Agile 20XX conference to vote on the nominations which have been made.

The committee is mostly made up of people who’ve already won the award in previous years. We won because of our ideas, because we’re good at spreading them, because we made a difference, because we were under the radar… but not because of our organizational ability! So please forgive this very late post.

We are still collecting nominations (email pask-nominations AT agilealliance DOT org) and will be voting at some point during the week.

A number of people have suggested that the Pask Award doesn’t matter. I thought I’d share some of the things which have happened to me since winning the award last year, so that you can understand exactly what it is that’s being given away.

The Pask Award

It’s always wonderful to be recognised for your work. The award also comes with quite a hefty bit of money – enough to pay for a couple of international conferences, and then some. There’s no trophy, but you get to tell people that you won the award. Your parents will be dead chuffed. You can stand on stage and recognise all the people and communities who’ve helped you. And that’s just the award itself.

The Side Effects

The number of people following me on Twitter doubled overnight, from 500 to 1000. Then it kept climbing. I am now followed by over 1,600 people. That’s enabled me to spread a lot of other people’s messages, too.

Because people have started to know my name, I’ve started getting more offers of work. I’ve had requests for help from the USA, from all over Europe, from India. (Some of them have even offered to pay me!) I’ve been able to raise my rates a bit, and I’m getting all kinds of interesting opportunities which I didn’t have before.

Then, there’s the conference invites. Lots, and lots, and lots of invites to speak around the world. I’m sorry to those people that I’ve had to turn down – I am simply getting so many invites this year that I can’t do all of them, especially if they’re at the same time as others.

Because of the conference invites, I’m getting to speak more, and spread the ideas from my communities, which leads to more Twitter followers and more exposure and more conference invites… I suspect the escalation from this has started to reach a natural limit, but again, I apologise if I haven’t quite been able to keep up. It really has been a little bit insane.

The Further Side-Effects

Because of the invites, I’ve become a better speaker. This means I can now spread the ideas more effectively. They weren’t all my ideas in the first place – many of them came from communities in London and around the world – so now people recognise that I can share ideas effectively. This means more people are now giving me lots of ideas to share! So I’m learning an enormous amount, too. I feel insanely privileged to have such excellent friends and colleagues.

In short…

My life currently rocks beyond my ability to tell it. I’ve been able to help other people’s lives to rock too. A lot of this is due to the award. Many thanks to those who nominated and voted for me, and to the Agile Alliance for continuing to make a difference.

The Gift

If you would like someone to receive a similar gift to the one that I’ve been given in this last year, enabling them to spread their knowledge and ideas to other communities that they wouldn’t normally reach, please nominate at pask-nominations AT agilealliance DOT org. You can see the kind of things we’ve been nominated for in the past. Mostly we’re looking for people who aren’t particularly famous or well known; who haven’t written books or run keynotes, who sit “below the radar”, and could benefit from more exposure – and who will benefit their communities in turn, passing on the opportunities and making the best use of the fame that comes with it.

Do you know of anyone who’s helped their communities? Who’s driven Agile forward in difficult or unusual circumstances? Who’s created an idea, or a community, or a tool, that’s truly revolutionary?

If so, don’t wait – post that email now.

The CodeRetreats are focused on having fun while learning, and follow a simple formula: 45 minute sessions of pair-programming on Conway’s Game of Life, then deleting all the code written and taking a 15 minute break. As well as giving up his time, Corey organises a storming lunch. Thank you Corey!

Deleting the code, for me, is the magic. I didn’t fully understand until Corey tutored me out of my outside-in, BDD habit at the last Code Retreat in Bletchley Park. “Why did you start with the Grid?” he asked.

“Well… because that’s how I’ll know I’ve solved the problem.”

“Are you trying to get things done?” Corey asked. “Don’t try and get anything done. 45 minutes isn’t long enough, and we’re going to delete the code anyway. Why not pick something interesting and see if you can find a different way to do it? Why not look at the rules, or a single cell, or the number of neighbours?”

I got it. CodeRetreat isn’t about solving a problem or getting something done. It’s explicitly the opposite. It’s about learning, even if that means you never solve anything or get anything done. The 45 minute period is just long enough to learn significantly but not quite long enough to make any real headway, unless you already know the Game of Life backwards.

As part of teaching BDD and driving out various BDD tools, I’ve produced multiple implementations of the Game of Life in Java and C#, to the extent where I already have a good idea of the classes I’m going to use. That can actually be a handicap in the CodeRetreat, because it makes it hard to learn anything new. I often find myself letting my pair take the direction, just to see if any other interesting patterns emerge.

In Orlando, we were lucky enough to have several great programmers amongst us – including Michael Feathers, Brian Marick and Uncle Bob. Having already experienced a cage match between Michael’s Haskell and Brian’s Clojure implementations of the Game of Life, I was excited by the opportunities to learn a new language. Brian was kind enough to show me some of the language features in Clojure. We didn’t really get very far with the problem, but that’s OK – the object was not to solve the problem, just to learn. Thank you Brian!

For the last session of the day, we voted to use a bit of extra time to conduct a longer session, and Bob kindly volunteered to help me continue exploring Clojure. We started with a function which would find all the potential candidates for life in the next generation, and worked from there.

10 minutes before the end of the session, we had a working copy, which Uncle Bob has kindly blogged here. The code is a little tidier and a lot more readable than the version we ended up with. I need to find out what conj and % do! We should also have deleted it, but since we had already gotten something done, it was too late.

Clojure turns out to be a very beautiful language, and Uncle Bob is a lot less scary in real life wonderfully patient mentor. Thank you, Bob!

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.

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.

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.

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.”

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 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.