July 28, 2009 § Leave a Comment

This is a post about the practice of risk management through use of a ‘DEFCON Door’.

A DEFCON door? Well if you’ve seen that early 80’s film ‘WarGames’ starring Matthew Broderick, or if you simply know your US history, then you’d know that DEFCONs – Defense Readiness Conditions – are used to be a “measure of the activation and readiness level of the US armed forces” (as described on wikipedia). During the Cuban missile crisis DEFCON 2 was reached, with the US airforce readied up to go and bomb their cold-war rival the USSR.

And how might this be applicable to your typical day-to-day IT project? For starters, once on a project what we did was to find a spare door and to configure it as such:

Defcon Door

It’s very simple really. Along the top column headers are the various DEFCONs. DEFCON 1 would mean that it is the consensus of the team that the project is going to fail because of a particular issue; that a very serious risk has indeed materialized. DEFCON 2 risks are still very serious, and DEFCON 3 ones are merely lesser risks that the team feel are important enough to warrant exposure at a particular given time.

What I found most pleasing about the DEFCON door was that it seemed to be a fairly natural extension of the Agile software development practice and was therefore well-adopted by individuals on the project. For instance in a similar way to how we do story estimation a person would read out a ‘risk card’ and then the team would count to three and display with a finger count the the DECON level that they thought the risk had reached. No fingers at all meant that the risk could simply drop off the door altogether – which ought to be a good thing.

Normally every couple of days or so after the standup we would do a quick review of the door. Sometimes, we also did it after a retrospective, because a few things that had been brought up were indeed risks that the team thought were ‘DEFCON appropriate’.

Risks would sometimes traverse up and down through the DEFCONs as the team would attempt to grapple with them, and often risks would be broken up into multiple risks, or instead merged together to form all encompassing ones. No one team member should own the door as it works very well as a collaborative tool where everyone can have input.

Thoughts on effectiveness:

I think often individuals within a team will have very real concerns about some particulars of a project. Personally speaking, one of the wants that I have when I have such concerns is that my concerns will be listened to and registered by the team, and I think the DEFCON door to an extent gives you that.

It also brings the team closer to the risk tracking that would ordinarily be done by project-managers. Although I don’t think it should be a replacement as it best works as a lightweight tool, there’s real value in having team-members contributing to tackling and identifying risks on a day-in, day-out basis.

The DEFCON door also has uses outside the immediate vicinity of the team, such as the ability to show project stakeholders the door and say “these are the major risks that the team feels are present right now”. Often stakeholders not operating within the team will have a want to gauge a collective opinion about how the project is going and the challenges that are being faced. Here the door can play a useful role.

Potential Challenges:

Firstly, it sometimes can be difficult to locate a usable door, especially a nice wooden one. If need be you could use a wall, but then you’d be harming the linguistically pleasing flow of the “DEFCON Door”. It is however, really up to you.

Understanding what the scope is of the door can be at times slightly difficult. For example it can be tempting at times to throw up enterprise-wise risks up on the door that are not directly project-related (e.g. is this architecture appropriate for adoption by the wider organization?). A strategy a colleague of mine came up with is to have a DEFCON corridor, but I fear this may be over-egging the solution. I would endeavor to keep the door simplistic, and if the door identifies risks and questions to be managed elsewhere then that can only be a good thing.

We should also note that this model of risk management is very lightweight and simple, and that there is much more about risks than can easily tracked and measured on the door. Therefore it would seem appropriate to use it to augment a more sophisticated risk management process.

In conclusion, the DEFCON door is a simple tool that aims to bring risks explicitly into the highly visible and participatory realm of an empowered, self-organising Agile team.

The downside of Agile

July 18, 2009 § Leave a Comment

A post I wrote three years ago but never published, I was pissed off back then after a couple of lousy gigs in a row. This was me coming out of the bright eyed Agile love affair mentality a lot consultants have.

Looking around the IT industry at the moment (or rather the microcosms of it that I’ve had exposure to), I’ve begun to develop an unfortunate degree of cynicism about the widespread adoption of Agile.

Currently there are people making claims that Agile has finally passed the chasm; that light has indeed been shone upon the masses. The more cooler of kids will of course have moved on to pioneering something else (maybe Lean), but Agile generally is where it’s all at. If you’re a conservative CIO waiting for something to come out of beta, then the wait with Agile is over.

But – and the more cynical than I would have clearly foreseen this – this widespread adoption is going awry. Namely, that when Agile techniques are ‘leveraged’ in the way that traditional software processes are, the sort of problems that those in position of management thought they’d seen the back of come back to bite, and harder. Problems such as low morale, lack of individual ownership, late delivery and runaway budgets.

Modern Agile methodologies (XP, Scrum) do indeed tend to offer a higher degree of transparency. But transparency itself invites meddling from those able to manipulate the process. Readily availability of metrics such as ‘velocity’ measurements essentially provide the grounds for managers to increase the amount of management. Metrics allows for targets to be set, and for endless tinkering to ensure that the targets are reached. The trust engendered to individuals to do the best job they can is lost when sophisticated charts come into play.

This is at the root my concern. That the previously existing command-and-control, blame-assigning culture of IT organizations simply carries on under a new fashionable look. In fact one might postulate that since Agile facilitates broader intervention at the various stages of software development, then Agile can actually increase the amount of bureaucracy directed at a development team.

And we must ask the question of ‘is this really such a bad thing?’, and am I just blowing this way out of proportion? We surely ought to welcome transparency and the safety nets that Agile practices layer into software development… Aren’t I sounding like the developer who wants everything his own way (perhaps) against the grain of the greater good?

Software is not simple brick laying. You can’t, as much as you might want to, trivialise it to the extent of paying a load of hot-swappable monkeys to write sonnets. Writing software is challengingly complex and has an infinitely diverse problem set. The solution requires innovation and that clever thinkers are given the time and space to follow their best judgment.

I have an inkling that some might feel I’m being somewhat unfair to the understanding of what Agile is really all about. Agile is simply a philosophy after all with axioms such as ‘people over process’ and ‘working software over comprehensive documentation’. The Agile manifesto itself doesn’t directly dictate how a software project should be done.

Well yes this is true. But then this is the difference between what an innovative approach is meant to be used for, and of what the collective wisdom of the masses decide it’s to be used for.

Without a deeper understanding of what a methodology is all about – or the bother to discover what it’s all about – managers will seek to use popularised yet blunt ‘Agile’ techniques to manage more, and then the whole ideal of empowered individuals/teams comes second or third. At worse the adoption of Agile simply becomes a guise for management by checkboxes. Got pairing? Tick. Got ‘stories’ in place? Tick. Got iterations? Tick. Not quite working? Oh well, let’s adjust the amount of pairs in team X, change working hours, assign workers to particular areas…

The lack of the masses understanding what Agile is all about is its downside.

Where Am I?

You are currently viewing the archives for July, 2009 at Pithering About.