The producer dilemma

Every attempt at fixing the process typically gets butchered when you approach that tough deadline. The good practices you have been building up does not work in this situation and you have to retort to basic brute force solutions. When the delivery is completed you are back at square one and have to start rebuilding the process again.

Working at a studio with publisher financed productions you are typically very dependent of every milestone payment. Since this has the highest priority, a successful delivery will always be more important that a long term improvement of the process.

To add to this, a producer at a small to medium size studio is typically responsible for both result and process with no one holding him/her accountable for lack of process improvement.

The solution to this should be quite simple, hire someone who's main responsibility is to own and make sure that the decided process is followed and that improvements are implemented (not found, that is everyone's responsibility). In agile terms a SCRUM master for the whole organization.

In my experience the cut throat competition and shortage of resources in most game productions makes it really hard to justify the hire of the process owner. When your choice is between adding that brilliant programmer that will make the game look so much better and that boring process guy it will almost always be the programmer. I believe the reason for this is quite simple, a programmer will start producing tangible results (results again) rapidly. A process owner would not produce results rapidly nor will they be very tangible. 

But let's assume that we make that hire in a team with about 50 people. Simple math says that if each team member works 2% smarter the hire is equal to the programmer hire. If you can beat 2% improvement of team efficiency (I hate that word as it has a lot of negative connotations, suggestions for better words to describe this are appreciated) it is a better hire. Naively I believe that improving 2% is quite easy if you have a good understanding for how game development works. 

For the organization SCRUM master role to function correctly that person should have no responsibility for results nor quality. He or she should only make sure that the rule set decided by the team are followed and coach the sub team SCRUM masters to find and help facilitate improvement implementations. 

Any organization, agile, semi-agile or something else would benefit from this role. As long as you can define the way you work it is reasonable to have someone that makes sure that you follow those rules and also finds ways to improve.

Because of the dilemma that results always wins over improvement I felt that I needed to leave the production role. I needed some space so that I could reflect upon the mistakes I've done and hopefully come up with solutions to some of them. Hansoft provided with me with an excellent opportunity to do this with the added benefit that I can hopefully help others to avoid my mistakes (though they are OK).

Lesson learned

The constant hunt for short term gains will prevent you from improving. It's important to find the balance between results and improvements.