[In this reprinted #altdevblogaday-opinion piece, Blitz Games' technical manager Tom Gaulton examines the problems of Agile development's scrum, and suggests that social media can help provide some solutions.]
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 – scrums 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 that'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.
[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]
"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."
I have also experienced this and i have found microblogging or even blogging VERY helpful! We were using a specific management tool and i found this feature as one of the most important! It kept the entire team up to date! Provided P2P assistance, and kept the team together in a way they are more comfortable and familiar with!
Hmm, it would appear to me that you're solving a symptom. If there isn't enough communication happening, why? Why are people afraid to speak up? What can you do to generate a culture of communication? What can be done to teach communication skills if they are lacking?
You've come up with an elegant hack; but, I wouldn't propose it as a solution to the "problems" of scrum or some such thing.
A lot of what you say doesn't fit in the stand up meeting DOESN'T and shouldn't be in the stand up meeting. You're allowed to have impromptu, ad-hoc additional meetings for those discussions. That's not a problem. Scrum is a toolset. It's your responsibility and the responsibility of your team to implement it and build on it in an intelligent fashion.
Some of the 'problems with scrum' outlined here read much more like problems getting people organized in game development culture. Recently, we've heard more about a lack of production management expertise in the industry in a general sense; perhaps this provides another example of that need. If scrum (or any agile development philosophy) allows for change to fit the team, it seems some of these problems can be fairly easily mitigated with some introspection, leadership and production support. Taking the initiative looks like a good move.
People may have some problems scrumming, but there's an even larger potential problem with the average programmer's ability to write clearly.
I'm not sure I agree in any way that blogging has any value in this. I'd have to see how it was set up, who would read it, and how that actually got the information where it needed to go instantaneously.
Very good points. Kudos for exploring ways to help teams improve these practices. I'd like to add a few points based on my observation as a game dev Scrum coach for the past seven years.
Scrum teams are meant to take ownership of their practices and change what ever they need to within a sprint to increase their productivity. However, some of these changes are done for the wrong reason. They are made in response to the discomfort that Scrum creates through increased transparency, team commitment and even "a working game over design documentation" philosophy. I frequently see studios claiming to do Scrum, but often just wallpapering a traditional big-plan-up-front, command-and-control process and calling it agile.
Take the daily scrum. The daily scrum is often misinterpreted as simply a task-reporting exercise. Task reporting is part of it, but its main goal is to be for a team to commit daily, as a group of peers, to their shared goal. This is alien in many studio cultures. Communicating verbally to other disciplines can be uncomfortable at first. This discomfort can lead to teams abandoning the practice and using an electronic replacement.
From my observations, how a team behaves when together, whether in a daily scrum or a sprint planning meeting, is a litmus to their health and productivity as a team. Great teams enjoy working together, yet don't avoid conflict. They almost speak their own language at times. This is the goal, not standing in a circle answering 3 questions. The daily scrum for a healthy team is a chaotic, noisy affair often lasting no more than 5 minutes. Less effective teams often have boring 15 minute time-boxed meetings where no one raises anything of importance.
Changes to practices, such as the daily scrum, need to be made in light of the principles behind them. Some of those are:
- The sprint practices are owned by the team, not imposed from the outside.
- Sprint commitments are made by the team, as a team. Not as a set of individual commitments.
- The team must continually explore ways to improve their performance.
- Adding value to the game is primary. Task tracking is important, but secondary.
If a team wants to use IM to improve, that's fine. The ScrumMaster should help guide them through changes by making sure they follow these principles.
Tom this is an excellent post, I identified many of this points as our company`s problems too.
Everyone should pay attention to their problems and try innovative solutions, and this is a typical example, congratulations and thank you for the enlightenment.
The problems is with the culture, and with a lack of communication, not with the scrum framework. My team just moved our standup to the afternoon. It's working out great. Likewise, catching up with people shouldn't happen at daily scrum, but why aren't people doing it some other time during their 8-12 hours at work? When we need to write out diagrams/algorithms, we table it until right after the 3 questions, then PO and SM leave if it's technical, and we get into a discussion. Blogging/IM may help communication, but it's by no means a swap-in for scrum.
"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."
I have also experienced this and i have found microblogging or even blogging VERY helpful! We were using a specific management tool and i found this feature as one of the most important! It kept the entire team up to date! Provided P2P assistance, and kept the team together in a way they are more comfortable and familiar with!
You've come up with an elegant hack; but, I wouldn't propose it as a solution to the "problems" of scrum or some such thing.
A lot of what you say doesn't fit in the stand up meeting DOESN'T and shouldn't be in the stand up meeting. You're allowed to have impromptu, ad-hoc additional meetings for those discussions. That's not a problem. Scrum is a toolset. It's your responsibility and the responsibility of your team to implement it and build on it in an intelligent fashion.
I'm not sure I agree in any way that blogging has any value in this. I'd have to see how it was set up, who would read it, and how that actually got the information where it needed to go instantaneously.
Very good points. Kudos for exploring ways to help teams improve these practices. I'd like to add a few points based on my observation as a game dev Scrum coach for the past seven years.
Scrum teams are meant to take ownership of their practices and change what ever they need to within a sprint to increase their productivity. However, some of these changes are done for the wrong reason. They are made in response to the discomfort that Scrum creates through increased transparency, team commitment and even "a working game over design documentation" philosophy. I frequently see studios claiming to do Scrum, but often just wallpapering a traditional big-plan-up-front, command-and-control process and calling it agile.
Take the daily scrum. The daily scrum is often misinterpreted as simply a task-reporting exercise. Task reporting is part of it, but its main goal is to be for a team to commit daily, as a group of peers, to their shared goal. This is alien in many studio cultures. Communicating verbally to other disciplines can be uncomfortable at first. This discomfort can lead to teams abandoning the practice and using an electronic replacement.
From my observations, how a team behaves when together, whether in a daily scrum or a sprint planning meeting, is a litmus to their health and productivity as a team. Great teams enjoy working together, yet don't avoid conflict. They almost speak their own language at times. This is the goal, not standing in a circle answering 3 questions. The daily scrum for a healthy team is a chaotic, noisy affair often lasting no more than 5 minutes. Less effective teams often have boring 15 minute time-boxed meetings where no one raises anything of importance.
Changes to practices, such as the daily scrum, need to be made in light of the principles behind them. Some of those are:
- The sprint practices are owned by the team, not imposed from the outside.
- Sprint commitments are made by the team, as a team. Not as a set of individual commitments.
- The team must continually explore ways to improve their performance.
- Adding value to the game is primary. Task tracking is important, but secondary.
If a team wants to use IM to improve, that's fine. The ScrumMaster should help guide them through changes by making sure they follow these principles.
I wrote more about the daily scrum here:
http://blog.agilegamedevelopment.com/2010/11/effective-daily-stand-up-pointers.h
tml
Everyone should pay attention to their problems and try innovative solutions, and this is a typical example, congratulations and thank you for the enlightenment.