Opinion: Communication Is Key

[In this reprinted #altdevblogaday-opinion piece, Blitz Game Studios' technical manager Lee Winder shares his experiences trying different ways to improve communication with his team during the game development process.] Successful communication is one of the most important aspects of a well functioning and productive team. Without good communication between peers, managers, publishers, and anyone else involved in the game development process, a team will not perform at it's best. If developers do not feel confident in the reasons behind their work, if they don't fully understand how their work will fit into the project as a whole or indeed when it will be required, the team will produce lower quality work with last minute changes and requirements fostering an atmosphere of distrust and crunch. But communication is one of the most difficult things to get right but so costly when it's done wrong. The following are methods I've used over the years to try and improve communication within the team. I'd be very interested to hear other ways people have tried too! Team Wiki Having an open Wiki that people can contribute information and notes is a good idea for documentation and persistent information. It is not a good tool for perishable short term information. Documentation on team processes (getting the latest build, creating submissions, setting up PC's etc.) is usually the kind of information that finds a home on a wiki, and while it's useful, it's not something that affects the team on a daily basis. And as it requires people to physically search for the information in the long term people don't bother looking for new information on a regular basis. As a result, the Wiki is useful but doesn't actually improve the day to day communication on a team. Blogs  We have a team blog that people update about 2 or 3 times a week, usually discussing their recent work, posting up screenshots or letting people know the state of the project. It's a nice simple way to push information to the team, though it does require everyone to contribute to the blog to get good cross team communication going. Discussions can take on a life of their own, which is actually a good way to gauge buy in into a project but can't be used to judge the success of the process. But you'd be amazed how many people don't have any kind of RSS feed reader set up… Micro-blogging Internal mico-blogging tools like Yammer or Status.net allow people to quickly thrown up what they're working on, problems encountered or general team information. The best thing about micro-blogging is it's push communication style with people's updates being automatically feed to clients, which people can update as much as they want (I usually recommended at least twice a day). But so far I've had very little success with micro-blogging tools in a team environment. Not because the idea was bad (when it worked it worked well), but I've yet to find a service where the official client is anywhere near usable and able to filter out the information people don't want to read. Without a good way to filter and push information where you want it (like all the best third party Twitter tools do), it either becomes an information overload or a sea of noise, neither of which improves communication. Wall Displays Walls are valuable real estate, especially in an Open Plan office, and I've rarely seen them used to their full potential. But highly visible walls in the middle of a team area are one of the best ways to communicate information across a team. As an example, on my current project we have the entire timeline of the project (it's only a short one) with dates/deliverables clearly indicated, a 'where we are right now' marker and a description – feature by feature – of what is required for a given milestone. Next to that, we have our sprint wall, which is our most 'live' wall display. But position is key, and in our case, the sprint wall's impact on the team is reduced due to it's rather awkward position between a big TV, a constantly spinning fan, and quite a lot of server machines. But I did say wall space is valuable real estate, and it's always hard to find a compromise between distance from team and accessibility. Morning Meetings Morning meetings are one of the best ways to push information across a team, but I've found that you need to follow a few rules to make them really valuable.

Milestone Reviews I love the concept of a milestone review. Everyone playing the game, lively discussions about what went right, what went wrong, and what we can do better next time. But it's easy for these to be less than stellar if not approached in the right way. If these reviews are not focused, maybe even as structured as a schedule or points to cover, people may start to feel unsure as to what they can comment on or what exactly they should be doing. You've also got to make sure that people feel comfortable both giving and taking criticism and manage the situations when that goes pear shape (and sometimes it will). I've found that when done right, when people contribute to discussions and when people can (importantly) see change as a result of these reviews, the quality of information coming out of them is invaluable. It also has the added bonus of making people feel like they are making a difference to the team and allowing their thoughts to be heard. Sprint Planning The days of managers sitting in a room building up a schedule and dishing it out to the developers is (almost) long gone. And there's good reason for it. Getting a group of developers (again with the morning meetings it needs to be small and focused) to discuss, schedule and plan the work ahead significantly improves the knowledge people have of what is happening across the team. Again, if people feel that have a say in how work will be implemented, how it will be assigned and when it'll be done by is vital to spreading information about the project and the work being done. So those are a couple of methods I've used to try and improve communication and information across the team. I'm sure there are plenty more (and I've tried a few which have been colossal failures) so what methods have you used and how well did they work out? [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. Article image by deathtogutenberg. Used under license..]