Fuller Game Production

After leaving Raven earlier this year I took stock of my position in the industry. With 13 years of development experience and more than a dozen AAA products to my credit I knew I could add value to any number of organizations. But I wanted more than to be tied to one project at one studio for years at a time.

My greatest fulfillment as a developer has come from helping teams succeed. Maybe that sounds trite, but it's absolutely the truth -- I genuinely enjoy helping others. After much deliberation I came to the conclusion that the best way I could help the most developers was to go into independent consulting as a producer-for-hire, improving processes and filling in the production gaps for studios of any size, in any location.

I don't just want my current project to be well-managed. I want everyone to create a fun game that comes out on time, without overtime.
And with that end in mind, I present to you: Fuller Game Production

 Creating a video game is hard. I can make it easier.

When You Get A Chance, Recognize Excellent Service

I had a surprisingly good piece of customer service from a gate agent at SFO a few weeks ago. My flight was canceled and this agent worked with a few other folks to reroute dozens of severely irritated passengers. This gentleman in particular hustled his butt off and remained calm, professional, and courteous to the very last passenger.

So I told the agent's manager and sent an email to delta.com support. Apparently, it resulted in some sort of recognition for the chap. I couldn't be happier. People in service industries frequently get pooped on and, I suspect, rarely receive appreciation.

Here's the message for you, gentle reader...
Try to notice when someone does an excellent job on your behalf...and show some recognition. Chances are, they don't get nearly enough.

And CS... keep 'em flying.



---------- Forwarded message ----------

From: S*****, C*****
Date: Thu, Dec 2, 2010 at 1:20 PM
Subject: It's Appreciated! Delta Airlines observation November 6th, 2010
To: "keithfuller01@gmail.com" keithfuller01@gmail.com

Good afternoon Mr.. Fuller. I wanted to take a moment to personally thank you for personally giving the great feedback on the day I met you to my supervisor Gary and you went above and beyond and sent a personal email. I want you to know that it did not go unnoticed and I indeed got rewarded for it.

Whenever I receive positive feedback it's best appreciated when it's unsolicited ;-). It makes me feel that a "guest" really took the time to personalize it.

I hope that your holiday season is going great and I wanted to THANK YOU for acknowledging me. Enjoy the rest of your week!


C***** S*****
Delta Airlines
San Francisco
Gate/Ticket Agent

3 Things to Know About Smaller User Stories

Yesterday I attended a webinar by Mark Levison (graciously hosted by Donna Reed) about slicing user stories -- why to make them smaller, how to make them smaller, how small to make them, etc. Here are some of the points I took away.

Why Make Stories Smaller?

It's easier to estimate the work involved and easier to grasp the details. Further, when (possibly if, but probably when) you get partway through and start to realize how far off your original estimate was, you haven't spent as much time working on something that your product owner will pull the plug on after discovering how long it will take.

How Do You Make Them Smaller?

Mark had an entire page of possibilities so I won't get into enumerating them, but one of the driving thoughts here in breaking down the story size is that -- once decomposed -- you want to still be tackling a story that adds value to the project. You can find any number of ways to reduce story size, but make sure the resulting stories each add value.

How Small Do You Make Them?

The guideline Mark gives a team just starting off with Agile is to make sure stories are big enough that they take a couple of people a couple of days. If it's smaller than that it's really a task, not a story. (As an aside, he also pointed out that there's nothing carved in stone anywhere that says you have to use tasks when running an Agile project -- maybe that's something to bring up with your team.) So keep the story/task distinction in mind and don't break down anything too much.

My Thoughts

My assessment of Mark's webinar is that he gave a great, in-depth discussion on story size. It was accessible to beginners, but he answered some write-in questions that were more advanced in nature. Mark clearly has real-world experience in this realm and does a good job of clarifying the material. The idea of decomposing stories into reasonable size is applicable for game development, to be sure, so although Mr. Levison's talk was geared toward "standard" project development I'd still recommend this content for developers in the games industry.