Methodologies Suck

Creating software in the corporate environment is a complex business and complexity is a wonderful breeding ground for risk. There are two types of risk that need to be dealt with: acquired risk and inherent risk.

Acquired risk will be the subject of a later post. It’s the quid pro quo of software development - choose the bleeding edge, expand your scope, try something experimental, and you’ll increase your risk. It’s the risk you choose or have foisted on you.

Inherent risk is the risk that you get on every project. It’s the stuff of communication, environments, time, skills, and budgets. The level of risk will change but the sources are the same old same old. It’s where experience pays off.

In theory enterprise delivery teams should have stopped talking about inherent risks years ago. Take communication. After a few disasters caused by half the project members not knowing what they were doing, mitigating actions would be put in place on all projects. Regular meetings, bulletins, an intranet site, show and tell, a project WIKI, team outings to the pub. Eventually these would reduce the communication risk down to very manageable levels.

Except we do still find projects not communicating. A lot.

I don’t know why this is. Human nature, a lack of competence, bad management, wrong people in the wrong role? Perhaps a little of all of the above.

But into this gap step the methodologists.

Like so many other terms ‘methodology’ has become a kind of banner that managers feel the need to carry before them in the mistaken belief that it guarantees all will be well. Like garlic around the neck for vampire protection. Recruitment is carried out these days by matching methodology names from requirement to resumes. Book writers and lecturers make a small fortune from peddling methodologies, or updating methodologies to make them sound more ‘agile’ or ‘service oriented’.

And this is where the sucking starts:

My first issue is that we’re actually talking about ‘methods’ not ‘methodologies’. If you have a commonly occurring problem, like effective communication, you need a method to address it. For another problem you need another method. For the same problem in two different circumstances you need two different methods. This, I believe, is called common sense.

If I have a small team that allows everybody to sit together I don’t want them to communicate via email bulletins. I want them to get up from their chairs and talk to each other. I want them to huddle around a whiteboard, work things through, capture the agreed way forward, and move on.

A method that forces me to create a regular email newsletter wastes valuable delivery time, and a method that tells me I need effective communication insults my intelligence. And there’s the issue - too much detail and you can end up doing irrelevant things, too little and you may as well just say ‘do a good job and make your customers happy’.

That’s not to say that what we call a methodology, or an approach, is all bad. The logical ordering of things is useful. Prince II says I must create a Project Brief then a Project Initiation Document before I move to High Level Design. For naming conventions sake and to remind us that we should say what a project is all about (the brief), then make a plan (the PID) before we start paying for expensive resources is a good thing.

But if we see simply having a PID as the garlic that will protect us from the vampire of planning disaster, we’re wrong. The plan will at best be an educated guess. Useful, yes, but accurate, no. Not until requirements have been gathered and designs done will the plan be even close to accurate. And not that accurate even then.

And proponents of agile needn’t feel too smug either. Many’s the time I’ve seen iterations start with a list items to be addressed only to be found chucking lots of them into the next iteration because planning was too optimistic.

The answer to inherent delivery risk isn’t to look towards methodologies to save you; it’s to think for yourself, make informed decisions and apply the most appropriate method available (or create a new one if that’s what needed).

The other issue I have with methodologies is that, even if you were to accept that they were all pure goodness with implacable vampire killing powers, they are nearly always implemented half-heatedly, partially, ignoring elements that are seen as difficult and managed by the dull of mind to wreak their petty power over others.

I’m not arguing for chaos, or a complete lack of control. I’m a big fan of proper controls. It is so infuriating to work on a project without a clear purpose, or a properly thought through business case, or watery requirements, or to be writing the code before the budget is agreed. Project gates are good. If it was my money a project was spending, I’d want to know exactly where it was all going, and that it was being spent wisely. I’d want confidence that the team understood what I was asking for and that the design was going to deliver it.

But what I would really want is competence. I’d want people to think, use their experience, the experience of others and show me a plan of action. If that doesn’t work then I’d want them to try something else, and so on until it does work.

That kind of talk scares the shit out of the methodology brigade because now you’ve got rampant reactive hackers working it out as they go. But ain’t that just life? I’m not saying knee-jerk your way from panic to panic, but at each stage you know only what you know, and can only do the best you can with that. It sounds uncoordinated but it isn’t. If you use what you have well, and have enough experience around to bounce ideas off, you’ll most likely be fine. And most likely are the best odds you’ll ever get.

OK, now proponents of agile can start to feel a little smug. Agile gives permission not only to code early, but to roll with the inherent punches that project delivery is bound to throw at you, as long as it is all done with full transparency to the business. With sensible gates protecting where the investment is going, and as long as the basic plan and essential requirements are captured at an appropriate stage (i.e. not skipped altogether), it’s a very workable model. But it’s not a methodology.