The Point of Maximum Learning

Reading time ~ 2 minutes

This post draws on some exceptional leadership training I attended in Cincinnati some years ago, a personal near-legendary experience from Summer 2009 and the fact that many of us actually flip back and forth from being visibly outgoing, strong and confident to being introverted, quiet and shy.

Recognising this model was something quite special for me – it highlighted why I gain so much from conferences, talking to customers, like-minded strangers and other controlled but potentially stressful situations…

http://www.socialpedagogy.co.uk/concepts_lzm.htm

In order to learn we have to explore, leave our comfort zone and enter the learning zone. Beyond the learning zone lies the panic zone where we are blocked (by fear) from learning – lessons here are only recallable in similar negative situations.

  • Individuals must find their own way into their learning zone, it’s unique to them.
  • Forcing someone out of their comfort zone out of their control may tip them immediately into panic.
  • The point of maximum learning lies at the cusp of the learning and panic zones.

I believe this is why we learn so much from failure and stressful situations and why we often only realize it when we face them a second time.

It’s also why I learn most from group workshops and preparing presentations. Getting out of my comfort zone and talking to people in public gets my adrenaline going and brain working.

A cautionary note. I’ve found that having recognized what’s happening and broken the seal on the comfort zone it becomes somewhat addictive. The boundaries between comfort, learning and panic zones shift and you need to keep finding something else to drive you onward.

Chris Matts is somewhat of a master at demonstrating learning on the fringes between learning and panic – talk to him about exploring deserted conference facilities at 2am armed only with a shopping bag, red wine and no water.

What things do you do that make you really uncomfortable but maximise your learning?

 

Red Cards

Reading time ~ 3 minutes

One of the best facilitation tools I own. How to get a group out of a rat-hole & back on track without personal confrontation and minimal effort.

Name: The Red Card

Concept: When a group is in discussion on a particular topic they can often disappear down “rat holes” or off onto tangents. Every member of an agile team is empowered to “red card” a conversation that they feel is going off track. The group as a whole typically rapidly decide whether the red card is warranted or not.

Usage: I ensure that plenty of of small (playing card sized) red cards are available in the team rooms. To introduce them to a team that haven’t used them before, I will usually take a large session such as release planning and introduce the concept of red cards as part of the facilitation tools and ground rules at the start of a session. What I tell the teams is:

“Whilst I’m facilitating, I tend to get drawn into the conversations and need hauling out, especially if I start ranting. Therefore the red cards are required primarily to shut me up – although feel free to use them on each other too!”

Once a member of the team first uses a red card, that’s it – the lid is off. Expect use of cards to take off rapidly. (see “breaking the seal – part 2“).

Background: Chances are this has been used before me elsewhere in the world, but this is a tool I introduced to my teams after returning from Agile 2009. During one of the evening sessions there was a panel discussion. Questions were submitted in advance and each panelist had 2 minutes to discuss. After the whole panel had their say, the audience were given an opportunity to vote. On every seat was a large red and green paddle. If we wanted the discussion to continue we voted green. If we wanted to stop and move on, we voted red.

When I got back to Cambridge I introduced it during some training I was running. I “borrowed” my eldest daughter’s red & green art straws. There were a few “hot spots” on the course where 1 or 2 attendees would lose track. We had a great team who immediately raised a red straw. They enjoyed calling each other out so much that we had red straw warfare at one point!

After using the same in a couple more sessions it became clear the green straws weren’t needed. The red ones were getting tatty so I raided the stationary cupboard for some red card instead, cut this into pieces about the right size to hold up visibly and planted a few in the team rooms. These are now the social norm for facilitators on many teams worldwide but probably not well-known outside the company I’m at right now.

Impact: Of all the tools I’ve used over the last 2 years this one seems to have had one of the greatest impacts on teams and the most viral spread within the organization I work with. Even the management team now red card each other and they don’t even have the cards in the room. Like all good verbal anchors, everyone now knows what “red card” means during discussions. Better still – even on difficult teams I’ve not yet seen anyone use red cards in a socially unacceptable way.

Try red cards out on your next big retrospective – you might want a stooge to break the seal first of all and chances are you’ll need to set yourself up as the first target but once the team have been through this once, facilitating meetings will become more of a team sport than a job for you.

Agile 20xx – It Takes a Team

Reading time ~ 3 minutes

Inspired by this post I just read from Seth Godin. As an average joe, hob-nobbing with CEOs isn’t so likely for most of us but the interpersonal interaction certainly is worth making time for. However…

If you’re paying to learn and thinking of attending Agile 2011 (or any other really big conference) take a team!

For the last couple of years I’ve attended the big US Agile Alliance conferences. I love going although I miss my family; I really enjoy the social interaction, spending time with (on the surface) a bunch of smart, similar-minded people sharing a week of learning, collaboration and fun. There are of course undercurrents (see this old post from Jean Tabaka) but I still find attending these conferences a rewarding experience.

For anyone that’s not been, the Agile 20xx conferences are huge and seem to be getting bigger every year. The number of parallel tracks – all with great presenters means you really have to make a plan.

Each year I’ve attended, I’ve had the luxury of going out as part of a team. My advice to future attendees is the same – take a team and collaborate on what you want to see.

My goal each year is to walk away with at least 3 key pieces of new thinking that would add value to my teams. The travel and conference fee for just 3 ideas might be excessive but as I said, I also go to learn, collaborate and have fun.

If even 1 of the ideas I bring back is sticky enough to be introduced successfully to a group of nearly a thousand engineers worldwide then I think that’s worthwhile!

So which sessions do you attend?

Personally I tend to steer away from the “rock star” sessions. Most of what they’re presenting is covered in their current or forthcoming books (and I read a lot of those already) so I don’t get much from them. Other members of my team don’t read so much and so will go along to some of these. Get the team to strike a balance but make sure the motivation is to learn and share, not just to meet “famous people“.

The stuff out there from people without book deals is rarer so I make the most of those sessions but less-experienced or well-known presenters may mean a higher risk of a not-so-good session.  Also keep an eye out for the open space sessions and lightning talks. You’ll find a lot of up-and-coming talent and thinking out there but again, your mileage may vary.

I also tend to look for things that are relevant to my current context, and future direction, not just my current role. A big part of my interest is in viewing things from other people’s and roles perspectives – for example I’ve never formally had the job title of “tester” but “Agile Testing” is one of the best books I’ve read that really “gets” cross-role pairing and test strategies – relevant to developers and managers, not just testers!

Others may prefer to spend the entire week in “UX” or “Testing” tracks but generally I strongly discourage spending the entire week in a single track in your own domain – you just don’t learn enough of the other interesting gems. Maybe it’s just me but agile isn’t just about your own specialist area, it’s about the whole team and organization.

Having presented at Agile Cambridge last year; I and my team have submitted a couple of proposals for Agile 2011 as we’re hoping we can start to give something back. There’s a lot of presentations out there so our chances are slim however despite the number that don’t make it, there are hundreds of great ones that do.

When planning your sessions, take a team and go for a knowledge portfolio – balance risk & reward to get maximum return on your investment. You won’t regret it.

 

A Decade of What?

Reading time ~ 3 minutes

Ten years since the Agile Manifesto and where are we?

Before I get flamed, much of this article is deliberately tongue-in-cheek but there’s a serious element to it.

Flashback: Chicago 2009.

After an amazing week at my first ever Agile conference I had the privilege to sit in the hotel lobby relaxing & talking shop with a few presenters & attendees.

Although I’ve not made time to catch up with him since; the ~day I spent at Agile 2009 with one of that group of attendees was career-defining. In just a day he taught (or perhaps reminded) me to open my eyes and see the world as it really is – not how it’s marketed to us. This post is inspired by that experience.

During one of many conversations he asked me if I’d read Mordant’s Need.

Being a fan of the Thomas Covenant series  I had secondhand copies of both books in my personal library but had never read them.

Some weeks later I finished the textbooks I’d been working through and switched my bedtime reading to fiction for a while. I picked up “The Mirror of Her Dreams”, blasted through it and moved onto the second book – “A Man Rides Through”.

At some point at about 4AM after yet another bout of insomnia and a reading marathon my mental lights went on.

The entire first book builds up a classic “long con” – a confidence trick drawn out over years – to the detriment of everything else. Incredible.

Now for some fun. Picture this…

SnowyOwl Surf Resort – 2001:  Post-Y2K, the .com bubble is ready to burst,  everyone with half a brain is in software and the consulting gigs are drying up…

Guys. Things aren’t looking so hot for us Cobol developers any more. We need a new cash-cow to milk…

Time passes,  brainstorming happens (with the only thing to hand – those little pads of hotel room stickies)

…well, what are we any good at?

duhhh – Writing software.

OK, that’s a good start but it’s no fun any more – what do we all hate about writing software?

… Maintenance…

…Documentation…

…Management…

…Long isolated hours…

I’ve got it! Let’s take everything we loved about writing software, throw the rest away, package it up and market it back to all the noobie developers as a revolutionary new way of thinking!

Hmm. I think we’re going to need some marketing to pull this one off…

…I have an idea, my buddies at 4N keep complaining nobody except hotels wants to buy stickies any more and they’re gonna be out of work soon. I reckon we can arrange some sort of reciprocal deal.

Sales & Marketing join the team…

So here’s the deal. Marketing to developers is only going to get us so far. We need a top-down approach as well.

…How about we add in project management 101 and package the whole shooting match up into a name that execs will think means better, cheaper and faster.

…Let’s call it “Nimble”.

It’ll be great! I see it now, a pyramid training scheme, conferences, book deals and… oh boy – consulting gigs to die for!

…You know what, this just might work but it’s too easy. We need to throw some stuff into the mix to make it that little bit unreachable for the majority of our marks – keep ’em coming back for more.

While we’re at it, let’s roll in a whole new subset of jargon for extra obfuscation and overlay with some real punchy one-page marketing.

Some years pass…

MickeyWorld 2010 – “Nimble Conference” keynote speech:

…In fact, if Nimble’s not working for you, that’s because You’re doing it wrong.  Donate a million bucks to one of our Gurus and you too will have perfect development projects, products everyone wants and fault-free software.

Here’s the real data from one really successful project to prove how great it is.

Present day – all over the world:  Everyone’s all-in. Despite the vision of a digital paperless office, our stationary budgets have tripled – but don’t the walls look pretty!?

OK, back to reality.

I wouldn’t have things any other way right now. How else would we counteract the incredible momentum of Taylorism and the erosion of good old common sense. Writing software in the 21st century is all about the business, coding is just a fragment of the job.  Gone are the days of a neat idea and a pile of VC funding, so too is the ability to write cool games single-handed at weekends (most of the time).  Here’s how we can make software development fun again. Better still, now we have the tools and support to demonstrate that software teams deliver real business value.

Look beyond the methodology marketing, the processes, the practices, the tools and get back to the root of why we’re doing this. Software is generally a means to an end. Agile, Lean, Scrum, Voodoo, whatever; our goal is to deliver business value to the best of our abilities.

I’ve committed my career to this. I’m having a fantastic time. Much of what I’m seeing in the agile & lean community is great but for large-scale enterprise software product development and large corporations it still is very hard work to make this stuff stick.

I don’t plan on giving up any time soon.