First off, two tutorials:

I’m running my first Deliberate Discovery, Cynefin and Real Options tutorial at Skills Matter on 29th May. These three ways of thinking and modelling software development and the world in general have really helped me, and I’d like to pass the techniques on. Highly workshop-driven and not at all technical.

At the end of September I’ll be running my 1-day BDD tutorial as part of Agile Cambridge. This is the only BDD tutorial I’ll be running this year, so if you’re interested, get in there now! Dan North (my mentor in all things BDD and Agile) and David Snowden (Complexity Thinking and Cynefin guru) are keynote speakers, so it promises to be an excellent conference!

I’ll also be speaking and running workshops through the year:

The Next Generation Testing Conference organised by Unicom is on the 23rd. I’ll be on the panel talking about Agile, and particularly ranting about our obsession with granularity and our need for certainty even where it doesn’t really exist.

I’m going to be talking about Real Options at Dev Tank in London on the 29th, after the Progressive .NET Tutorials. It shouldn’t be a long talk, so lots of opportunity to catch up with your fellow devs over a beer. More details to follow – watch the space!

On June 7th, I’ll be giving an overview of BDD, how to do it well and why it works at Agile East Anglia. If you’ve been out of the loop on BDD, this is a great chance to get into it, and I’ll be answering any questions you have too. I think there may be just one ticket left…

In August I’ll be at Agile 2012 in Dallas, running “Turning and turning in the Widening Gyre”, a workshop on complexity and deliberate discovery, and “BDD: Look, no Frameworks!” on how to do BDD using custom DSLs instead of BDD tools, while keeping steps maintainable and readable.

On 21st – 22nd September I’m honoured to be one of the keynote speakers at Lean Agile Scotland. Topic still to be decided, but it’s going to be related to people and the inside of our heads; one of my favourite minefields.

I’m also speaking at GOTO this year (October 1st to 3rd, Aarhus, Denmark). In my talk, “To be honest…” I’ll be looking at why honesty is so important and yet so hard to do.

In the meantime, I have some days free for in-house training or coaching. Please get in touch now, before the rest of the year gets this busy too!

The outcome of the unconference wasn’t really stated. When you understand that a complex domain is one in which the cause of an outcome can’t be perceived except in retrospect, this might make more sense. The only thing we were trying to do was see if there was a way of using complexity theory to help inform our practices, and if there were some practices from Agile and Lean that complexity theorists might find interesting – a mash-up!

There’s one problem with this.

Currently, the best-known leadership of Complexity Theory revolves around the company Cognitive Edge. These guys have some amazing methods for making sense of domains, spotting complex problems and providing data which calls out “weak signals” that might otherwise be lost. I paid good money and took time off work for the course last year, and it was worth every penny. For the non-initiated and tl;dr, imagine five new types of retrospective, a method for reducing planning meetings to five minutes, and six different ways of making the output from them heard, and you’ll get a vague idea of the impact and scope. Oh, and they’ve got software for running the retro across countries.

Except…

I can’t currently use the methods they taught me, not as a professional coach. The methods are open-sourced, but released under a non-commercial, non-derivative Creative Commons license.

Cognitive Edge, your Wiki says (emphasis mine):

The Cognitive Edge wiki exists to provide a collaborative space for accredited members of the Cognitive Edge Network. All accredited practitioners should feel welcome to contribute to the ideas and concepts in these pages.

The licence prevents me from using your methods as a professional coach:

You may not use this work for commercial purposes.

The licence also prevents non-accredited people, which is most of our communities and a lot of CALMalpha attendees, from creating their own ideas:

You may not alter, transform, or build upon this work.

While I might be able to build on your work, I’m unwilling to do so as long as my efforts fall under this licence. I also can’t pass on anything to the people I work with for their contribution.

Can you see how this doesn’t mesh with the idea of a “mash-up”, and goes completely against your ideas around multiplying perspectives?

So here’s my request.

Cognitive Edge, please, please open your licence up for commercial and derivative work.

The stuff you do is amazing. If you were working solely for the money, you wouldn’t have come up with these ideas. I can only assume that you, like us, are trying to make the world a better place. We will continue to attribute the methods to you and talk about how amazing they are. Those of us who’ve seen it will continue to point people towards your SenseMaker software (which is ground-breaking, world-changing, worth paying for the 1-day demo, and deserves the more rigorous patent applied to it – I look forward to the day when it’s a bit cheaper!)

As it stands, we can’t do anything useful with your methods. Worse, because you’re working in a space full of narratives and I’m working in a space full of very similar examples, I have to be very careful that my work – released on my blog under CC, non-commercial, non-derivative – is actually based on other sources (mostly Dan North and Chris Matts) and not on yours.

Please. Be generous. Reach out to your contributors, ask them, and release what you can.

Sometimes it’s worth doing something you can’t go back from.

Our industry is in an awful state. A really awful state. It took me a day and a half to recognize one of the problems. There’s a prevailing sentiment that I keep hearing that, “If only we provide the right bucket for them to deliver in, teams will deliver.”

You know what? This isn’t true.

Of the many developers I’ve worked with over the years, I’ve been lucky enough to work with the best. These are the developers who can code well, work in teams, learn quickly and respect and learn from differing opinions.

I shouldn’t have to be lucky to work in teams like this. Engineers don’t get away with it. Architects, pilots, restaurant staff and dustbin men don’t get away with it*. We have such a low barrier to entry in this industry, it hurts. I shouldn’t have gotten away with it for as long as I did!

While I was at the conference, a gentleman linked to one of my blog posts about Scrum and Kanban, calling it “pontificating rubbish”. I wrote it mostly because I was already fed up of the fighting between the two communities: there’s more similarity than difference. This gentleman said, “Can we just ship some software already?” Iain, I need to thank you. Your comments must have stuck with me, because by the second day I found myself thinking, “He’s right.”

One of the things we strive for in Agile and Lean is a high-trust environment; one in which the business give us the space and time that we need to deliver the things that they really want. As an industry, though, we don’t have that trust, because we haven’t deserved it. Even Agile and Lean haven’t solved the problem. Even Agile and Lean don’t ship on time, and even Scrum projects occasionally wait until the last moment to tell people it’s going to be late (and yes, I know this isn’t how you ought to run a Scrum project). So here’s the first problem:

Many of the developers I’ve interviewed over the last decade can’t communicate. They can’t code, even when they’ve been told that it’s part of the interview. I had one dev provide a code sample that they were completely unable to work with – I’m guessing a friend wrote it. I’ve had samples submitted which were ripped off of the internet. I’ve worked “with” devs who were sidelined onto useless projects, deleted afterwards, because they were no good at coding and too nervous to help. No wonder, as an industry, we can’t ship. No wonder those of us who spend our time at conferences and self-improvement workshops are befuddled as to why. The faculty at CALMalpha talked about how crews work, and the training they undergo. We don’t do that.

One of the things that David Snowden taught us is to aim for fail-safe probes – a thing that we try, in order to make a change, which might fail and which is safe to do so. He also taught us not to attack the problem directly. I’m not sure that this is even a complex problem, but the fact that it hasn’t been solved yet suggests it might be. So rather than saying, “Just ship it already!”, here’s what I suggest (and please, if you have an understanding of complexity theory and can see some stuff that might not be safe to fail, let us know quickly – I’m new at this).

Get devs to code in the interviews.

Do it, and spread your success stories. I’ve not yet found a company who’s done this and stopped. Code with them – pair on some silly, simple problem – and you’ll also find out what they’re like to work with, and whether they’re able to learn and talk to you.

The idea is not necessarily to filter the developers. If this happens industry-wide, we’ll quickly run out of devs who can code, and something else will happen. Perhaps a lot of them will be able to learn quickly, and you may find after some time that you’re frustrated looking for the ones who can code and you’ll settle for the ones who can learn. Or maybe the universities will up their game. Perhaps it will become accepted practice that developers spend time learning, and companies will give them more space.

If this fails, and we find that we can’t get people to code in the interview, we’ll be no worse off than we were and we might find out something more about the problem.

*Dear Dustbin Men

Without you life would very quickly grind to a messy and disease-ridden halt. You are my heroes. You do the job that I do least want to be doing, for a lot less pay than I’d do it for. This is why I’ve picked on you – not because I think you’re low on the list of people who need to work as a team, but because your job is so stressful in my estimation that I believe you have the right to work in any way you want. That I always see you working together, usually smiling, carting away all our rubbish and doing extra work to make up for Christmas etc., is amazing. Thank you.

(I have never yet seen a Dustbin Woman).

Devs, our job is ranked as really not all that stressful. We do not have the excuse.

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.