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?

 

Readiness to Serve

Reading time ~ < 1 minutes

A couple of years ago a friend said: (I’m paraphrasing here)

My team are paid a huge pile of money to do nothing most of the time.

As an analysis team for a financial institution their goal was to be immediately available at the first sign of an anomaly in the system. Like every other good analysis team in the city, their goal was to identify and find a means of exploiting the next new anomaly before anyone else in the world did. When the rest of the world catches up, their edge is lost – until the next time.

Many times I see organizations saving pennies on billions of dollars of revenue to ensure they keep their teams “busy” or “fully utilized”.

  • If your teams are always busy, how will they be able to cope with the next bump in the road?
  • If your teams are always busy, how will they be able to stop and see the big picture?
  • If your teams are always busy, when will they have enough time to stop and sharpen their tools?
  • If your teams are always busy, who is looking around to see what the rest of the world is doing?
  • If your teams are always busy, who will you have available to exploit the next change in the market before your competition?

Unless money really is that tight, staff up your teams or balance your investment portfolio not just to deliver your current needs but also provide sufficient capacity to be “ready to serve” when the next anomaly hits your market.

Software Is Just A Means To An End

Reading time ~ < 1 minutes

Last year Chris Matts wrote an insightful post reflecting on the Agile Manifesto and business analysis. At the time it sparked some creative thinking but I didn’t turn it onto the right words.

Now I have them.

Writing software is just a means to an end. Our customers and users don’t always want software (with the exception of games). They want to be able to achieve something and fulfil their role.

Software was developed to help us achieve things in more effective, efficient, accurate ways. We have CAD tools because it’s seen as better than traditional draughtsmanship. We have Financials applications because it adds more value than traditional double-entry book-keeping. Software is written for commercial fighter aircraft because we made them too complicated for people to fly alone.

I could go on…

Remember you’re solving someone else’s problem or making someone’s life easier or safer, not just writing software for the sake of software.

The next time you think about adding a speculative “neat” feature or idea to the backlog, think about who will actually get value from it.

Admittedly, sometimes it might just be to tick the box on an RFP in which case your investment should be lower than if you’re delivering for real end user value but there is business value in doing something.

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.