Most developers are now familiar with the basics of Agile development, including the idea of a daily scrum where the team can share their progress, ideas and problems. But no development method works perfectly for everyone, so is there an alternative to the scrum?

What’s wrong with the scrum?

First of all, we need to identify what might be wrong with the scrum. The number one issue I’ve heard mentioned is engagement – not everyone excels at verbal communication, particularly in a group and when they’re put under time pressure, which is all part of the scrum.

Another issue is the timing – scrum’s are typically held in the morning. This works great as a way of preparing everyone for the day ahead, but there is benefit in capturing information during the day, while problems and solutions are fresh in the mind. In some cases there may also be geographical (and time-zone) reasons why the scrum doesn’t work. And of course, if someone is away on holiday or ill, they’ll miss the information shared in the scrum.

Then of course there’s the length of the scrum – each person must necessarily keep their update brief, but that limits the amount of information they can communicate. Break-out meetings go some way to addressing this but it’s sometimes difficult to get everyone together at the right times and to know who to involve in each one, without the whole day descending into an 8 hour meeting-fest. In a similar vein, the short scrum keeps it focused on the tasks at hand, but doesn’t leave time to chat about that cool game you’ve discovered or what you’re doing at the weekend – stuff that’s not strictly work related, but can be beneficial to team interaction and morale.

Scope can also be a problem. In a large team it’s common to have separate scrums which means you need a way to communicate information between scrums. There’s the “scrum of scrums” approach but that’s very hierarchical and doesn’t always put the right people in touch. And what’s to say that people outside the team don’t also have an interest in the daily progress?

Lastly, there’s the issue of how to communicate technical and visual information. The details of algorithms and techniques can be hard to communicate verbally, and showing visuals during the scrum may not be possible depending on the team size, scrum location and even whether the game build is stable at the time of the scrum.

What solutions exist?

There are already documented ways to resolve these issues. Break-out meetings are part of the scrum development process, as are regular sprint reviews. But, as mentioned earlier, break-out meetings still have their drawbacks and sprint reviews are still limited in scope and occur much less frequently than the daily scrum. Clearly there’s still room for improvement.

What else can we do?

One area that I’ve not seen discussed much in relation to agile development is that of social media. Agile is big news, and social media is big news, but connecting the two seems to be lagging behind.

Probably the most common usage of a social media technology in development is instant messaging. For years now many developers have been using IM to aid development, but IM is very much a one-to-one communication tool rather than a broadcast, and in terms of social media, IM is really on the fringes.

So what about more recent developments, such as blogs, microblogs and photo/video sharing sites? Well, for the last few years I’ve been writing a daily blog along with every other member of my team. The blog has a similar format to the scrum, I’ll talk about what I’ve been working on, what went right or wrong, and what my plans are. The big difference from the scrum is that I can spend as long as I like on the blog, and I can write it when I want. I usually keep the blog open in the background all day and jot down notes as I think of them. I’ll include links to interesting articles, screenshots of work in progress, a rant about some API I’m struggling with, or sometimes just go off at a tangent about hobbies that are only tenuously related to work, if at all.

I find this form of communication highly beneficial. I don’t expect everyone to read all my posts, and I don’t manage to read all of of everyone else’s posts – but I’ll skim through and pick out what looks like the important and interesting bits of information. I will also read blog posts from other teams, and receive comments on my own blog from people across the company, often with useful links and other information that I’d otherwise have missed.

As a manager I find it useful to be able to keep tabs on what everyone is working on across the whole team and to gauge morale. On occasion it has been useful to go back and look at blog posts over a period to remember how long implementing a feature took and what problems were encountered – information it’s hard to get from commit logs, documentation and so on.

I’ve also found that people feel much more able to vent on a blog than face-to-face or in a meeting – this can be useful for picking up problems before they become serious and leads to improved morale and productivity.

For all these reasons, I feel that daily blogging has a significant benefit. For reasons of confidentially the blog will typically need to be private to your company, but setting up a WordPress server is straightforward enough. Despite the provocative blog title I don’t actually believe that it’s an alternative to a daily scrum, but I do think the two things compliment each other nicely.

Going forward, I’m really interested in experimenting with microblogging (StatusNet is a good alternative to Twitter if you want to run a company-local server). Twitter started its life as an internal brain-storming tool for a company called Odeo, so it’s strange that microblogging within agile hasn’t had more coverage. Yammer seems like another potential solution – we experimented with it a few years ago but back then it seemed to be just a group chat system which didn’t really work for us.

In the end, any tool that promotes communication within your business has to be a good thing and I’m excited to see where this field of knowledge sharing leads in the next few years.