Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 4, 2020
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

A Problem Solution: Standardized Work

by Andrew Grapsas on 03/18/11 02:26:00 pm   Expert Blogs   Featured Blogs

8 comments Share on Twitter    RSS

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.

 

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:

  1. When an issue arises, go to the area it occurred first
  2. Check what's faulty, where the problem is, etc.
  3. Fix the problem on the spot temporarily
  4. Discern the root cause (5 why's)
  5. 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.

Follow Andrew on twitter!


Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[08.02.20]

Experienced Game Developer
Plarium Michigan Studio LP
Plarium Michigan Studio LP — San Mateo, California, United States
[07.31.20]

UX Designer





Loading Comments

loader image