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.

« »