“The basic idea is to get the game up and running as soon as possible in its crudest possible form.” – Phil Robb, Turtle Rock Creative Director
Concepting and prototyping allows developers to cheaply explore a design space in order to find the nuggets of gameplay that can be polished to a high sheen. The single biggest issues are the size of this design space and the efficiency with which you can explore it. Roughly speaking we want to explore as much of the design space as possible as quickly as possible. There are two good routes to this; defining good constraints and working in parallel.
Good Constraints
Limiting the size of the design space is something you want to do for a whole variety of reasons:
- To match company vision and goals.
- To tackle specific problems.
- To meet the abilities of the staff you have.
The single most important reason for defining clear constraints is to aid creativity. It’s simply easier to think through choices when they are limited. Constraints don’t need to be externally imposed nor do they need to be shared between teams working on new concepts. They do however, need to be good constraints. So what is a good constraint at this stage in the production lifecycle? It’s a constraint that can act as a quick razor to dismiss ideas. For example:
- Genre.
- Functionality requirements.
- Team size and experience.
Bad constraints are not invalid constraints but ones that are more complex questions where the answers are unclear this early in the project. A good example would be setting a deadline, for example this product must ship within 18 months. There is almost certainly a constraint on the amount of time a project can take to make it to market in a business but estimates of this at an early stage in a project are going to be completely wrong. People deal with unpredictable things that need to fit into a fixed timescale by being extremely conservative, which is probably not something you want at this stage in a project where there should be maximum creative scope.
Go Wide
It’s a truism that it’s quicker to explore a space by splitting up and taking different sections. Double Fine’s Amnesia Fortnight is a good example of how this might work in practice within a small/medium sized company. Likewise Vlambeer demonstrate that even as a tiny studio by severely limiting the amount of time you spend on a prototype you can hit many different ideas including some that become successes. In an ideal reality concepts should be something that are being developed all the time. Who doesn’t have a book of design ideas juggling around in their head or transferred to paper? Creating a prototype is more time consuming but critically allows a better understanding of how well the proposed idea meets the constraints and how feasible it is for a given team to develop. The more prototypes you can create the better you have explored the space and the more likely you’ll have come across the true maxima in that space. For larger companies it makes sense to have many small teams prototyping at once and as one or more ideas become more concretely ‘the best’ begin to structure those teams around moving them into pre-production. Sadly what you’ll mostly see are a lot of companies that have one small team working on one particular idea without really bothering to more fully explore the design space. This usually results in companies paying lip service to the production lifecycle without really buying into it because there are no real alternatives to the one project in flight.
Ideally what a developer is looking for is for the lifecycle stages to act as a funnel. As the stages are progressed you gain more information about how well the idea meets the constraints and the teams ability to implement it. So as you move through the stages ideas are discarded as they are found wanting.
Click through to a bigger version so you can actually read the text.
During the development of APB we had a whiteboard in our kitchen/break area on the third-floor of Realtime Worlds offices that served as a bit of a community scratch-pad for daftness. This particularly entry was started by me after we shipped but just prior to our investors pulling the plug and plunging the company into administration. The contents are contributions from all the development staff who worked on APB. We also had a “What Went Right?’ board which is sadly consigned to the mists of time.
The complaints can be broadly broken down into three areas Design, Business and Production. All opinion from here on is my own and comes with the caveats that everything happened at least three years ago and I’m writing from my own specific perspective. I worked on APB for five years as a Software Engineer specializing in Gameplay by the end of which I was probably doing a job closer to that of today’s Technical Designers.
Design
“What IS APB?”
“No clear vision”
I think this is key, naturally, because I wrote the first question! The project went under at least two major shifts of focus in the five years I worked on it but only had one (bad) prototyping period. The creative vision was extremely woolly and the end result is a mediocre third-person shooter surrounded by some odd and mismatching features. Each time we refocused we should have sat down and reprototyped the new “vision” extensively both to get a firm idea of what we wanted to make and also to know what we needed to build. This lack of cohesive and shared creative vision has been the scuppering of a whole bunch of projects I’ve been a witness too.
“Overwhelming arrogance across the board in the face of criticism.”
“‘As Designed’ and ‘Post Launch'” – Unpopular ways to close design defects.
“It’s not that type of game.” – A phrase often uttered in the face of criticism.
In my experience I’ve not seen very many development teams who weren’t very aware they were making a lemon. APB’s was no exception and our bug database teemed with obvious design flaws and people voiced criticism of the game even before we had a whole load of beta testers giving us very valuable feedback. Internal feedback is too easily dismissed and by the time we got external feedback we were basically too busy fixing defects and optimizing the game to make any sweeping changes. In hindsight the writing was on the wall for the company about 6-8 months before APB shipped. The key take away here is that criticism and how you use it should be the defining factor in how you should shape your game. That doesn’t mean you need to respond to everything people say or implement their suggestions but study the root causes of what is being complained about and look for ways to improve the experience. The very worst thing you can do with criticism is ignore it. One of the games main critics in the development team actually went on to be Lead Designer for the successful GamersFirst reboot.
Business
“Not understanding what makes people pay money for online games.”
“Not enough value to pay an on-going fee.”
I actually think this criticism is wide of the mark. GamersFirst demonstrate very obviously that there is a viable business model for APB as they’re still running it three years later! Sadly it’s not the one we chose to use. Plus we made ourselves look foolish by telling people the game wouldn’t have a subscription and then having a subscription option as part of the business model.
“Marketing”
Very simple, we didn’t market the game we had made, we marketed an ideal. If we didn’t have a design vision we had a very clear vision we marketed which was essentially GTA online. We setup elaborate videos, had tightly scripted demos run through by our ‘Publisher QA’ that involved shooting to miss a lot. If we had successfully made that game we’d probably be rolling around in piles of money and I’d be writing a very different blog!
Production
“Software Engineering versus Games Development.”
I spent a lot of my first year at Realtime Worlds exhaustively writing Requirements, Specification and Designs for everything I made. To the point where I’d have to send documents out for review and sign off. I’d get revisions back for rework with no substantive disagreement in them other than grammar use! It was a colossal waste of time and resources as well as being a known about and demonstrably bad practice for software development. Documentation isn’t a terrible thing but Big Design Up Front (BDUF) is. This will be a reoccuring theme.
“Not enough iterative development/prototyping.”
“No #1 focus on fun gameplay.”
“No focus on core gameplay.”
Its no accident that I’m a big fan of making things to prove they work and learn about the problem space. APB was very instructive about the problems that can be created by designing something, implementing it and then calling the results done and good. BDUF strikes again and in this case made worse by being in siloed teams. At one point the Gameplay Engineering team I was on had a pretty tricky working relationship with our Game Design team! This is not a conducive setup to making a good game! Cross-functional teams that are genuinely collaborative just work much better. The sense of shared ownership and ability to rapidly iterate on something make for better games and a shorter development time.
A consequence of siloed teams that couldn’t iterate is that our core game never got much love or attention. Sometimes it also felt like people didn’t consider it a problem. For example the first thing suggested by one of the senior designers to work on after the game shipped wasn’t an improvement of the core mechanics but a Zombie themed mode! After APB launched along with a bunch of other people I put together a proposal about how we could improve the core game. We proved the effectiveness of a cross-functional team freed from the constraints of bureaucracy by improving the core experience an awful lot. Sadly only a small part of this made it out before Realtime was shuttered and a lot of the work we did was incorporated into the first few released of APB: Reloaded.
“Hierarchical Management Structure.”
“Branching by Team rather than Feature.”
At first these two don’t seem related but they have the same root cause. As the reliance on BDUF and siloed teams suggests we had a deeply old-school approach to development right down to running the closest thing to a waterfall methodology I’ve actually seen in the wild. Hence why we ended up branching by team rather than feature and had a overly heavy management approach. I won’t labor the point because the problems associated with this approach were well documented decades before we used it. The solution is to become more agile.
What Went Right?
Actually an awful lot. A lot of the technology in APB has still yet to be surpassed. The level of customization was outstanding, not many games ship with a music sequencer! There was a decent niche game under the baggage of a bunch of poorly integrated systems that the GamersFirst guys appear to have made into a sustainable free-to-play business. There are a bunch of triumphs against adversity in any failed project and APB was too choked full of talent for that not to happen.
When you start to make a prototype one of the first decisions you have to make is which medium to use. This might seem like an easy decision to make, just pick your preference and roll with it but I think there are a few more subtleties to it born our from my experiences of the various mediums. I want a prototype to demonstrate that the game idea I’ve had is good, that I and my team are capable of building it and that there aren’t a bunch of crazy unknown issues lurking to catch us out down the line. It also shouldn’t take too long to build, otherwise we’re just making the game. Ideally I want the lowest cost solution that gets me sufficient information and that differs per project.
Digital
Digital prototypes are ideal for video games, right? After all we’re trying to make a digital game?
Well yes and no. Certainly making a real videogame as a prototype will get you the most accurate information about the game you intend to make. The largest issue for developing a digital prototype is cost. It’s by far the most expensive option. Firstly because it’s much more complicated to make a digital game. Secondly because the expectations in terms of acceptable production values are higher particularly if you want to test the prototype with real people.
As such we only really want to use digital prototyping when the other methods wouldn’t work. In reality this boils down to interactivity and how close the prototype will resemble the final game. The more realtime interaction the game or feature requires the more you would have to abstract that interaction for it to work as a paper or whiteboard prototype. That abstraction comes at the cost of real knowledge about the game since we’re no longer dealing with the game as it is going to be played.
Another danger with digital prototypes is disappearing down the rabbit hole and not limiting your development. It’s extremely tempting to keep working on an idea for a video game once it exists despite things not really working. “If only I had <feature d> then it’ll be good… *three months later*… if only I add <feature x> then it’ll be good.” To avoid this feature creep you need regular evaluation of the prototype with decision makers. You also need to accept failure. It’s a good thing to find out your idea is not viable quickly. This can be a problem with the other mediums as well but in my experience videogame developers understandably get caught up much more easily in their chosen medium.
For example a team of five of us worked for three months at CCP to make a multiplayer prototype of some potential avatar based gameplay for EVE Online. In essence you explored an extremely dangerous environment as a group in order to salvage ‘awesome stuff’. We could have prototyped this quite easily on paper as a boardgame in much less time but you would lose quite a lot of the feeling we were attempting to create in being confined and exposed to danger as a group. Plus we wouldn’t have come across some of the technical challenges we faced when implementing it. This all fed into the final proposals we made to the Executive Producer of EVE who canned our project because we didn’t have the man power to produce it. A good decision and a good result for the prototype.
Paper
Paper is awesome, nearly a
nyone can make a game just using their imagination, paper, scissors and a pen.
Paper works best for prototyping game systems that work at a slightly slower rate than most twitch games. However there are often system in games that actually work in a way that’s easy to translate into the turn-based mechanics of card and board games. The problem then becomes abstracting the twitch elements from the game in such a way as you can be confident that you are modeling the rest of the game correctly. The more integral the twitch gameplay is to the game the less this is acceptable and the more attractive a digital prototype will look. Even if the game works at a pace that is amenable to turning into a board or card game you still might need to simplify it to be fun as a game in that format. People are less capable at complex maths than computers, even a slight increase in complexity of a game system makes turns drag, the game hard to understand and hard to pick up. This can be a good revelation though as very often in games we want people to be able to intuitively understand their systems and those with too many hidden variables become increasingly hard to fathom. Further simple systems that still produce the required ‘simulation’ or feature are much easier to maintain and balance.
The image on the right is an example of a card prototype I made for a revamp to the hacking mechanics in EVE Online. The system as it stood involved a skill check on a timer and after a designer defined amount of successes you had hacked the item in question. Very simple and worked well but it was also deathly boring. In revamping the game system I reimagined it as a simple ‘procedural death labyrinth’ and as the system was turn based it was very easy to represent as a card game.
Actually making and iterating on a series of prototypes was done over a couple of weeks and involved my entire team plus a couple of game designers from other teams. We also playtested the game with a variety of other people in our office not only to get feedback on the game system but to spread understanding of what we were going to build. Once we were pretty happy with the gameplay we had prototyped we quickly moved on into actually making the system. There was a really short timescale to make this game system and I credit the vast majority of the success of the game system with players to the time we spent prototyping right at the beginning. It gave us the confidence to power into implementation with a strong, shared vision that we knew would work despite the full digital version only really coming together in the last week or two.
Whiteboard
To me Whiteboards are the place to design and prototype details in a Just In Time fashion. They are great for quick, collaborative sessions where you are trying to build a shared picture of what the intimate details of the immediate work are. Most of the time I’ve used them as a way of explaining an idea through a series of pictures or a diagram that can be changed to show the state of the game you are currently talking about. This can be particularly useful to work through several different ideas quickly in order to pick the most viable for a first attempt at implementation. They are also really good for collaboratively designing UI.
However using a whiteboard is also the most approximate form of prototyping. Very often you’re not exploring the game system itself but how it appears and works from the point of view of the end user. They should be used liberally but in support of other forms of prototyping rather than instead of them.
It was not the Hollywood triple-A top-down script thing where you spend months scripting out a game design, the art style, you spend years implementing before you can try it out, and if it sucks, well, you hope it wasn’t your money. It was all about an interactive design. You want to start with a minimum playable design, play it, improve it and repeat until a fun game can evolve – which could be completely different from what you intended.”
GDC has bought with it the exciting news that many companies that make game engines are following in Unity and Game Makers footsteps in an effort to “democratize development” as Unity’s CEO David Helgason puts it. Most are following a subscription model with a variety of price points having been announced. This is great news for developers as access to professional quality features, cross-platform development and increased productivity just got a hell of a lot cheaper. I can get a fully featured game engine with full source for less than I spend on my internet connection per month. That’s pretty crazy.
The main downer I can see at the moment is most companies seem to be competing on cost rather than productivity. Wild eyed developers who see the shiny features and triple-A titles that the engines have powered are already announcing the death of Unity. In truth though the reason you buy an engine off the shelf is to save yourself time and money building, maintaining and improving one of your own. Most games companies are interested in making games not technology. As such cost is only really an issue if you end up spending more money than you save in increased productivity. Even at the indie scale we’re talking about such small number differences (tens of dollars a month) that even a mediocre productivity enhancement in a more expensive product will more than pay for itself many times over. Given the price point differences the cheaper end are really saying to me “look we know our product isn’t great but at least it’s cheap” only the cost saving isn’t radical enough to offset the potential loss in productivity between platforms. For example at this stage Crytek would have to pay me to use their engine over the competition. Their tool is just not as usable, which is not to say it’s a bad engine, because it isn’t, but the UX is just terrible.
Bad UX is a typical problem of internal tools. They are built in an ad-hoc manner to a “just good enough” standard and are often just plain terrible from the perspective of the user. Typically horrors involve choice paralysis, bugs and lack of a well designed workflow that matches users needs. Most companies survive this because they have a huge amount on institutional expertise to guide new users and new projects through the complex maze they inhabit. This knowledge also tends to be tribal, passed on by word of mouth and custom rather than by good documentation. As soon as you can’t rely on this institutional knowledge you are basically screwed and your productivity is going to be very bad until you learn it. This has historically tended to be a big problem facing teams adopting internal technology and is an even bigger issue if you are licensing someone elses technology. The reason Unity currently has far more users than other engine companies who have also had free offerings for some time is simply that their mission has been to empower developers so their product is just easier and better to work with.
I’d also be very skeptical about getting seduced by revenue sharing schemes. 5% gross revenue is an awful lot of money to ask and could well push a developer into making a loss rather than a profit on their game. For example you make a game in one year and sell $100,000 worth of copies. $30,000 of that will go to distribution (e.g. Steam), $5,000 goes straight to Epic (plus the $240 you spent per month) leaving only $65,000 to account for marketing, the creation of the game (you’re going to pay yourself right?) and any profit you want to actually make. For Unity the upfront costs are higher but that 5% cut is gone so rather than costing you $5,240 you are only spending $900. When your margins are slim that’s important.
A Wishlist
So what would I like to see from an ideal commercial game engine?
- A company that puts empowering developers as their first priority. Without this the project is doomed. The entire mission for any new feature should be to make the UX as good as possible within the other constraints. The tools and code should be extensively documented and that documentation should be easy to search and use. Video tutorials and regular education opportunities would be excellent. Further support for the community is a must as very often people will solve each others problems.
- A clean architecture for making games. This essentially means that the process of creating a new game entity should not be unnecessarily convoluted nor should the resulting entity be polluted with lots of unnecessary stuff. I’m very much biased towards engines that make use of an entity-component system these days. The architecture should make inter-entity communication simple and event driven. There should be templates for scenes and entities which provide good support for procedural generation. All the engine code should be well tested, by which I mean it’s covered by unit and integration tests further it should be easy to write and run these tests on game code.
- The engine should be fast. Game developers still want to push hardware particularly on fixed platforms like consoles. This means at the very least the engine needs to be multi-threaded probably with a generic jobs system to make use of the cores that are available on various platforms.
- The engine should be portable. If it can’t build to consoles, web, mobile platforms, Linux and desktop OS’s then that’s a bit of a deal breaker. Not because you necessarily want to deploy to all those platforms but because having the option means you can should your companies plans change. This is important from the perspective of productivity as porting a project can be an awful lot of work especially if you need to learn a new engine to do so!
- Iteration times should be blazing fast. Data should be editable on the fly and it should be ludicrously easy to experiment with ideas. It’s even better if code can be live reloaded, usually from script to avoid the pitfalls of compilation where certain cases will force you to tear down everything.
- It should be easily extensible. An editor you cannot customise is pretty useless. Doubly so if you want to fit it into any sort of Continuous Integration/Deployment or want to implement a more complex build process.
- Integrated. At a minimum the editor should support various forms of source control. Support for other popular developer tools out of the box would be gravy.
- Source access. Big, ambitious projects will almost always need to modify the engine internals.
- Feature rich. This comes last. Shiny features are no good without the above. Unity has amply demonstrated you can have a feature rich editor simply by empowering developers.
Now that these opening salvos in a battle over license cost have been fired we’ll hopefully see a wider war waged on empowering developers with tools that really enhance their productivity.
In my post Cross-Functional People I talked about the value of generalists and how they prevent agile development from getting really screwed up. I thought it would be good to look to the other side. Are there areas of game development where we want deep specialization and more general skills aren’t really required? My instinctual reaction is yes and they’re most valuable in the parts of games development that are better understood or perhaps to put it better less volatile. They are the areas of development where you perhaps wouldn’t have lots of traditional specializations taking part together so don’t have the problems associated with internal team dependencies. For example a lot of rendering or engine engineering doesn’t have much call for anyone other than software engineers if your automated testing is good. Similarly making high-quality production art is not something you need much in the way of engineering to do once pipelines and tools are good.
Or perhaps a better way of thinking about it is that they still need to be cross-functional people but in a more specific domain. Just as being a cross-functional game developer is a different domain to being a cross-functional OS developer. The wider the scope of the domain the team is tackling the wider the scope of skills you need. In this respect it might be more sensible to consider these domains as specific specialized sub-teams who still work in an agile manner but serve as components to the teams with a wider scope. A good engine team empowers a feature team just as having a solid game at the end of pre-production empowers the content creators and artists to fill the game during production. Although I’d argue that many teams would be better learning something new for tasks with small scope rather than having often messy dependencies with other teams or individuals. For example on a small team it’s probably better in the long-term to learn to write shaders than contract that out to someone else.
So in the end I’m arguing for specialization of the team rather than the individual and that results in a different set of requirements for the functions that need to be filled the team members should still be cross-functional. Further this can only really be an issue in large scale development. Small game teams by necessity have to either learn new skills or contract in specializations they lack. This also speaks to a requirement for large teams to be organised differently as they move through the game development lifecycle.
In this post I’m going to continue setting up some ground work to talk about Agile and Games Development by discussing the Game Development Lifecycle. A lifecycle in this context is the identifiable stages of production a project moves through from initial conception through to shipping (or going live in the case of services). I think the games lifecycle is pretty much divorced from the project management methodology you follow. There are simply several stages a game goes through whether they are explicit recognised or not. Much of what I write below is idealised in order to illustrate what I think the stages are and what happens in them. I’ve also deliberately ignored stuff like marketing as I’m no expert and it’s something so dependent on the chosen business model.
Here we have the lifecycle:
A couple of initial things to note off the bat. Firstly there is no scale to this diagram it ultimately captures the process in a fractal manner. As you decompose a game you still need to go through all of these steps for each component of the design. For example if you are adding a new feature to an existing game you still need to work out if it’s a good idea or not so prototyping is only sensible. The second thing to note is that the transitions and where exactly a game is might not be clear in any particular organisation. Some organisations are very formal, have very specific hand-offs and might even abandon work (but keep the game artifacts made). Others, particularly in smaller teams can be very fluid and the move from prototype to shipped product is a series of refactorings of the game. In my opinion almost all games go through these lifecycle stages and quite a lot of project cock ups come from not respecting the limitations of each stage. For example if a project goes through a sudden large pivot in development during some of the latter stages then it’s behooves people to recognize that they will need to drop back in the game development lifecycle for substantial portions of the game to prove it out again.
Moving from left to right through the stages in the diagram should lead to a firming up of the game ideas. It’s an oft said thing that the initial game concept bears only a passing resemblance to the final game and that’s because ideas are just the starting point. Ideas need to be tested and refined, preferably in the crucible of real player experience. This is one reason why putting a massive amount of time into a monolithic design document before anyone starts making anything is a terrible idea. Moving through the lifecycle stages should also firm up knowledge about when the game will be shippable and the scope of work remaining. For a lot of projects this doesn’t happen though and I think a decent Agile approach that takes some ideas from Lean would help approach the lifecycle stages with the right mindset.
Idea
The cornerstone of any project but also the least important part. Ideas are ten-a-penny and it’s the ability to take that idea and build something good from it that is hard. Sometimes the team you have might not be a good fit for making a particular idea or the resources required are unrealistic for what you want to achieve or there is no real market for your idea. There are lots of reasons not to pursue an idea but at this stage many benefit from a little making to gain a better understanding of what might be involved. I’m a firm believer that there is a lot of value in a failed idea and even more value in having a whole bunch of ideas you like in existence as prototypes. Ideas should be given a quick sanity check before moving onto the next stage without getting too involved in details that will likely change further on in the lifecycle anyway.
Prototyping
Lets make a game! In game development it’s the job of a prototype to take the core game ideas and demonstrate that the team is capable of turning them into something fun. This is necessarily messy and exploratory. It’s also an ideal time to stop spending more money on an idea if it seems to be going nowhere. I’ve written at more length on the value of prototyping to both individuals and businesses as well as having spoken about my own experiences. The end result should be an entry in your prototype repository and a decision about whether or not the prototype was deemed a success. Prototypes are also very useful for securing funding to take the game into pre-production as well as validating your game idea by letting real people get their hands on it.
Pre-Production
Pre-Production begins when you take a prototype and decide to make it into a complete game. It’s the process of taking the core game ideas, refactoring them and expanding on them to create a meatier game with the view to nailing down most of the game systems and features. As this progresses the underlying technology is generally refactored as well, to make it technically better and suited to the creation of the large amounts of content many games need. The goal of pre-production is typically to end up in a position where the majority of the work remaining is content creation without large changes to game features. Usually this culminates in a ‘vertical slice’ of the game containing every aspect demonstrated at production quality in a ‘one level’ run through. Making a ‘vertical slice’ also exposes the weaknesses in the technology and content creation pipelines that need to be fixed before the game should be put into production. There should be further validation of the game with lots of real people all the way through this process as the game changes and by this point you should have a good idea of the quality of game you are going to put out.
Production
Production is the point where you get hard to work at cranking out game content which is often the most time consuming part. At this point it can get incredibly expensive to make relatively innocuous seeming changes to the game design. For example altering the attributes that define how a character jumps at a late stage might mean you need to rework all the content in your game. Ouch! Ideally people not concentrating on making content or supporting content creators will be fixing defects, optimizing the game, improving the user experience or ‘juicing it‘. Hopefully it goes without saying that you should be putting all this new content in front of real people all the time to validate that it’s fun and works well with the game pacing (e.g. everyone fails then gives up on stage 3, maybe we should fix that).
Polish
Polishing is the final step that takes a game from being good to great. It’s adding more ‘juice’, improving the user experience, making sure the game pacing is great using feedback gained from playtesting with real people, squashing as many defects as possible and making sure the game runs smoothly on all targeted platforms. A lot of the time this runs in sync with production as some content is often finished before other parts. Although a bit of time at the end of a project dedicated to making the game much more polished can make all the difference. A word of warning though. Games never feel finished to the people working on them. At some point you just have to stop and put it out into the world.
Ship
Champagne or shame this is where the rubber hits the road and your game either crashes and burns or achieves some reasonable commercial success. It’s also the hardest point to reach for all sorts of reasons so it’s quite an achievement to be part of a team to ship something even if it’s not a commercial success.
Cross-functional people AKA T-shaped people or Generalizing-Specialists. The idea that as well as a deep understanding of one subject you want someone with a more general understanding of many others as well. The concept is not new but its quite hard for people to take on board as we live in a culture that raises us to value specialization. Even in education people are pushed further and further into their own little box until a fresh faced person pops out who has “this is my specialty” emblazoned into their mind. The problem with this approach is that it sets up boxes that people are put into based on their label. Even if a team is cross-functional with a mix of the specializations required to build a product people are often trapped in their ‘specialization box’ and this can manifest all sorts of problems:
Slack Time – You have a workflow defined by specializations: The designer will design the stories you have in this iteration, the engineer will build them and then the result will be tested for correctness by a QA person and the defects found fixed. The problem here is that the poor QA person will only get a couple of days to do all of the testing for any artifacts created in an iteration and will have spent the rest of his time not working on the things the team will be doing. Likewise the designer will have to be done early in an iteration in order for there to be development and testing time. The engineer is an even worse position as they will be twiddling their thumbs at the start and end with an unknown amount of work to cram in right at the end to fix any defects. The team is not really working as a team but as an assembly line. In fact it’s just the old-school silo by specialization approach in miniature. Working in time-boxed iterations and being co-located have lots of advantages but now people have to scramble about for things to do to fit into the awkward gaps. Worse still planning each iteration is a nightmare of trying to fit together tasks given the variable length of time design, development and testing may take. This leads to a tendency for each iteration to bleed into the next as estimation goes awry. We could just make the iterations longer but that makes us less able to respond to changes and increases slack time. Often this leads to a naive fix:
Working Off Cadence – Brilliant! We know we’re a waterfall production line in reality so we’ll get the designer to make a design in an iteration. Then the engineer can build it in the next. Finally the QA person can test the end result and the engineer can fix any defects in the final iteration. Now we can all work in parallel at different points in the cycle! Only now we’re even less of a team than we were before! Plus each of us will have to context switch all the time to deal with team members in earlier and later iterations. We’re also now taking three iterations to make anything so after the first three iterations we will be constantly delivering things at the old rate but there will be three times as long between starting something and receiving any feedback on it. In that time we may have designed new systems that take advantage of things in mid-flow only to have to rework both things when feedback comes in. Clearly this system is better at delivering a constant stream of things provided we don’t make any mistakes. However the cost of mistakes, people going on holiday or getting ill just increased a lot! We’re also setting ourselves up to make mistakes by dividing the attention of everyone between several different things in flow. This doesn’t sound good at all!
The answer to this problem is to let people break out of their box and collaborate to make things. Specialists become facilitators and mentors to the team in their area of expertise and the team actually works together to design, build and test the product. The risk of mistakes are lowered as the team is bringing their expertise to bear on each stage of development, the team is more resilient to everyday problems like illness and ultimately the team will be able to self-organize better to account for members strengths and weaknesses.
A few days ago I posted a quote from the Hearthstone developer Eric Dodds about how great it is to work with cross-functional people on a team because everyone is involved and that leads to a better game. But why is that so? I think several things come into it:
Shared Vision – The team builds and truly owns the vision for their work, rather than a few team members doing it in isolation. This means everyone is on the same page building something they feel ownership of. It’s a massive boon to motivation and team building. The team has a purpose and work becomes more enjoyable. It also cuts out a lot of the communication problems caused in trying to articulate ideas namely that it’s very easy to miss important things out when translating ideas to text and the text is easily misinterpreted. Chinese-whispers on paper.
Autonomy – Individuals are no longer locked in a box and are allowed to grow as their talents allow. There has been a lot written on the power of autonomy as an intrinsic motivator.
Increased Development Velocity – Many hands make light work, when free of their box people will do what needs to be done to finish their vision rather than making work to fill their time. The more work on the actual product that will fit into the time and budget requirements the better it will be. Particularly if people are invested in making it great. Increased velocity also brings with it an sense of accomplishment.
The other place to look for the success of this approach is with Indie games. Necessity drives people to be generalists. You can’t really be an Indie game designer unless you can actually make something. Likewise just being able to program a kick ass piece of software or make awesome art doesn’t get you very far unless you are willing to work on a contract basis. These days awesome tools mean generalists can get 90% of the way to making some very complex products and only need to bring specialists in for certain tasks.
The take-away from this is that you are hurting the agility of your company or project if you have an over-reliance on the concept specialization and aren’t encouraging teams to work collaboratively to spread knowledge and skills.
It’s fantastic to have a game where everyone on the team is involved with multiple aspects of the game; we’re already a team of generalists, with designer-artists and programmer-designers and the like, but the small team fosters an environment where everyone gets intrinsically involved in everyone else’s business, and I think it made for a better game.
meheleventyone 