Friday, January 30, 2009

Bletchley Park Needs You!

Bletchley Park is an unremarkable, run-down country estate in South East England. Unremarkable, that is, until you realise that it was where a team of boffins, including geniuses like Alan Turing, broke the German Enigma code in WW2. This allowed the Allies to intercept vital information and save countless lives. It is also likely to have significantly shortened the war - maybe by up to two years and 22 million lives. Its place in history is assured by this alone.

But even more remarkable, in order to break the code the scientists had to invent from scratch the first ever electronic computer - Colussus. Thanks to the efforts of Max Newman and Tommy Flowers and many, many others we have the computers we have today. Through their efforts, we have the software industry - the productivity tools, the games. We have levels of communication no-one could have dreamed of back then - mobile phones, satellites, GPS. We went to the moon, and are now eyeing up Mars and beyond. We have the ability to carry out advanced research, analysis and ultimate cure of crippling diseases. The potential they unleashed is endless.

Now a museum and tourist attraction, Bletchley Park is suffering from a crippling lack of funds. They need a huge amount of money to restore it to its former glory (around £10 milion). Anyone involved with the IT industry should be concerned by this - Bletchley Park represents the birthplace of our industry and as such deserves to be saved. So I urge everyone to donate just £5 to the cause, more if you can.

Also, if you have a blog or website, promote Bletchley Park's cause. Spread the word.

Wednesday, January 28, 2009

Yet another name for compromised agile process

Via Simon Voice:

wagile adj a cross between agile and waterfall process. The mess that's left if agile is only partially implemented without cultural change. See also: failure, compromised, doomed

Wednesday, January 21, 2009


I have just finished doing my own, personal retrospective of 2008 after spending a couple of weeks relaxing and decompressing. Definitely a cathartic experience that has left me re-energised and ready to go in 2009.

  • 2008 saw me go into several flawed companies/teams in succession as well as some well adjusted ones. Although I delivered results, they were nowhere near the level that I am used to getting, and the battles to get even those results were long, protracted and draining. Portia Tung wrote about something she called "The Wall". Well, I found my wall last year and although I managed to scale it, it wasn't elegant. So in 2009 I intend to only work with well behaved clients who genuinely want to change, or have already made the change to agile/lean thinking but need guidance. Life is too short not to. Consulting should not be a battle, it's a co-operation. More of that in a later blog post. But I also need to understand better what my personal "wall" feels like, how to recognise it more quickly and how I don't just scale it but burst through it.

  • One of the related problems in 2008 was isolation. Sometimes when you work as an independent consultant you can feel very alone and begin to lose focus (the ancient wood for trees syndrome). You really need to bounce ideas off like-minded people to identify root causes and figure out new and exciting ways to deal with them. So I intend to kick off a peer review group amongst some trusted friends and colleagues and see how it goes. I have used the peer review approach before but this will be more challenging since the people involved are likely to be on entirely different projects....

  • Last year I neglected the important-but-not-urgent stuff. Things like this blog, going to conferences, networking with people, getting the industry vibe. That sort of thing. So expect more blog posts, and watch out for me at the odd conference. I might even present at one (although it's probably too late for 2009).

  • In 2008 I learned a helluva lot about myself and the state of the agile nation. I am entering 2009 better educated and more aware of the issues which can only make me better prepared to recognise and solve some of them.

  • I had nowhere near enough fun last year. It was far too serious, filled with destructive conflict and injury instead. So I fully intend to make 2009 a better year - both at work and in my personal life.
So here's to a happy and prosperous New Year packed full of learning, delivering top quality software, and fun, regardless of what the current economic situation throws at us. Cheers!

Monday, January 19, 2009

You don't need bug tracking

I have just been reading a thread on an agile group discussing the best practice for bug tracking in an agile team. Almost everyone has immediately jumped in and suggested things like Bugzilla and Jira. At risk of this turning into a rant:

You do not need a formal bug tracking system in a healthy agile development team

Quite a sweeping statement. Let me explain.

The whole problem seems to come from a fundamental misunderstanding of what a 'bug' is. I define a software bug as "undesired or missing functionality". Now let's compare this to a definition of a 'story' - a story is a statement describing the desired functionality - i.e. it is an invitation to correct undesired or missing functionality... Sounds familiar!

In other words bugs are stories. And if they are really stories, then why treat them differently? Simply write them on cards1, throw them onto the backlog and let them be prioritised along with everything else. Bugs that are important to the Customer will always be done first. Unimportant bugs will get fixed eventually/never in the same way as unimportant stories would. 

[1] I use red cards so that bugs are visible in the backlog. That way if they start to multiply the team can stop and fix the problem causing it. 

Tuesday, January 13, 2009


I have been playing on Twitter for a month or so to see if it could be useful.

As yet I'm undecided, but it has been useful enough to capture idle thoughts on the run so I'll stick with it for a while longer.

For anyone interested in following my random ramblings I can be found here.

Friday, January 09, 2009

When weekly iterations go bad

Having tried several different iteration lengths over the years, I now tend to recommend iterating weekly. It provides maximum flexibility and adaptability while being extremely intolerant of waste - problems are quickly surfaced with such a tight feedback loop.

But it does not always work as I found out over Christmas.

Our live system broke. Something ate some important files so the app collapsed. This was quickly traced to the Jetty servlet container deploying to the /tmp directory by default. Not a problem in itself, but there was a default cron script that helpfully tidies up /tmp by deleting anything that has not been touched for 10 days.... Of course, the Team was in Christmas shutdown for two weeks, and sure enough 10 days after our last live deploy...<BOOM!>

We missed this because we were using weekly iterations. We were deploying to the various dev, QA, demo and live systems every week so the deployed files were never older than 7 days.

So beware...weekly iterations can bite back!