How development teams interact

Who do you work with at college, university, or at your job? All games developers have to work with other people. Let’s hear how these developers work in teams. A game team is going to be made up of producers, designers, programmers, artists, and then a lot of more niche roles that you fill in between. But what I like to do, and what a lot of producers like to do, is to mix those teams up. And what we’ll do is form Scrum teams. Scrum teams are multi-functional teams within one game development team. They will each have their own goals. And they will be working in, typically, two week cycles or four weeks, which we call sprints.

That Scrum team will plan what they’re going to do for a period of time. They will talk and collaborate around ideas. And then they will develop and deliver together. It will be made up of senior members of the team and junior members of the team. And everyone can be involved in that planning process together upfront. With my role as a character artist, working with other teams is– well, usually we’re kind of in the middle of the pipeline. So we’ll have concept artists before, who are kind of designing that process, and then animators and designers who will take it on after that. So we have to kind of provide what they need in their kind of role.

So usually, for example, designers and stuff will have certain hitboxes that they need the character’s things to be in. And while we’re making it pretty, we don’t always consider how big that thing needs to be or whatever. So that’s why a lot of discussions and stuff and remaking things to fit the actual dimensions of things is important. Yeah, I end up talking to more or less everyone. So you’ve got a core team of four programmers on the enemies at the moment, and then we’ve got to talk to animation, level design, designers, our lead designers and then producers– the one producer assigned to us. And then also, audio and QA. So we’re basically talking to everyone for different needs.

And then everyone’s coming to us if they find an issue, then it might go via QA or come straight to us, if they know it’s us that’s related to the issue. So more or less everyone, right? It’s the same for me, really. Like, when it comes to talking to the other teams, it’s just you have to figure out who you need to go to for certain things. So if it’s like, oh, well I need to go in and fix an art problem, go to an artist and if I need to fix like, a programming issue, then I’d go to the programmers. You’re always kind of dynamically going between each team.

And I tend to find that sometimes you end up needing a person from each discipline. It’s kind of like, come together and make a decision. And be like, well, this is how we’re going to do things. Development teams are multi functional. And as much as possible, we want them to mix in with each other and not operate in silos. Collaboration is critical from the very beginning of the process. We want the programmer who’s implementing the feature, the designer who’s designing it, the artist who’ll be creating visuals for it, to all be talking as soon as possible so that it is a collaborative effort to achieve the designer’s goals. Teams are typically led by the most senior members.

They’re going to be managing and developing everyone within the team. And they will have a lot of the ideas that lead the team. But when we plan for a specific feature– for a specific idea– having junior members of the team, people who will be doing the quality assurance all together upfront to plan and voice ideas can be the most productive. And sometimes, the best solution has come from the most junior person in the room.

Before I got this job, I definitely expected to work a lot with others. Because during university, I spent a lot of time working in teams. So that definitely prepared me for that side of things. I don’t think you expect to be quite as one on one as you are with a lot of the other disciplines. Because you have some days where it’s like a whole day I spent with a programmer or an artist or another person on the team. And that was quite surprising to me, just how much one to one time there can be at times. Yeah, I definitely agree with that.

I don’t think I really realised how much input people want in kind of collaborating with the creative side. I kind of thought, maybe they’d just give you the thing and leave you to it and just get it done as fast as possible. But part of the way we work is everyone wants to kind of talk things out and make sure everyone’s on the same page about things, so yeah. Yeah, I was more or less hoping to have a lot of interaction with other people, because that’s what I like the most. I don’t really like being shut off from other people. So yeah, it’s nice just always talking to other people, getting their input, finding out what they need from you.

Because specification documents don’t always tell you the actual useful information a lot of time. You need to go and talk to them to find out what they actually want. I think one of the most challenging parts of being a producer can be the chameleon nature of the role. People who work in different disciplines can have a tendency to interact differently. There are people who are more bubbly and sociable, and people who want to get on with their work. So it’s understanding how I can bend and flex to get the best out of those people who want to be spoken to and interacted with differently.

Realising how much I need my team and how much they need me, we all have to constantly be in communication with each other.