Fo-what?!

I think the best way to explain the true essence of focus is to quote Steve Jobs:

    It’s very important to understand this in abstract terms, philosophically, as it may become easier to understand the pattern and the flow of processes that channel through this issue.

    Being able to focus is actually one of the most challenging things to do because there are a lot of temptations along the way to lose focus. Failing to focus and follow the plan by adding new features is called Scope Creep and is one of the most dreaded things that can happen during the development cycle. Nearly every studio in the world does this or has done it at some point one way or another. This process is very destructive for the following reasons:

Who cares?

    So how exactly is it destructive? How does the scope change contribute to these problems?

      Team velocity is a very subtle and tricky subject. This is the speed by which you/your team executes the plan or any part of the plan. This is the first priority metric that helps you assess if you follow the plan. It’s how many tasks do you successfully execute per period of time, for example, a week, or a day. So, what’s so tricky about it? Everybody knows of its existence, few know of its importance, and even fewer know how it’s not the best indicator and advisor. Because no task is like any other. Also, the change of scope is invisible in this sense. Team Velocity is at its best when the team follows a plan without any or next to no changes to the plan/environment. Whenever the team knows what’s next beforehand - they can execute the task better, and if it’s a part of a recurring process, and not a unique task, even better. Any kind of disruption during the development is very destructive and temporarily impairs the team. This “plan” is a product of vision. Whenever the team knows what’s next, they are always able to prepare and take the hit.

    Crunch - The dreaded situation, when all team endeavors escalate to a point where it’s impossible to sustain a work/life balance. Scope Creep inevitably generates Crunch. Besides the obvious reasons that we cover in this article, It’s also because on a tactical level there is much more work that has to be done as a product of scope change than is projected on a strategic level, by a mile, to say the least. It involves immense amounts of work that the team blatantly agrees to do. Crunch is devastating, as not only everyone deserves to rest, but everyone needs rest. Ultimately undermining all the creative potential of the team crunch is one of the worst things that can happen.

    Team Morale is another important thing and is very fragile. Poor management can devastate even the most enthusiastic, creative, opportunistic, and competent teams in the world. Scope Creep means unpredicted change with a high chance of jeopardizing the plan and directly contributes to morale drops. There are many psychological reasons for that, but the most important is that people don’t like to be on a rocky trip while being blindfolded. Another one is that people want to have a competent leader who knows what he’s doing. This is why transparency and communication is also important. Any kind of unpredicted change most probably involves scrapping major chunks of the team’s work, and that is also a very negative experience, although it happens very often, for other reasons too.

    Uncalculated Dependencies: Whenever you add or change something to a semi-developed system, you have to be very careful with what happens to the rest of your work, as you might break all hell loose by changing a system that is interwoven with other elements/systems for a short-term or ill-calculated change. This is something that is inevitable when you set out to change something in a complex system, but the degree of it is what matters.

    Budget Inflation is a direct product of labor mismanagement; Uncalculated Dependencies impact some parts of your product that have been already developed, and now they have to be redone, sometimes taking much more time than it took initially, as navigating in a complex system is extremely difficult, something software engineers know extremely well. A more trivial example is when you increase the scope of the product, assuming that it is possible to execute in the same budget as initially calculated, which is, of course, an ill-informed assumption, to say the least.

    Product/Game Vision is, in my opinion, the root of the problem which feeds itself when mishandled. If you have a clear vision of what you are going to do, then you also have a clear vision of how you are going to do it, in most cases. Whenever the vision is not firm or clear enough, that’s when everything starts to go downwards. You start to add things to compensate and end up undermining the game vision even more as you continue the same way down the road. This triggers a chain reaction which is the reason we explore this topic.

    Missed Deadlines are missed projects. A project is a temporary endeavor, in order to generate a product or meet a goal in a set time period. Whenever this time period starts to slip away, the project slips away too. Scope Creep triggers a chain reaction that leads to this, and in most cases gets you into a loop, a vortex of endless delays, reschedules, re-budgeting, etc., to a point where it consumes all resources and shuts down.

But, why?

    So, all of us have encountered this if we’ve made at least one project. But, it’s not obvious what brings us there, what undermines the benevolent force that pushes the projects forward and prevents us from finishing them on time, on budget, what triggers Scope Creep. In the previous episode, I’ve talked about what you can do to set up the project’s scope so that it has better chances of being delivered and is best fortified against Scope Creep. But it’s more important not to drift away from that, as you may set a scope properly, and ruin it during the development. So, what powers Scope Creep?

    Poorly Defined Scope is what I’ve talked about and shared some insight on how to counter that in the previous episode. It’s important to start from a proper point with a clear scope. You can always come back to this stage if you have the time and the budget to do so. Redefining Scope is an extremely risky and responsible action. Sometimes it’s something that saves the project from certain doom, and most of the time - it’s something that brings it there. As I’ve said, it’s important to understand what is in the scope, but it’s more important to understand what is NOT. This is more important as it gives you explicit red flags for what’s an unacceptable development of events. If you have defined the scope of the game not to have an X feature, whenever you try to add something X or resembling X, you and your team members have better chances to identify a trap. If you don’t have this set up before going into development, nobody can stop you from adding something that doesn’t belong, because you have no agreements on what belongs and what doesn’t.

    The features themselves have to be defined to the best of your ability and knowledge. Ideally, you've developed a prototype with the given features, and now you know exactly what it is going to be for your next iteration. You need to know what’s the feature you’re working on. 

    When a feature is abstract and not defined, you can’t tell if you’ve made it or not when you assume you’ve finished the work. Besides, you might not be able to have a clear idea of where to start in the first place. This already means you couldn’t define a schedule and a budget for it, most certainly. But not defining a feature, and not defining it well enough are different situations. The latter is when you’ve most probably been tricked into assuming that you’ve measured, budgeted and estimated a feature, and most importantly, delivered it. That’s why pre-production is very important as you have more chances to precisely define a feature and then make the plan for the development of that feature.

    Ok, so the Development Plan is the plan for how you are going to implement a feature. It is the path between point A & point B. A development plan is much like wandering in a forest; you need reference points to triangulate your location to understand if you’re going in the right direction. Whenever you don’t know what you’re going to find during the journey, it’s much more probable you won’t get to your destination.

    The Development Plan is also very important because when you have a decent one, you are much more effective in protecting yourself from mediation along the way. Whenever you feel lost you can always go back to the previous checkpoint and debug what went wrong and what to do next. When you don’t have one, or it’s severely weak, you wander around in search of the golden fleece, even though you might know exactly what it looks like. Investing enough time into planning the development in pre-production has a great impact on the final deadline, also. Wandering around generates uncertainty, even towards things that are truthful and well-defined, so it’s very dangerous to walk around without a map. Any action that doesn’t belong to the plan is easier to identify when you have a guide, and it is easier to seize unnecessary deviation.

    Professional game development is a business, and involves money, one way or another. And inevitably we are in the same Market, maybe in a sub-market, but it’s all interwoven. One industry impacts the other, and creates a chain reaction, or a “butterfly effect”, if it’s a more convenient term. The modern market is extremely rapid, and changes occur on a daily basis. An immense amount of competition rages for the love of the crowd, and we are in the midst of it all. Whenever a big change occurs, the environment changes, and the market adapts accordingly. Adaptation demands mobility, quick wit and vision.

    But not all have the chance to adapt, as we, most probably, already utilize all of our potential, energy, focus, and attention. Deep analysis and a business acumen might provide a better chance of predicting market change, but it’s not a guarantee by any means. Even though you might have an idea where things go, you might not have the confidence, the resources, and energy to outmaneuver the change. This is one of the things that are in some way beyond our control, as big sharks create the biggest waves in the aquarium. This is when we all start to waver, and panic fills our minds and impacts our decision-making process. The only remedy in these kinds of situations is to have a clear vision of your product/game. That’s important because then you understand what’s the target you aim for, and in case the target moves, you know what it looks like.

    Before we get to the solutions, I want to talk about a very important topic - Scope Change Management. I don’t want to convey a wrong point of view that any change is bad. Some of the biggest and best hits involved big changes at some point. It’s not about not making a change, it’s about managing change. It’s all about responsibly dealing with change and adapting accordingly, be it changing scope, delaying a deadline, or any other change to the initial plan. What is important is that this is an advanced topic, and you should pay immense amounts of attention and a responsible attitude towards this. 

    Turning any change down is also destructive: any action that is directed towards you and/or your team reaching the goal, or following the vision, is a correct action. It’s not about being firm with the means to reach a goal, it’s about being firm in adherence to reaching the goal.

    Scope Change Management is a toolset that you have to have to handle change. This has to generate a process that enables flexible decision-making on the basis of pre-defined, or continuously defined metrics that serve to assess if the change is necessary to reach the end goal. This is a funnel that tests if the proposed change is worthwhile and optimal. These metrics are different, depending on a game project and are aligned with the vision and the business goals. These goals have to be enforced, but the path to them has to be flexible. Having a protocol on what to do in many different situations is what constitutes Scope Change Management, this is what keeps the creative storm at bay, and provides you with a better chance to reach the set goals. Learn to agree & disagree on change, debate on change with visible and independent metrics, learn to request change approval from a higher manager, learn to propagate that decision so that the team doesn’t feel swamped.

    Ok, let’s face the endboss.

Counterpunch

    Situation I: You’re not guilty, it just fell.

    Now, the initial scope planning was done to the best of your knowledge, it’s a bar you’ve set. Hence, you have to hold it there, and not let it fall. Just the moment you start the development, all hell breaks loose. You start to deviate from the plan, add something to the roadmap, lose focus, etc. Well, we have to defend the scope.

Step I: Just don’t do it.

You add new features along the way mostly, because:

    The first one is the most common one, and it happens to all of us. What we need to understand is that even a single line of code, or a simple shader, or a little part of the map, or a little feature has cost. And, you’ve already allocated a timeframe, a budget to do all the rest, now you’re trying to smuggle a little feature in. You have to understand that you’re bound by time and by resources. And it’s just math. You can’t fit 7liters into a 4-liter canister. It’s extremely simple, but it is what it is. And, it might be simple, but it’s by far not easy. If you do understand all of this, the only way you can let a small, tiny feature smuggle in, is by being off-guard.

    What I did with my team is, obviously, defined what our game is not about, and what we are not going to do. We wrote it down, and we all adhered to it. But, how do we cope with scope creep on a daily basis? Controlling the creative storm is one solution I was able to implement: whenever we had a new idea (and we had a lot, constantly, just like you do) we wrote it down and delayed the decision to a moment where we weren’t so emotional about them. And it worked as a charm. The general abstraction is: I try to create a lot of bureaucracy around these decisions so that I can filter the brilliant ideas from momentary, exciting ones.

Example:

- I saw a movie yesterday and I know our game needs this new feature. <…> explanation… <...>, argumentation… <...>, how it is just THE idea that will make the game exciting…, So, what do you guys think?

- Okay, that’s an awesome idea, but let’s talk about it next week at a meeting and decide what’s gonna happen with that.

    So, what’s so important about this? We never say no, we just say, there’s this law, that we all agreed to follow, and if this idea passes the filter, we will do it.

    What happens at this meeting, which is called Scope Adjustment Meeting is we have a list of some ideas and changes to the scope, that we have to talk about and try to test them with every tool we have at our disposal. If this idea survives the test and is justified, we do add it. But that happens extremely rarely, as most of the ideas seem awesome, and if they’re actually awesome, they seem fitting, and if they really fit, they seem executable in the timeframe we have. If the idea is actually extremely awesome, fits there and is creative*, we do work an hour a day more, but: