Let Go

The really interesting thing about having a job for a while (over 2 years) is that you get a really good opportunity to compare one years performance against the previous year. And although many things change year on year, you know that one thing has been a constant - you.

And given that I'm not one for resting on my laurels, I look intently for areas where my activity has yielded an improvement, or for areas which, despite my best efforts, appear to have remained poor or under- performing. I'm pleased to say that 2012 has been a good year with some strong improvements in my department, but it has rather driven some odd behaviour in me. In summary, I'd say that I've started to let people 'get on with it' by themselves.

Ordinarily this wouldn't be an issue, but of course few of us work in a vacuum and there are a couple of side effects. Firstly, and the easiest to resolve, is a distinct lack of basic knowledge of what your team is up to. Of course, without having problems escalated to you or requiring your intervention, you never get to have those conversations where the poor guy or girl has to explain to the manager how things all went astray. So you need to replace these sessions win your own - either walking around chatting to individuals, or organising catchup sessions, steering groups, etc. Either way, it's solvable.

What is more difficult to fix is your peers and managers behaviour: when they continue to apply the same old rules and techniques to a situation which no longer requires it. So they insist on the same level of documentation, the same Spanish Inquisition when you have a meeting with them, the same panic when a problem is found - or, more likely, fever pitch levels of communication around a crisis because there hasn't been one for a while.

My suggestion to them: let go!

Recognise that the world has changed, and that it's changed for the better. That you need to change too, and up your game to that level that you wanted to be at when you first joined. And we'll all see the benefit.

The challenge for the rest of us, therefore, is helping them come to this realisation!

17 years .. not a bad run for a Start Menu

So i've had the latest Windows 8 release on my laptop for about 2 weeks now .. perhaps longer. I've come directly from Mac OSX and was determined to show that I could work as efficiently and effectively on Windows as I could on the Mac.

Sorry, but I can't.

For those of you who don't know (or who have a normal job), Windows 8 is Microsoft's latest and greatest operating system - one which builds on the success of such noble predecessors as Windows 3.1 and Windows 7. And, given the underwhelming releases which were Windows 98, Windows Me (remember that?) and Windows Vista, I was pleasantly surprised to see some radical changes.

The Close

There's an art in 'the close'. Ask anyone in the sales profession, or used to pitching ideas and they'll tell you all about how a brilliant demonstration or tangible rapport with your customer is worth nothing unless you can close the deal. Infact it's worse than that - you've probably burned a fair few dollars in the process.

Yep, closing a sale is critical; much like closing a film I think. Sure, I can accept a few duffers where the whole thing is a dream sequence or the saga is 'to be continued' but 90% of the time I'm sorry but I need a proper ending. It doesn't have to be happy, but if you're going to tell a story, write a book or make a movie please please PLEASE can you make sure you finish it off.

Cutting the film as you prepare to fight a wolf single-handed is not what i call an ending. Joe Carnahan please take note.

KPI KPI KPI

If you don't measure it, you can't manage it. How many of us have heard this?

Driving along the other day in the car I heard a noise. I can't tell whether it's getting louder, so I rigged up a microphone. And connected it to my laptop. Unfortunately there's a lot of background noise, so I keep my speed low. The noise seems to have disappeared.

Have I fixed the problem? Have I even measured it?

Some systems are acutely sensitive to measurement or the endeavour of measurement - you may be familiar with the observer effect - essentially it means that an observation of something affects what you are seeing. To observe a dark room you may need to illuminate it - it's no longer a dark room. It's hard to measure the air pressure in your car tyres without letting some air out, therefore you've changed the pressure.

And it's true also with human systems and processes. If you ask a team to report on the number of defects they have introduced, you may encourage a focus on defects, but you may also inadvertently encourage a failure to log trivial or quickly-fixed defects. I mean; nobody wants to be the team with the highest number of introduced defects, right? So we don't log the trivial stuff, perhaps we start forgetting about them, and we end up dropping defects into production.

So you then ask the team to report on defect fix times - surely an innocuous measure of how long a defect is outstanding? Yes, but longer is worse, so why raise the defect as soon as you know about it? Why not go have a chat with a developer first, discuss the problem, make a note on a piece of paper, wait for the solution to be found, and then log the defect, swiftly followed by a closure. The problem here is that your defects aren't being logged, trends can't be discovered, you may be inefficiently using the team - ironically real fix times elongate all because you've started to measure them.

How about measuring velocity? Certainly it's an 'output' measure - if a team delivers 400 story points in one sprint, and 300 the next, they've delivered 'less'. Is that a problem? Well it might be, so lets measure it. Hey presto, the next sprint they deliver 410, the following sprint 510 - excellent, we've got more output, right? Well no - all they did was relax their 'done' criteria so they didn't have to do so much performance testing - this allowed them to get on with more work, but the system is now 20% slower than it was before. A good result? Not really.

So we have to be careful what we measure, and thoughtful in what behaviour we believe it will encourage, and it leads us to consider what the purpose of the measurement is. I went to visit a company a couple of years ago who had transitioned to agile and asked them: how do you show that you are efficient? My question was clearly aimed to elicit a response which would include the metrics which they gather. The development manager looked at me quizzically and replied: we don't need to prove anything - we deliver value to our business at the end of every sprint, and they are happy to pay our wages.

The KPI in this case is clear and simple: delivery of value on a regular basis. And how would we assure that this continues? I believe it may boil down to three key scrum metrics:

1. commitment
2. delivered
3. done criteria

#1 simply allows us to ensure that the team is predictably delivering (as it must correlate with #2), #2 measures the value which the team actually delivers - it must be > 0, and must be acceptable to the customer, given our cost and #3 is our 'control' measure to simply ensure that no gaming of the other two values occur - in essence, to ensure that quality is maintained.

With these three, I believe we have all we need to measure, surely?

In Pursuit of Perfection

Very often i'll hear the conversation in meetings turning naturally towards a consensus that something is missing. Something which, if it were to exist, would have prevented the situation, would have made things easier, would have saved us money, saved poor Jonny from falling down the well, etc etc

And most of the time, this is absolutely correct. I mean, given that extra £100K we asked for, given the extension on the project, given the physical redundancy that we asked for 'last year' or the magic document which would have clarified the situation, we wouldn't be in this mess.

But we need to stop and think carefully about why this didn't happen.