Communicating is the hardest thing you’ll do.
My name is Patrik and I’m the producer at Arrowhead, a position which I took just 5 months ago. Before I was a producer I worked as the designer and, during the later stages of development, as team leader on Helldivers.
Recently I was asked about the impact communication has on games: is good team communication essential for playing co-op games? My answer was less of a “yes” and more of a “hell yes” with a growing realization of just how much communication really does matter.
In any team-based game the quality and amount of information you provide your teammates with is critical to success. This prompted me to think about how we have used communication at work and to start defining what the issues were and what we could do to solve them.
The blogpost that follows is based off of my personal experiences, and I’m sure there is a big bunch of research on communication issues that you could look into for more in-depth reading.
1. Team (un)Scalability
Someone else has probably made this observation already, but I have found that as soon as a team reaches the size of more than 5 people the work efficiency lowers significantly. Adding another person is not equivalent to adding 100% more work on the game, instead it turns out to be more like 70% and in some cases even less.
As soon as you reach 7-8 people you start to need a proper team leader, someone that takes time out of their day to make sure that everyone is up to date and has the latest information.
When you reach a team of 15+ people, this quickly starts to resemble a full time job, and I do recommend you to find a dedicated team leader at this point. Someone who is not expected to produce anything for the actual game (though if they happen to contribute a bit, that can always be nice).
2. Bastumöten (decisions made in ad hoc meetings)
This is a term used in Sweden (eng. sauna meeting) and I have yet to find a better English equivalent. Essentially these meetings are what might occur when a few of the devs go out for a beer, hang around late at the office, or just generally sit around discussing the game. They find some feature that would be really nice, or revise a feature already in the game, and somehow they end up at a decision to change something.
The problem here is often not that the decision is bad, many of the best ideas come from a more relaxed informal environment, but rather that the change never reaches the entire team. It is essential that whatever you decide in meetings like these gets noted down, and that they are distributed to the whole team.
A great solution is to have a mailing list that incorporates your entire team – and make sure that it is used! However, don’t over-saturate your mail with information that not everyone needs to know, people will get tired of reading the “spam” and miss important information.
3. I thought you told him?
Plenty of times I have found people to simply not be up to date on what’s being worked on. It’s very easy to just forget that someone was sick the day that a decision was made, or that they were in a meeting and no one ever told them. Mailing out these small changes, however, could easily clutter up an inbox if they are mailed out every time you start working on something new.
A common solution is to use some form of Agile or Kanban workflow, where tasks are clearly defined and everything is up on a board for all to see. Yet in my experience people seldom have any idea what’s going on anyway since they tend to dig into their work and not look at boring organizational stuff.
I have found that morning meetings is the best way to go. Just gather quickly every morning and step through what people are going to spend their day on before getting started. Repeat this process daily and it becomes second nature just continuously update your team on what’s being worked on.
4. And on the topic of morning meetings…
I love these, others hate them. They have some downsides, like enforcing an interruption of work if they aren’t the absolute first thing in the morning, they can get tedious, and most of all they require that people are on time.
They neatly solve a lot of problems though. Like making sure that everyone has the latest information, an idea of what’s being worked on and can make sure that any blockers are well known. My preferred way of doing morning meetings is to just stand(!) in a circle, quickly present what you are working on, if anything is blocking your work, and anything else you might need to inform the team of (change in design, change in direction, that you have a dentist appointment and will be absent for a while, etc.).
A word of warning: make damned sure that the morning meetings do not become drawn out affairs! You are going to do them every day and people lose interest fast. Also it is important to make sure that the morning meetings do not become a point of review, the purpose is not for the management to check if you were slacking off the day before but to facilitate good information flow. As your team grows I would recommend to have the morning meetings in smaller groups, and do a larger morning meeting where only one from each team talks.
5. “Someone” please fix this
This is a lesson I learned early on when I did reception duties for new students during my time at the University. If you ask “someone” to do something, no one will do it. “Can someone fix this asset?”, “Can someone fix this bug?”, requests are often ignored because everyone thinks someone else will take care of it.
I have found it immensely helpful to make sure that a name is attached to everything that needs to get done. This goes all the way from sprint planning to small issues found here and there. As long as people know that they personally do not need to do it, but they are responsible to make sure it gets done. It’s fine if they ask a co-worker to handle it instead, but this simple responsibility attachment is critical to make sure that the task reaches completion.
For sprint tasks, I make sure that each task is assigned to a team. It is then up to that team collectively, and primarily that teams lead, to make sure that the task gets done. Gameplay teams often have tasks that are 80% programming, but it still hinges on design.
6. Sprint planning
There are as many ways to organize your team as there are grains of sand in Sahara, many of them contain some sort of sprints. Currently at Arrowhead, we use a system where we plan one week sprints every Wednesday and do a rough planning of the following weeks’ sprint. Every Wednesday morning we then evaluate the sprint and mark down which tasks were completed and which failed (and for what reason). We then revise the rough plan we had in place and make a new rough for the following week.
Every task is assigned to a team, Gameplay, Art, or Code. It is not necessarily the team that will do the most work on the task, but rather those responsible for the completion of the task and the team that can clearly tell you when a task is complete. Each task is also easily verifiable; they have a clear line where we can say if it passed or not.
7. What is Blockout and what is Greybox?
As we grew in the art department we quickly found that tasks we planned for sprints had vague descriptions. It used language that one week said to greybox something and the next week used blockout. It also tended to use wordings like “make pretty”, which we quickly found out was nigh on unverifiable.
We soon realized that we needed a common language with solid definitions of what words imply. This led to a larger overhaul of our art workflow, defining absolute terms for asset creation and level creation respectively. We are still revising this as we go but just a simple sheet with clear definitions of the words and what they imply will help your team speak the same language.
8. Language as a barrier
As with the clear definitions of words it’s important to realize that words have different meanings to different people – I say potato you think I mean tomato. Maybe not in the same extreme, but often disagreements between people can be boiled down to having the same opinion but communicating it differently.
This is especially true for people that have not worked with each other before, or simply those who may have a harder time reading social cues. People tend to naturally adapt to each other’s specific meaning if they work together for a long time, but just being aware that they might mean slightly different things with what they say compared to how you interpret them and this can make you think twice before getting into a heated argument.
9. What was it that I was supposed to do?
Another common issue is that someone may request for another person to do a task, but that said person can’t do it right away as they are already in the middle of something else.
The task is then misremembered and the end result is not what was requested. This is more common than one might think as the human memory is very unreliable. A good practice for this is to have a list, or just make a little post it note specifying the task that needed to get done. There is then a physical agreed upon guideline to adhere to and the risk for tasks being misremembered or forgotten entirely is lowered.
When I give people specific tasks that need to get done “soon™” I have taken up the habit of asking them if they want it on a Post-It note or where they want it written down. Some like Post-Its, some have their own pads where they keep stuff that needs to get done, and some use Trello or similar.
10. To poke or not to poke the programmer
As we all know, programmers are of a special kind and like to shield themselves from the outer world. This is for a good reason though and applies to everyone: as soon as you are interrupted in your work you lose your flow and need to find it again. Being constantly poked by other people who require your attention can be infuriating.
Try to find ways of building a message queue instead. Use a chat program like Slack to send messages, the person can then go over Slack once they have the time or a natural break in their work.
Sometimes you just need help instantly because something is blocking your work or several other people’s work, and in that case of course you need to get help immediately. Just think twice before disturbing other people.
On a final note…
Communicating efficiently and at a good level is no easy task, as with everything it is best in moderation. Or as we say in Swedish: “Lagom är bäst.”
I can totally relate to this: “as soon as you are interrupted in your work you lose your flow and need to find it again”
Fortunately my boss understands this well and keeps stuff off me when I need to focus on something specific, but it can still happen because sometimes the interruption is more necessary than keeping focus on previously assigned task.
I am sure it applies to more than just programmers. Anything where you need to think through and then work to complete can be disrupted easily with even simple interruptions.
Communication is a central part of all things in life from an academic view point. Communication is the basic building blocks of life being central to simple tasks like asking for help to open a door when your hands are full or more complex task like overseeing the operations of a multinational global conglomerate that is on the leading edge of a multi-trillion dollar industry such as the video game industry. Communication is central in family, work, school, software development, commercial business structure, raising kids or parenting, relationships, marriage, and so on and so fourth.
Information is also just as central to many facets of life. The wrong information or misinformation can be a very destructive force when this information is conveyed or passed along in the communication process. Incorrect information that has found its way into the communication process can lead to misunderstandings or issues that can not be solved on the technological side of being a developer in the age of computers. Misinformation can lead to total failure, loss of community, loss of trust, mistrust, a uniformed consumer base, team direction and bearings being in the wrong direction, and a lackadaisical approach to the development cycle as tasks are simply incorrect needing to be redone again for no good reason. There are many more things that the wrong information can lead to in all aspects of life and a litany of things that become the outcome of the wrong information being implemented.
Saying communication is an important aspect of development is just a rehash of an age old paradigm, idiom, or academic belief. To have good communication there must first be physical two way communication as the root meaning of communication means information or ideas being conferred between two individuals. Communication is something that Arrowhead Studio needs to work on I can see from the above post as there have definitely been some serious issues that have arrived. A laissez-faire approach to anything has been deemed incorrect by the current world standards in the year 2016. Literature on communication is in a large general abundance in many circles and is a common topic of the leadership courses that had risen to popularity and mainstream society in the 1990s’.
Agile Development is the life blood of current world standards of software development and computer industry cycles. Agile offers many well thought out and tested ideas for implementation in the development within the computer sector. The Agile Development Manifesto has been tried, tested, and proven and has been communicated by cutting edge companies, business leaders, as well as thousands of books, journals, and articles over the last two decades.
One of the major principles of Agile development that I see again and again being beneficial in todays world and market-place is the call for the development of viable software production in very short cycles. Short cycles being defined as a few weeks. The short cycle provided by Agile Development gives companies the ability to remain constantly active on activities that are actually constructive. Being active is important to producing a positive vitality. The cycle of a few weeks for product development in Agile also allows for companies to stay above the past and constantly looking to the future. Most importantly companies that have followed the Agile doctrine have stayed fresh and above the fray and these companies do this with a very bright future in sight if everything works out. There is enormous wealth in computer development.
Arrowhead Game Studios has had the same games on the website for the last 6 years. Producing a bad end product every few weeks is not a good business plan and would most definitely lead to a negative company image. Agile describes balance as a central part to development and is in some cases seen as a user or end user oriented approach to business. Agile has clamed to world wide acclaim and adoption for a good reason and its merits are not unfounded. The scales of balance fundamentally function off of the physical confides of the world. These laws cannot be broken or altered as it is gravity that cause scales to function and as gravity is defined as a constant the laws, and ideology that balance convey cannot be broken the same as gravity. Why would anyone defy reason. You can quote me on that.
Agile is the greatest weapon in the arsenal of the computer developer to defeat and ward off trolls. Definition of internet troll or trolling: a troll (/ˈtroʊl/, /ˈtrɒl/) is a person who sows discord on the internet by starting arguments or upsetting people, by posting inflammatory,[1] extraneous, or off-topic messages in an online….https://en.wikipedia.org/wiki/Internet_troll.
Trolls hate the light of day light, endless toiling, life, happiness, others, and live this way with pleasure. The troll knows that confrontation, discussion, insight, and facts will expose it as a fraud and will try to stay away from or distract attention away an instances of this happening. Trolls are rarely found and commonly unseen in person just like the mythical creature characterization of a Troll.
Agile powers and promotes development, ventures, vibrancy, communication, logical thought, balance, developer communities, software, advancement….and so on. All great things that Trolls hate, yet all these things Trolls cannot stop as the power of Agile is heard and resonated all around the world. Agile is simply to powerful of a weapon for the Troll to over come.
Developers using Agile and the end users that are supplied by said developers are already on to the next good thing before the Troll can even keep up or plan and stage a campaign to under mind both the end user and developer. Agile leaves the Troll in the past and makes these old news. Agile shines the sun light on the illusive Troll. Being agile and using Agile Development always keeps moving on to the next and this is done so fast it is hard for naysayers and trolls to keep up while benefiting the computer development community immensely.
Agile is the greatest weapon in the arsenal of the computer developer to defeat and ward off trolls. Definition of internet troll or trolling: a troll (/ˈtroʊl/, /ˈtrɒl/) is a person who sows discord on the internet by starting arguments or upsetting people, by posting inflammatory,[1] extraneous, or off-topic messages in an online….https://en.wikipedia.org/wiki/Internet….
Trolls hate the light of day light, endless toiling, life, happiness, others, and live this way with pleasure. The troll knows that confrontation, discussion, insight, and facts will expose it as a fraud and will try to stay away from or distract attention away from an instances of this happening. Trolls are rarely found and commonly unseen in person just like the mythical creature characterization of a Troll.
Agile powers and promotes development, ventures, vibrancy, communication, logical thought, balance, developer communities, software, advancement….and so on. All great things that Trolls hate, yet all these things Trolls cannot stop as the power of Agile is heard and resonated all around the world. Agile is simply to powerful of a weapon for the Troll to over come.
Developers using Agile and the end users that are supplied by said developers are already on to the next good thing before the Troll can even keep up or plan and stage a campaign to under mind both the end user and developer. Agile leaves the Troll in the past and makes these old news. Agile shines the sun light on the illusive Troll. Being agile and using Agile Development always keeps moving on to the next and this is done so fast it is hard for naysayers and trolls to keep up while benefiting the computer development community immensely……There is an old adage: No one likes negativity.