Archive for June, 2012

I hate this phrase with a passion. All it means is that you’ve sketched out some ideas as a diagram using something like Mind-Mapping, Rich Picture or a Context Diagram and that’s it. Nothing more, nothing less. Maybe it doesn’t even follow any convention at all. So why not simply say “I’ve produced a basic diagram to illustrate”?


Last year I wrote an article triggered by some wall charts i had seen describing the steps in “agile projects” and “waterfall projects” – both of which looked pretty much the same to me.

Of course “Agile projects”, don’t really exist. The Agile philosophy is based around continually building on and improving a “product”, a piece at a time. Furthermore, this building never stops.

This is, of course, at odds with the traditional “Project” notion.

You can go further and get deep and meaningful about it and say that the whole “project” mindset negates the agile ideals, and in fact, it is the project concept itself that is the reason for delivery failures. The notion that we do something that conveniently ‘starts’ and ‘finishes’ (the basis of a waterfall project) might be administratively convenient, but is a bit of a nonsense if we are dealing with something that is going to be with us for a long time. As most IT systems are.

I have been attending some training courses recently. One of the most enjoyable aspects of a course is always meeting the other delegates and swapping ideas. Traditionally, you would chat about the subject matter and generally put the world to rights over a lunch consisting of plates of those small triangular sandwiches that have done so much make the world a happier place. Even if you ate in surroundings reminiscent of a hospital accident and emergency waiting area it was always fun.

In these cash-strapped times, the sandwiches have long since gone. You’re lucky to even get those plain cookie type biscuits that nobody likes or eats – unless they are on a training course. Socialising has given way to grabbing something from paid for vending machines even less likely to dispense your chosen item than those mechanical grab machines in fairgrounds.

But last week, we still built up quite a rapport and had some interesting conversations.

Two of the delegates were in the process of introducing agile into their companies and asked for advice from the rest of us. There were some very VERY interesting insights about people’s experiences. This sort of thing is almost worth the cost of the course in itself and you certainly won’t get it from any book.

I was the fourth person in to give an opinion, and explained my view:

Agile is a better way of running your projects. It generally reflects what people know deep down to be the right things, but that have somehow been suppressed or forgotten. But it comes with a proviso. A big proviso.

That proviso is that the people on an agile project need to know what they are doing.

Knowing what they are doing doesn’t mean technically competent or even being able to apply technical skills. We can assume the team have all of that which s why they are there. It goes deeper. It means understanding the applications and technology from a business perspective and understanding the business context of the project and where it s going so we can shape the requirements. (Apologies if that sounds a bit high and mighty…).

If we have that, then we have what the agile books refer to as “a good team”.

We can then apply agile to it and hopefully make “a good team great”.

The “applications and technology from a business perspective” bit is key. Most projects nowadays involve existing, legacy, systems. This isn’t the 1970s.These applications will have business rules, logic and behaviour embedded in them. Often this is not properly understood, and furthermore it is not discoverable to the users. You need developers to help understand it by looking at the code. But if you have developers that don’t want to work on anything pre-existing, and feel aggrieved if they can’t work just on the glamorous “new” stuff (and I’ve encountered plenty of those, I can tell you) you will have a problem. This mindset certainly isn’t that of a good team.

To be fair, I’ve also encountered business analysts that are reluctant to look into pre-existing IT systems too closely. They seem to think this will in some way contaminate the finished solution. For heavens sake. They exist. Therefore you have to look at them. If people were using ringbinders and rolodex to manage their process you would look at these, so why get aggitated about pre-existing IT? There may well be much to learn from it.

Examining what you have and having a deep and meaningful understanding of it, can shape and influence the new requirements. It isn’t necessarily a case of even understanding the requirements at this stage: Like cooking, it is more a case of understanding the ingredients and what they are capable of first. Then, we can focus on the recipe.

Time for some biscuits.

Project plans are, it seems to me, like weather forecasts: well intentioned, produced using the best available information, worth looking at certainly, but frequently wrong.

This doesn’t mean we shouldn’t have them, necessarily. Nobody suggests not having weather forecasts just because they are often wrong, and you could say the same about project plans. There are certainly situations where project plans don’t add any value and I don’t see why they are there, frankly. But I can accept that they sometimes have a part to play – if only to provide a guide to the general direction of travel. That is fine by me.

Ultimately it is people’s perception that is the problem. Plans and forecasts don’t seem to be enough nowadays. People expect absolute certainty and predictability in everything, even if we know in our heart-of-hearts this is an unachievable nonsense. Plans and forecasts need to be treated as such. With a degree of caution: Points of reference are sensible, but whole-hearted reliance and an expectation of quasi-scientific perfection is just silly.

We should know better by now.

The word “Wrong” also needs examination. People often seem to assume that something “wrong” can always be put “right”. It is often further implied that the wrong could have been avoided entirely if only we had done something differently: If only we had taken some (inevitably elusive) action. If only we had gone that little bit further to make the plan perfect. Damn. No matter – next time it will be better and we will improve, right?

This is just hindsight playing tricks, I’m afraid. A wonderful thing, but also depressing and destructive if you don’t keep it in check.

The most dangerous thing is that it perpetuates the myth – and thats what it is – that the “perfect” project plan is achievable. Like the perfect weather forecast…