I am sometimes asked by people wanting to understand more about retrospectives "Can you tell me a story that demonstrates a powerful outcome that resulted from a retrospective?".
Sorry, I am not able to produce a fantastic retrospective story out of a hat. I have come to realize that this question is similar to "Can you tell me about a grand design that resulted from regular refactoring code?" or "Can you tell me about a disease that was cured by taking regular exercise?". These questions make an assumption about the result of a practice and then ask for confirming evidence.
The power of regular refactoring, regular retrospectives and regular exercise is that they prevent big problems from happening so there should be no war stories or miraculous transformations!
Of course, I have worked with teams where running regular heartbeat retrospectives made a big difference in the long term but because the changes were gradual and slow they don't make great elevator pitches.
Had lunch yesterday with Kent Beck who was over in UK promoting the Agitar tool set.
Over the last year, Kent has been encouraging developers to take more accountability and responsibility for their work. Change starts with you as an individual. By being open about the quality of your code and progress of your work, a developer can show how they are actively supporting their current project proposition. Being open can also give you the upper hand in organizational politics.
A memorable quote from Kent was "Agile development does not mean means never having to say you're sorry". Developers need to take responsibility for delivering value to their customers. That means developers need to get more savvy with their project proposition and just exactly how it is going to deliver value.
The original focus of XP was how to write and deliver quality code but that ceases to be meaningful if that code does not deliver value. Developers need to start paying attention to the wider project perspective and get their heads around how their code generates return on investment. Kent suggested that developers can learn something from seeing how Sales people go about their work. Sales people have visible revenue targets and quotas to meet that help them focus their efforts in generating value for their organization. Software developers need to grow-up and start understanding their place in the value-chain better. A concept that I heard about recently from the oil drilling industry is that it helps to think in terms of "consumables" rather than "deliverables".
This month I have been working with a Lean Software Development project team. The team actually know figures for their burn-rate (cost of development per week) and also the cost of delay per week. This helps give them focus on what to do next. Sadly such awareness is rare in software development, most developers work away oblivious of project costs and benefits. It's rare for developers to hear about the value generated from their software releases. Many companies are set up to take deliverables from IT and (aside from bug reports) that's the last developers hear about it. When I was at Egg internet bank, one team were slogging away on a legacy code project and it really buoyed their efforts when their customer came back to them after a release and actually tell them how many tens of thousands of pounds had been brought in as a result of their efforts.
So developers, don't just polish your code without understanding how your software delivers value - start asking for some real numbers!
Finished my last coding gig on Sun SPOTs yesterday. Back to coaching again!
I have blogged before that, in order to coach developers in agile software development techniques like Test-First programming, I find I need to do some solid stints of coding during the year. Recently I put together a "utilization" spreadsheet to find out just what percentage of the past year I spent on programming work versus consulting/coaching (and going to conferences).
It turns out that I have roughly a 50:50 split between coding and consulting gigs which surprised me - I didn't think I wrote that much code (maybe I was in the the pair programming backseat).
I also found out that only about two-thirds of my time was billable. No, I did not spend the other four months of the year months at conferences ;-) I only spent six weeks at conferences last year (more about conferences later). Networking and sales soaked up the rest of the time.