Tuesday, December 14, 2010

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.

Thursday, December 2, 2010

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.

Monday, November 29, 2010

My thoughts on daily standup meetings

Clint posted a great blog entry recently on daily standups in Scrum. I thought I'd add some of my own thoughts on the topic.

 
To anyone who hasn't been doing these, the term “daily standup” probably sounds like one of those dang Agile Terms. Or worse yet, a Scrum Term. To be fair, it is. But it doesn't have to be. There's no reason for any such connotations of methodology.

 
Don't get me wrong. I'm an unabashed advocate of Agile practices. But in many companies there's still a sense of newfangledness associated with Scrum. For those in such an organization, I'm here to tell you that daily standup meetings are incredibly valuable and can certainly be methodologically agnostic.

 
I've introduced standups to teams using the following points:
  • I want to know what's holding you up each day so I can address it quickly
  • I don't want to waste your time so the meetings will be short – discussions can be held separately
  • We'll meet as a team so everyone can keep tabs on the project as a whole
Notice there's no mention of Scrum, Agile, or any other label. I've found that laying out the purpose and format of the daily meetings in this way assuages many fears and misgivings such as You-Don't-Have-To-Check-Up-On-Me-Every-Day-You-Nazi, Meetings-Are-A-Waste-Of-Time, etc.

 
After we first get together I might introduce the idea of answering The Three Questions. To be sure, it's ideal if you're with a highly empowered team that only requires the facilitation of a Scrum master here. But in non-Scrum settings it's not the end of the world if you still have to lead the group by asking the questions yourself. In my opinion it's more important to get the information out there and hear each team member contribute to the data flow than to get hung up on enforcing the ideals of Scrum.

 
A bonus for you, the manager, is that you get a chance every day to work on your soft skills. There will likely be a spectrum of personalities present in your daily standup and not everyone will be outgoing and easy to work with. You'll probably have this guy in your group:

 
You: “Emil, what are you going to do today?”
Emil: “Bugs.”

 
This is your chance to improve your own communication abilities. Make sure you're picking up on who's more talkative and who isn't. See what you can do to form bonds and occasionally cajole a lengthier response out of ol' Emil. If you learn more about him and address some of his recent accomplishments (“Thanks for implementing the classic controller layout so quickly.”) you might eventually get a two-word reply.

The bottom line is that daily Scrum standups are a great thing when they are driven by an empowered team – the people are focused on the task at hand, they care about the group's progress, and you barely have to do anything as Scrum master to get the necessary communication flowing. But even if you aren't in an Agile setting, you can still easily implement daily meetings that encourage teamwork, improve communication, and provide you, the manager, with the transparency you need to track the team's progress.

Friday, November 19, 2010

New Wolf Diary entry -- Tuesday, November 28th

I hadn't really thought this through when I started resurrecting these diary entries, but now that the entry dates are almost aligned with the current date I'm starting to get a little confused. I can only imagine how befuddling that must be for you, the returning blog visitor. Or even you, the intrepid first time reader*.

So to be clear, the title of this post ("blah blah blah November 28th") refers to November 28th, 2006 -- the date on which I originally wrote the diary page in question.

It's funny to think of how the landscape of the industry has changed in just four years. Notice some of the names in the latest diary entry. Quake Wars was still in production. Z-Axis wasn't Activision Foster City or Underground or...um, nonexistent. id was a major player. Or possibly even a playah. Hard to say. I've never been the most appropriate person to make that distinction. Point being, things change. A lot. In subjectively little time. And with that, I've managed to make a seemingly profound observation that's really just a paraphrase of 2000-year-old Socratic thought. Way to go, me.

*according to this blog's Stats page, this is actually a rather small demographic. Size of 1, in fact. Here's looking at you, xxx.xx.xx.255 of Ottumwa, Iowa.

Wednesday, November 17, 2010

Last night's IGDA-Wisconsin chapter meeting!

I had a great time chatting with folks before and after the meeting, especially Jeff Spurgat, a programmer with whom I worked at Evermore Entertainment about 12 years ago! (We both did a, "Wow, has it been that long?" :)

The Raven chaps were predictably excellent hosts and it was good to see such a large turn out. We filled the main conference room then brought in 20 extra chairs and still had people out in the lobby.

While I enjoyed hearing Rob Martyn's assessment of the state of the games industry, I found John Bergman's talk to be most intriguing. He spoke on Guild Software's ongoing Android development for Vendetta Online, which is Guild's MMO title. Some of the points I took away from his presentation:

  • While the hardware is similar to iOS platforms, there are more bundling opportunities with Android
  • Tough to design UI for touch-based devices
  • Likes Tegra as a development target, mainly due to NVIDIA's history of working with game developers
  • Sees the mobile development war heating up in mid-2011

It turns out Guild Software is based in Milwaukee, apparently not too far from the hovel I rented while attending UWM. Keep an eye on Mr. Bergman and his crew. Thanks for the great presentation, John!

Tuesday, November 16, 2010