10 June 2011

A Survival Guide for New Agile Coaches - It Pays to Lose Sometimes

My son loves to play video games, especially hockey (hey, we're Canadian - the hockey gene isn't recessive here).  He also loves to win, and win big.  He sets up the game so that there's no salary cap and any and all trades among teams are accepted.  He then proceeds to create the most stacked team in the history of the sport, followed by putting the game at its easiest settings.  What follows is a constant stream of hugely lopsided wins.

That's great, right?  His self-esteem must be at an all-time high!  Yes, it is.  It's also complete crap.  In life, we don't always win.  We face constant challenges, and true self-esteem comes from overcoming those challenges and recognizing that even when you don't win you did the best you could.

Coaching Point
While it would be nice if everything went perfectly all the time, life isn't like that.  Software development is even worse - I remember actually experiencing fear when a program compiled the first time without an error!  We learn much more from our mistakes than our successes, and constant learning is essential to delivering the right software at the right time with the right level of quality.

So, if constant learning is essential and we learn more from making mistakes, shouldn't we make mistakes all the time?  Well, yes... sort of.  Big mistakes that aren't visible or acknowledged for a long time aren't good.  Very small mistakes that are caught very quickly and communicated with the team are OK, though, and are a fundamental part of learning.

Small mistakes are small User Stories built to the Product Owner's satisfaction that receive feedback during a demo that means a Story will need to be changed.  Small mistakes can be automated tests that fail because we haven't written the code yet to make them pass!  Small mistakes can be assumptions made about how to approach the development of a certain task that, while programming, are exposed as flawed.  Small mistakes are spikes that are used to determine if a certain technology or approach can even be used to build the software.  Small mistakes allow us to learn without really bad consequences... as long as we learn from them, of course!  Small mistakes are the nesting ground of innovation!

Teams must be empowered to make a constant stream of small mistakes!  They have to feel that it's safe to make a mistake or two without fearing for their reputations or even their jobs.  That's the only effective way that we currently know of for delivering good software without a huge overhead cost, and to deliver truly innovative solutions.

We have salary caps, we can't trade players at will and for the most part we can't tweak the settings of the software development "game" to make it easy.  So, we have a lose a few games along the way in order to learn and thus to be truly successful!

No comments: