The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

Every project hits snags. Every game has its production pitfalls. Sometimes it is the mechanics that just suck out time and energy from people while ultimately contributing nothing to the game. We've all been there. You can plan and plan for a thousand years but inevitably something will go wrong and you will have to change those plans to keep your schedule. Currently I am facing a similar situation. Something very simple that good old retrospect tells me should have been an obvious trouble, but I let it happen none the less.

Up until now I have been working with an agile development plan. Basically that means my programmer,artist, and designer will all make things as we go. The designer will design a mechanic, the programmer will program a prototype, and the artist will make the assets. This is a good framework for iteration on the fly and can make production speed as well as amount. The major issue with agile development is that it relies entirely on the productivity of every member. If one member of the team gets hung up on a problem then the rest of the team is forced to wait until they catch up or leave them behind with a largebacklog of things to do. Such a scenario is currently happening as I write this. Of course we could all wait for everyone to catch up to the group but that could cause more issues then it would solve.

So what is the solution to this? How can you keep up productivity and hit deadlines while not overworking your team and making enemies for life? The answer I've come to is that you have to plan for change. You have to be able to jump from an agile development to a lean development when workstarts to pile up. With a more confident team I'm sure that you can keep a lean production going but when using an untested team a great way to keep people working is to swap over from agile to leanwhen things start to fall behind. This by no way is a 'proper' way to make a game but it worked as a great way for my team to keep up production and keep moving towards a goal.

Our team is now changing the development method to a more rigid structure that is less accommodating to change but more streamlined for faster and more productive team members. Since everyone has a goal and can keep to a schedule we can make sure we can hit deadlines. When everyone is caught up we can change back to agile development in order to get our game some more iteration and make the player experience more enjoyable.