Category Archives: A

A is for… Agile

First, let’s be clear – Agile is a software development methodology, it’s not a ‘save the world/software delivery panacea’, and in a lot of ways it’s really a collective re-badging of stuff that’s been around for ages.

The Good Guys will recognise a lot of this before, but others will cling to it thinking it will somehow magically make software development faster, better, cheaper, etc. There are plenty of books on the subject and most will tell you it DOESN’T solve everything, it’s NOT necessarily faster, or cheaper, and there are certain projects or situations you should NOT use it.

Agile brings with it lots of new exciting terminology and lots of new fabby techniques, or does it? Let’s compare Agile with DSDM and XP, or, if you’re old enough, RAD or JAD (whatever happened to that), and let’s compare it’s new fancy buzzwords with, well, errr, plain English really.

  • Stories: A narrative describing something to be delivered. The old skool will recognise these as ‘Requirements’ (Epics = High level requirements).
  • Sprint: A defined period of time where everyone works hard with the objective of delivering something. XP calls them Iterations, DSDM called them Timeboxes in the olden days
  • Scrum: When the team all gets together to discuss what to do. Sound familiar? Yes, a ‘Meeting’
  • Standup: No, not a comedian, but by now, you are may be beginning to wonder. This is where the team all gets together quickly to discuss what to do, without sitting down. You will undoubtedly recognise this in the real world as a ‘Short Meeting’
  • Refactoring: Restructuring or changing existing code to make it work differently. Yeah right, you may be more familiar with the terms ‘Fixing’ or ‘Debugging’

We could go down to the level of discussing ‘dunces hats’, and ‘visible build indicators’, but you’re probably getting enough of an idea already. It’s all been done before and those in the know have been doing it for years without the daft names. Suffice to say, if you’ve mobilised a teamlet, who’ve assigned a story-captain and they’re now swarming on a work item to burn down a story, you’re already too far gone.

The bottom line is that Agile is like any other methodology du-jour; it’s right for some things and not for others, it has useful bits and irrelevant/pointless bits and it has people who know about it and understand it and people who think they know about it but don’t.

Watch out for the latter; the methodology evangelists. These are the people who will say things like, ‘That’s not the Agile way’, ‘We should have a stand-up to resolve this’, ‘we must use xyz software to track with’ (it’ll be a beta release of a freeware hack that only runs on an obscure version of Linux, or a Commodore 64 and requires you to be a seventh level mage to sign in), and generally strut about looking like they know it all.

Agile works best if you can isolate everything from the real world; the project team, their development kit, the users, the testers, the delivered system, all common sense. Strangely, us real world guys know it’s just not as simple as that…

Anyhoo, like all methodologies, it’s only partly about the methodology, it mainly comes down to the people executing them; if you have enought good people, they will stand a good chance of delivering. However, if you don’t, then the combination of that coupled with the use of a methodology new to those people , no matter how new and sexy it is, or wacky it sounds, will likely result in chaos.

A is for… Appraisal

At some point in the working life of every manager, you will be asked to make judgement on your subordinates. Luckily they will be usually given some form of performance review system to give structure to your meandering thoughts. The system will typically be based on objectives, competencies, performance against ‘vision’, that sort of thing. The simplest thing to do is to ignore all of this and to concentrate on some fundamentals rules. Start by answering these questions:

  • Who in your team makes you look good without being a direct threat to your position?
  • Who in the team would it cause more hassle to lose than retain?
  • Who would you happily flush down the toilet?

Got the answers? Good. Now the next stage. Recite the mantra ‘Reward to retain, ignore to eliminate’. Pay most attention and reward to those you want to keep, be polite and courteous to those you want to flush. Its for the good of everyone, you, the company, even the individuals themselves. No one wants to work for a boss that thinks they are a muppet. You’re doing them a favour, putting them out of their misery.

A is for… Avoidance of Failure

The best way to avoid a project management disaster is not to get involved in the project at all. Learn to see the Turkeys coming and duck them with vigour. Do all you can to ensure that those projects are assigned to your less capable friends (see the test under Arses). This is not as unfair as it sounds. Given that they probably can’t deliver any project, giving them the undeliverable to deliver at least gives them a viable excuse for failure.

Here’s a few tips for spotting the ones to avoid:

  • If the salesman can’t immediately answer the question “What exactly did you sell?” ( see the entry under it ).
  • If the technical architect says ‘no, no, we don’t need a proof of concept, it’ll all work, I’ve read a whitepaper’
  • If you’re general manager says ‘we’re going to deliver this one from India’.
  • If you get introduced to the team with the words ‘Yes, they’ve been doing mainly mainframe work but they are going on re-training next week’

A is for… Arses

This is probably the most galling fact of all. You work in I.T. You have a right to expect that you share your working life with well-educated, well-trained, competent individuals. This is why you feel alone. This is why you get frustrated. What will free you from this hell is if you just accept that probably as many as 85% of all people working in IT aren’t very good at it.


Project Managers, great aren't they?
Arses

In fact, brace yourself, Project Management is probably the most guilty discipline of all. Think about it. How many people have you met he have stumbled into Project Management solely because they weren’t actually any good at anything else and specifically because the role of Project Administrator is very often confused with Project Manager. Collection of timesheets does not a Project Manager make.

Try this test. Give one of your so-called Project Management colleagues this book and if they say things like “That’s terrible” or “Very funny, lucky it’s not actually like that” make a mental label of “Arse” for them in your head.