Tag Archives: Methodologies

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.

M is for… Methodologies

Methodologies are wonderful things, or so the people who invented them, or offer training or consultancy in them, would have you believe. Some have cool-sounding names: RAD, JAD, some try to sound important: PRINCE, or obscure: SDSM, SSADM, ITSL, some are just clubs: APM. They’re all basically the same concept, take a real world discipline and put some rules in place, some fancy terminology or acronyms and maybe thow in a few standard forms and a £45 manual or two.

Yes, they come under many guises, Project Management methodologies, Development methodologies, Quality Management methodologies, etc. They all have one thing in common, the people who invented them and the organisations that are touting them are now very rich.

The other strange phenomenon that exists in this area is that just about every organisation thinks they can do it better. So, when you hear things like ‘Yes, our Product Management methodology is based on Prince II but it’s much more practical’, the warning bells should be starting to ring. After all, why would people plough millions, nay many millions of pounds in developing and spreading the word about something just for other people to discard bits of it because they don’t like it?

Rule #1: Don’t try to use a big methodology to deliver a small project. Use the lesser known Common Sense methodology instead, it’s cheaper and much less complicated. If you’re a Good-Guy, you’re already trained in it!

Rule #2: If you don’t have to use it and it does not benefit you to use it, don’t use it. There’s little benefit in telling people you ran a fully SSADM compliant project, using PRINCE2, which failed.