Agile Software Development is such an encompassing and loosely-defined term that I’m not going to even try to define it, except to say that most programmers are using Agile techniques even if they’re unaware of it, or unwilling to admit it. To keep this post short I’ll simply talk a bit about a few of the techniques that I’ve experienced and what was worthwhile and what arguably wasn’t.
Now, your eyes have probably been drawn to the accompanying image here of the whiteboard with the post-it note explosion. There’s probably some formal name for these things, but I’ll just call it “The Board” because that has a certain gravitas to it. So what is actually going on here?? Well, what we do is split The Board into 3 sections left to right: To Do, In Progress and Complete. Each post-it note or card represents a task and we can move them about like a really depressing game of Frogger.
On the card we put the name or description of the task and a time estimate for completion. But obviously before this we need to have a fairly big piece of development work that we can then chunk into different tasks. To give some reference, the times are usually in days and ranged from ½ day to around 4-5 days. If you come up with a time outwith that range then perhaps you need to re-evaluate the way you’re breaking up tasks.
When you’ve finished creating your tasks and your desk is sufficiently covered in post-its, then it’s time to stick them all on The Board in the leftmost section: To Do. Now shout over some developers and start talking about who wants which task and… well, would you look at that, you’re unknowingly participating in a stand-up meeting (!).
These meetings are sometimes referred to as Scrums (with ScrumMaster somehow being an actual profession and job-title for some people) and I find them the most valuable and worthwhile part of all this. The first stand-up will be assigning tasks and going on from there you should have a daily meeting (usually in the morning) to discuss progress and update the board.
So for example, the morning of the first day I might say that I’ll take Task B: “adding Marquee and Blink tags to the issue tracker to improve the UI”. So I’ll move that card to In Progress on The Board, and the other developers take tasks too. At the next morning’s meeting everyone should huddle around The Board and talk about their progress with their assigned task, moving anything to complete if necessary and picking up more tasks. Perhaps the next morning at the meeting it becomes clear that I’m still on Task B and I’m really struggling with it. Someone who is a bit more knowledgeable with these particular tags and knows them <marquee> inside <blink> and </blink> out </marquee>, so we say that he will Pair with me until the task is done. Then the next morning we talk about our progress again and update the board, and so on… until everything is complete.
Essentially this is all just a way to break down a project into tasks and having regular meetings to talk about problems, it’s nothing difficult even if you give it a formal name. It’s very easy to see the progress for a project from a glance and can help people see the big picture or conversely, when everything’s a bit overwhelming, it keeps everything in manageable chunks. As I said, my favourite part is the daily stand-ups, as it can keep the managers and the developers informed of what the actual progress is so there are no false expectations. Also they can flag problems up really quickly if a developer needs help or is perhaps going about things the wrong way. Often they turned into short brainstorming sessions about how best to tackle a problem, really useful.
Obviously there can be downsides and it can feel a bit bureaucratic; you may feel you’re wasting time making all these little cards in the first place, and keeping the board up to date can become a chore. Perhaps some people think having meetings every day are a waste of time and they’d rather just “get on with it”. To that I’d probably say that I’ve found it to be much more efficient for the reasons I’ve already mentioned and that, granted, it maybe doesn’t suit solo-developer projects. However with some common-sense and the right project I think doing something like this would be worthwhile.