Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
A Problem Solution: Standardized Work
Using standardized work to prevent recurring issues.
5 Min Read
In software engineering, there's something called test-driven development (TDD). In TDD, unit tests are often used to control the recurrance of bugs or to ensure the functionality of a system after a change has been introduced (regression testing).
TDD is very important for extreme programming and used in many agile toolboxes. I'm not going to spend this post touting TDD, however. Instead, I'd like to ask: how do we prevent issues from reoccuring within our organizations?
Often times, physical historians are relied upon as a means of inhibiting repeated mistakes. Basically, your team or team members have some recollection of what has been tried before and what has gone wrong. The understanding, training, and skill of these individuals is relied upon. This is a very common practice within many software organizations.
Taking a step back, let's look at where this system has been found wanting:
Rock climbing - often times, the simplest activities (abseiling) are the most dangerous. Why? Well, at the end of a long climb, it's easy to skip steps or consider something so simple that little attention is paid as the act occurs. One of the most frequent causes of climber death is rapelling off the end of a rope. As a standard fix, my climbing partners and I always tie knots in the ends of our ropes before abseiling. We always ensure the other climber has checked the rope to guarantee the knot exists before beginning our descent.
Piloting - an airplane taking off from a runway can look beautiful; but, it's rife with dangers. There are many systems that must function for a plane to successfully fly without incident. How have these complex systems been managed? By the pilot's memory? Certainly not. Rather, check lists are used.
Hospitals - A recent development in several hospitals and one that has been greatly supported by the Lean movement in healthcare are check lists for various routine procedures. The results speak for themselves.
Those are three easy to identify examples. I'm sure you can come up with more if you look in your everyday life.
Maybe some measures have been enacted within your organization to move from a memory-retention model to a document based approach:
The Internal Wiki - often times, we use wikis as repositories of data. When it comes to Wikipedia, it's a wonderful source of information. As for internal wikis? Well, maybe you've had a good experience with them; however, my own experiences within organizations is that articles become stale by the time they're finished and are too infrequently updated to be useful.
The Large Document - many companies provide documents detailing standards or practices. These can, often times, run dozens of pages in length. Sadly, when presented with such a difficult foe, more individuals will, more often than not, glance over the document. This is frequently the case with company/employee handbooks.
These provide a history of what has occurred, but may not provide solutions. Indeed, in game development we frequently use post mortems as a means of figuring out what went wrong. Do your post mortems end with action items? Or do teams break up and rely on their wet-ware (brains) to retain the information and apply it appropriately?
Standardized Work
So, I've identified what may be a problem in some or many game organizations, software development houses, etc. What're some solutions? I'm sure there are multiple. The one I'm most fond of comes from Lean and Toyota.
When a problem occurs, what do you do? Scramble to provide a patch? If E3 were tomorrow, and you had a horrible bug, that's probably what you'd do, right? What about afterwards? Would you look for the root cause? Solve the real issue? Sure!
Take that to your view of a company, now.
The five rules of Gemba are:
When an issue arises, go to the area it occurred first
Check what's faulty, where the problem is, etc.
Fix the problem on the spot temporarily
Discern the root cause (5 why's)
Standardized to kill it there and never have to solve the problem again
That last bit is the element we're mostly missing. We often solve the problem at that instant, and then promptly forget it ever occurred.
What is Standardized Work?
As with the check lists, it's a simple method of ensuring that procedures are followed. These can be as mundane as a collection of check boxes that guarantee certain questions are asked or as complex as outlines used to indicate where certain items are stored.
Standardized work isn't your boss telling you to fill out a report or to extend his/her control fetish. Rather, it's something agreed upon by the individuals performing the work. It is an extension of the worker's ability to generate quality.
Standardized work isn't arbitrary.
Well, I just wanted to provide a taste of the problems and potential solutions and to get your brains churning. Hopefully this has helped. I highly suggest checking out LeanBlog and various other blogs for more specific dialogues on these topics. With any luck, I'll soon have more time to blog less introductory topics and delve into deeper implementations.
Have you seen standard work implemented in game development? What has worked? What hasn't worked?
About the Author
Andrew Andreas Grapsas is a game programmer at Arkadium, Inc. developing facebook games. Previously, he was a gameplay and animations programmer at Kaos Studios|THQ, and intern systems programmer on Medal of Honor.
Andrew is actively writing and programming for various projects. You can read more at his blog aagrapsas.com. He promises to update it soon.
About the Author(s)
You May Also Like
