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.
meheleventyone 