• /
    • Archives /
  • November 30, 1999

Archives For November 30, 1999

MVP, EVP, WTFVPBBQ – Think don’t buzzword.

February 20, 2015 — Leave a comment

Last night I was leafing through Twitter and came across a tweet referencing the ‘great new thing’ the Exceptional Viable Product. Now stop me if you’ve heard this before but the general idea is to make sure your product is really good so it lands with a bump and gets picked up by lots of users quickly. AKA what everyone was doing pre-Minimum Viable Product and what you pretty much still need to do if you’re shipping anything like a boxed product. My initial reaction was to laugh and generate a big long thread on a friends Facebook wall. A buzzwordy and seemingly history ignorant ‘new invention’ is too good to pass up.

However MVPs, EVPs and other constructions of their ilk are really talking around the problem at hand. What should you release into the market and when? In this respect the re-invention of a pretty basic wheel in fancy start-up speak might suggest a bit of a sea change in the market as it approaches saturation with new ideas or consumers get less and less happy to switch to a new, buggy and feature incomplete product. Have start-ups worn out good-will?

Re-focusing things in terms of videogames and we can see some consumer dissatisfaction with similar ideas like Early Access. Games released in a relatively feature incomplete state have failed to engage players and then due to the funding model being reliant on new sales have failed to earn their keep. Ultimately this leads to general consumer weariness with the very idea of funding games ‘in development’. Double Fine are a great example at the reputation hit this sort of problem can cause.

Ultimately you want to ignore buzzwords and focus on the problem. What is the market situation I’m releasing into? How do I release with the best chance of success in that market? The answer to that is very situation dependent and exists on more of a continuum than most blogging would let you think. Think don’t just be taken in by the latest buzzword fad.

In Agile, Game Development
permalink

The (Bloody Awful) Art of Estimation

September 9, 2014 — Leave a comment

The entire point of Agile is to maintain flexibility in order to deal with the uncertainty inherent in developing software products. To fully display my biases this goes doubly-so for creating videogames as we’re attempting to hit much more nebulous targets like ‘fun’. Planning is still a necessity for most businesses but rigidly sticking to a plan is not. It’s embodied as this value in the Agile manifesto.

Responding to change over following a plan.

If we’re planning we need to be estimating but we know from research that humans are completely bloody awful at it when there are high degrees of uncertainty involved. We cannot see the future and are kidding ourselves if we think we can. In my experience discussions about estimation tend to go in one of two directions. We have the empiricists or Reality Deniers and the #noestimates crowd or the Oblivious Snowflakes. Broadly speaking the first group think numbers have the answer and the second group is in a really unique situation where they don’t really need to do much if any long-term planning for development.

Denial, something, something, something… river in Egypt.

The Reality Deniers take comfort in models and using data from ‘experimentation’ to generate predictions about the future. There are two problems here; context and the applicability of the model chosen. Context is the game development empiricists Achilles heel. If I run three miles several times a week following the same path in sunny LA does the average of my times translate over to how well I’ll run a mountain marathon in really bad weather? No, very obviously not. Newton’s Laws of Motion don’t apply on the really small-scale and the really-big scale but they do work pretty damn well at the scale the experiments to determine them were conducted at. If you want to use experimental data to create models to predict the future you better be damn sure your context is not about to change under your feet. Which, being videogames development it almost assuredly will.

The second problem is the model. As most people use Scrum and Scrum is about tracking velocity almost all future estimates just linearly extrapolate velocity. The problem is not necessarily that this is wrong just that it’s incredibly unlikely to be right. All sorts of things speed-up and slow-down teams and change the way people estimate for an average to be tracking consistently. Further the velocity of a team coming to the end of a project is going to be very different to one starting off. Primarily because the level of certainty and knowledge about the project increases greatly as it nears completion. Small errors in estimation accumulate into big errors over a long period of time and you can’t really be sure that everything has actually been estimated (we’re going to iterate a lot right?). Anyone who has had to write any multiplayer code knows that extrapolating linearly in the presence of even small accelerations is doomed to give you wildly diverging results.

Combine the two together and I don’t think we even need to look at problems with the experiment setup. We want to estimate an uncertain process, with data from a different context using an overly simplistic model, even dressing up in our +10 Robes of Technomancy this seems stupid. Science is rigorous, this approach is not.

#noestimates4lyfe

At the other end of the spectrum is the idea that we don’t need any estimates. I called these guys the Oblivious Snowflakes because their position is often unique and they don’t seem to realise it. I actually have a lot of sympathy for this position as it sounds dreamy and has less of a bad accountancy vibe. #noestimates is the idea of continuously shipping a product taken to the next level. These snowflakes aren’t iterating once a month or once a week they’re iterating once an hour and pushing the results out live. Of course you don’t need to estimate anything if you have already shipped a product and are able to work on it blisteringly fast. Well, in the short-term at least until someone with a tiny bit more vision and urrm… planning comes and knocks your product off it’s perch. Sadly for most of us a system of continuous delivery is a very long way from reality and most games require a lot more effort to create a viable product than a web application.

Reality Check

We’re agile… or at least supposed to be. The answer to this tricky conundrum of what to do with longer-term project planning in the face of a fog of uncertainty is damn well written down.

Individuals and interactions over processes and tools.

Customer collaboration over contract negotiation.

In this instance the customer is not the end-user they are the person paying you to make the game. It could be an investor, the representative of a publisher or your executive producer it doesn’t really matter. What they want is assurance that you’re not full of shit and they’d like this signed, in triplicate, in blood with a firm deadline upfront based on any plan you have. This is a risk mitigation strategy for them and your job is to deftly dodge the contract deadline hammer and convince them to work closely with you on a very regular basis to better mitigate the risks involved in development. However we’ll still need a plan but this is not a plan that can be captured in a contract. It must by necessity be iterated on as development continues and new things are learnt. As we progress towards completing a project our plan will become more certain. It also means that we can early out and still do something else if, despite our best efforts, the project is not meeting expectations. Both parties need to embrace the reality of the uncertainty inherent in the beginning of a project and keep plans vague and the uncertainty in them spelled out clearly.

As the project progresses the plan should be routinely revised and the teams developing the game should be meeting and discussing the game regularly with the customer. At a high level a healthy project should see a downward trend in uncertainty over time. Employing schemes like the development lifecycle can be a good way of tracking progress an deal with uncertainty upfront. In short building the project plan is no different to building the product and the people working on it a virtuous cycle of iteration, feedback and adjustment.

Detailed Estimates Are Still Useful

For teams iteration planning there is nothing better than a old fashioned application of numbers. We want to work at a sustainable pace and the only way to do so is to avoid over-committing to the work we are going to do in an iteration. This is why we should prefer shorter iterations. It’s much easier to estimate and plan one weeks worth of work than it is four weeks and we avoid compound error causing massive deviations in our plan. It’s also much easier to estimate the work we are just about to do because we know a lot more about it than it is to think about the consequences of the consequences of that work in a months time. This is also the point that it makes sense to capture uncertainty in the actual task estimate rather than keeping it as a separate concern. Essentially estimates should be a combination of task size and how sure we are that our size estimate is correct. We then drop tasks into buckets and using recent historical data for the team plus a bit of intuition to bring stories into an iteration such that we don’t over commit to the number of ‘buckets’ we got done before.

In Agile, Game Development , , , , , ,
permalink

“The best thing we did was let people try out ideas, and when we saw [good ideas], grab onto them and hold onto them.”

Drew Murray, Game Director ‘Sunset Overdrive’

Posted on September 4, 2014 In Agile, Game Design, Game Development, Great Quotes, Prototyping
permalink Leave a comment

Agile Game Design Documentation

August 20, 2014 — Leave a comment

In most cases it’s essential to do some design work before you can begin implementation. Typically the artifact coming out of this is some form of documentation about the game or feature to be implemented. In traditional games development this usually involves generating a massive tome explaining every facet of the game in detail. This approach is also a massive waste of time for several reasons:

  • It is necessarily incomplete and as such will require revisions as flaws and unexpected problems are found.
  • It is incredibly hard to maintain due to the volume of material and references between elements, even in a wiki system.
  • Being hard to maintain means it gets out of date quickly and loses coherence.
  • No one will read it as they are generally too big, verbose and dense to be used day to day.
  • It’s completely open to interpretation as it’s a description of something rather than a concrete thing itself.

This sort of documentation does have one use. Theatre for managers and publishers. It provides a nice cozy, false sense of security that everything is fixed, known and contains as few risks as possible. Sadly this is usually deleterious to the actual goal of managing project risk.

Why do we design?

To answer the question of “what should agile design docs should look like?” I first need to step back a stage and question why I design things in the first place. The answer I like best is simplicity, the goal of design is to provide the simplest solution that solves a particular set of criteria well. This is not necessarily the most intuitive solution and therefore it is important to spend some time making sure that I understand the problem before we go ahead and implement a solution.

I value simplicity because it usually provides a solution that is conceptually easy to understand for both the people implementing it and the person using the resulting feature. Simple solutions also tend to be robust as they have a low number of moving parts. Simple solutions are easier to modify later to add more complexity if required. Overly complex solutions can be an absolute nightmare to detangle at a later date.

Why do we document design?

If the simplest solution is not necessarily the most intuitive that means I need to be able to communicate the problem, the solution and the reasoning behind selecting the solution to other people. Usually in the case of design documentation that’s to the people implementing it, even if that person is me. It also means it needs to be easily digestible and relevant only to the current context. This is the great failure of monolithic design documentation.

Making an idea easy to question is also a vital part of communication. The creation of a design artifact is emphatically not a hand-off procedure but one part in a continuing collaboration to create a great product.

Agile Documentation

The main measure of progress in Agile is the state of the working product, for games means a playable game. Design artifacts therefore are not a measurable form of progress in themselves. They are however incredibly useful in moving forward more rapidly towards a working implementation. As such design artifacts must be “Just Barely Good Enough” that is they provide enough detail to start implementation with the expectation that design questions will be answered whilst the implementation is in progress. The level of detail entered into and type of design artifact generated really depends very much on the context of what is being designed. However all design artifacts should generally answer three points.

  • What is the Problem Domain?- What problem is it we are trying to solve? What are the goals we want to achieve by solving this problem? Why is this a problem?
  • What is the Current Best Solution? – A description of the solution adhering to the constraint it must be just enough to begin implementation. This could be anything from a photo of a whiteboard sketch through text documents to a mocked up video or animation. All depending on context.
  • Why? – How does the solution meet the goals and sort out the problem we are trying to solve?

We also need to deal with one more issue. Most products including games are broken down into various smaller chunks for implementation and still need documentation about the project in totality to keep things coherent. Particularly in the early concept stages where different avenues are generally being explored. The good news is that this documentation approach is applicable at that level as well. It’s useful to have a simple, easy to digest and question synopsis of exactly what the game is supposed be and how to achieve it. The trick again is to provide just enough documentation to get started and to answer questions as they come up.

Next up how do you go about creating these design artifacts?

In Agile, Game Design, Game Development , , ,
permalink

A Simple Agile Game Design/Development Process

July 2, 2014 — 3 Comments

Usually when Agile is introduced to people it’s done so with Scrum which is seemingly filled with arcane terms and voodoo ritual. Very often the context behind those rituals and terms is lost and the general advice is to, “do it by the book,” until you understand, before you adapt it. There are a couple of problems with this. Firstly that the context Scrum was developed for might not fit the context you are making games in so rather than enabling you to move faster and make better games you are standing in a corner with your wizard hat on. Secondly Scrum as an introduction obscures some of the elegance behind the Agile Principles, concerned as it is with day-to-day process in service to that elegance.

So let’s cut back to the elegance. In yesterdays post I made a simple re-drafting of the Agile Manifesto to make sense of it for games design/development. Today I’m going to take those re-drafted principles and show how they fit into a simple Agile process.

First a diagram:

simple agile

That’s it. That’s the beating heart of Agile. So simple you can describe it in one sentence. Come up with an idea, make it and try it out to see what it’s like, then use your learning to refactor your idea and processes. So simple it gets repeatedly invented in an intuitive fashion. So simple I can retire this blog forever! Done!

Well not quite, we’ve only managed to deal with a few of the Agile Principles in this loop the rest involve what happens during each stage. Currently we’re hitting:

  • Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • A playable game is the primary measure of progress.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Ideate

We want to keep our ideas lightweight. Over-complicating our ideas too early means wasting a bunch of time both coming up with them and also implementing them. We’ll be refining our ideas over the course of many iterations so starting with a ‘perfect design’ is not going to help particularly as we have not yet managed to evaluate how perfect the design really is! The watch phrase some canny individual coined was “Just Barely Good Enough”.

Ideally we’re keeping these principles in mind:

  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.

Create

Creation is in many ways the ‘easy bit’ where we turn the idea into something playable. The main point to be aware of is that almost every task is going to require some Just-In-Time design. Having whiteboards (or a pad if you’re by yourself) handy is incredibly useful to quickly solve design problems. If you’re creating a videogame then this is also the time to make sure you’re refactoring the code your are working on to keep it simple, elegant and easy to work with. There are lots of ways to make this less painful but that’s outside of the scope of this post.

The principles to keep in mind are the same:

  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.

Evaluate

Evaluation means putting real people in front of your game and have them play it. Ideally you want the audience you intend to release the game to playing it as early as possible (or a close facsimile). At the very least you want some people that aren’t you playing the game to give criticism and feedback. Other developers can be good as they can excuse some of the rough edges of a product in development as well as being able to understand the ruleset and provide critique of the design. If you’re in a company then you’re probably going to have a list of stakeholders responsible for your project who should be playing every iteration and providing feedback. Other excellent although more time consuming methods include using Usability testing methods. For example doing some User Testing, a technique where you watch a players game session and take notes on friction points in the experience.

Schemes like alpha and beta testing, attending games shows, plus funding methods like Early Access also provide a host of willing playtesters. A caveat here is that the quality of the game experience does matter when showing something externally to large groups of people in a manner where there are quality expectations. First impressions count, word of mouth is important and it can be hard to dig a games name out of the toilet if every comment on articles about your game references how rubbish an early version was.

The end result should be a collated list of feedback and some action points to take into the next Ideation phase.

The principles being hit here are:

  • Our highest priority is to satisfy the customer through early and continuous delivery of a quality game experience.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The remainder of the principles deal with things like team composition, team management and day-to-day practices that are effective rather than process. They should be kept in mind at all times.

So why is Scrum so complicated?

Well it turns out as you start to use the above process a whole bunch of questions will routinely come up that need to be answered. Some can be answered by reading the Agile principles but others need a bit of cogitating on the best way to handle them.

For example how long should it take to move through the whole loop? According to the Agile Principles:

Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequently providing a playable game means frequent feedback from stakeholders, playtesters and colleagues. It is the engine of iteration.

So we want to move through the loop pretty quickly, what if our idea is complicated? Well we’re going to have to cut the idea up into chunks we can implement and we’re going to need to work out roughly what order to do them in. But that means we won’t have the “full game” playable for some time? Well we should build a prototype first so we can get early feedback on our complete game design or we won’t worry too much and let the final design fall out in the wash as we receive feedback. Scrum basically provides a ready made solution to a lot of common problems that come up when trying to implement this elegant feedback loop.

Whether you pick an off-the-shelf solution or grow your own from simple beginnings the important thing to remember is that the entire process fails if you don’t keep up the virtuous feedback loop for both the game being made and the processes you use to make it.

In Agile, Game Design, Game Development, Prototyping , , , , , , , , , , , ,
permalink

The Agile Principles of Game Design/Development

July 1, 2014 — 3 Comments

Let’s face it the Agile Manifesto is very Software Engineer focused. I’m not sure it’s meant to be but it’s a consequence of the background of the people that wrote it. The principles also explain what but not really why or how the principles directly interact with the manifesto values. It’s also a bit hard to frame in your own context sometimes. This is a bit of an experiment in re-drafting the principles to make sense for game design/development. I’ll highlight the changes I make in bold. The original Agile Manifesto which can be found here.

First the values themselves:

We are uncovering better ways of developing games by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Playable games over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The first thing to read is the very last sentence. Lots of people read the manifesto and assume that there should be no process and no documentation. The point of the manifesto is that those things are necessary to a degree but should not be the focus as they have a tendency to take over and work against the primary goal of making a particular product.

Why a playable game rather than comprehensive documentation? What about the Design Treatment, the Preliminary Design, the Final Design and all the other ancillary documentation you might produce? The simple fact is that the value of an idea for a game is much better expressed as a game that you can play rather than abstracted into a document. A document is open to interpretation in a manner that an actual demonstrable game isn’t which means that two people can have wildly different ideas about how the end product might turn out without either of them actually being wrong. A design expressed as documentation and a tangible, playable product is there to be critiqued much more directly with far less ambiguity. Further generating comprehensive documentation rather than a product is a big waste of time as we know that we will be making changes as we go along and a big list of things to implement before the game is ‘finished’ often delays critical iteration.

I re-phrased the Agile Principles as:

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of a quality game experience. This provides us with the best and most direct feedback so as to shape out product direction. It also means our game is continuously in a shippable state. The value of a game is captured in the quality of the experience.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Late changes are a reality of the business.
  3. Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequently providing a playable game means frequent feedback from stakeholders, playtesters and colleagues. It is the engine of iteration.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Autonomy, mastery and purpose are the key motivators.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. A playable game is the primary measure of progress. We are making a game, if the game is not changing we are not working on it. A feature designed on paper is not a feature that is playable.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The principles were not originally numbered but I’ve done so to keep the discussion brief, it’s not a statement on which of the principles are more important than the others. Never the less there are a few of the principles that are good to call out in groups.

  • Process Improvement: Twelve represents the engine of process improvement within the agile framework, it’s taking an iterative and evidence based approach to improving the working practices of a team with the rest of the principles representing the yardstick by which to measure them.
  • Game Improvement: Seven details the key indicator of progress. The state of the game itself. Combined with Three and One it provides the engine for evaluating and iterating on the game.
  • The Team: Five and Eleven detail who the team is and how they should be managed.
  • Mindset: Eight, Nine and Ten frame the mindset required to work with an agile process with One as the goal.
  • Working Practices: Two, Four and Six detail important working practices that are part of the reality of working on commercial products with many people.

The entire point of the Agile Manifesto is to define a new way of working that is customer focused, iterative and concentrates on making the best product possible by empowering the people that make it. Hopefully this re-write clarifies how this approach fits game design/development and gives people a good starting point for defining their own processes.

In Agile, Game Design, Game Development , , , , , , , ,
permalink

“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

The basic idea…

Posted on June 16, 2014 In Agile, Game Development, Great Quotes, Prototyping
permalink Leave a comment

Go Wide, But Love Constraints!

April 16, 2014 — Leave a comment

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.

In Agile, Game Development, Prototyping , , ,
permalink

The Case for Specialisation

March 19, 2014 — Leave a comment

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 Agile, Game Development
permalink

Cross-Functional People

March 13, 2014 — 3 Comments

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.

In Agile, Game Development
permalink