Search

Wednesday, October 18, 2017

Agile game development training course is now free

The "Agile Game Gems" video training course is now available for free.

This 48-minute course is a useful resource to introduce and refresh game developers on the purpose and vocabulary of agile game development.

I will be using this course to prepare students for my training cso we can better hit the ground running on adopting and improving agile. 

Links for the course's reference material are linked to in the video's description.

Tuesday, August 15, 2017

Mobile Game Lesson - Rapidly Responding to Change


I’m slightly embarrassed to admit that the mobile game I play the most is Solitaire.  Solitaire is a great game to play when you are waiting to board an airplane or when trying to fall asleep in a hotel.  I do both of those things quite often.

The first mobile Solitaire game I played had great graphics and some good features.  It also did a few things that annoyed me such as having slow animations when “undoing” moves and not having a feature that quickly completed the hand once all cards were exposed (a Solitaire hand is "solved" once all cards are face up),

Then one day, after Apple upgraded iOS, the game just kept crashing on startup.  This kept up for a few days.  Because I was traveling that week, I was having some serious withdrawals.  So I ended up trying a few competitive Solitaire games and finding one that not only worked with the latest iOS, but also had fast undo animations and the autocomplete feature.  I ended up buying that game and never going back.

By chance, I ended later ended up working with the studio that made the original game and was able to meet the small team that was supporting it.

It turns out that the team were unaware of how the market perceived this very profitable game of theirs or what the competition was doing.  Part of the problem was having a very deep feature development pipeline that didn't respond to change very well.

It was an eye-opening experience that such a simple game could suffer from the problems that larger games could as well.  The mobile game market can be very fickle.  Crashes, exploits or the emergence of a similar game doing something better can change you market overnight.  You need to be able to have some bandwidth set aside to deal with them.  Plan on change!

Thursday, July 13, 2017

Why a "Scrum for Video Game Development" Course?

What areas does a Scrum for Video Game Development course cover that others don't?

Plenty. Video game development has unique challenges that other industries do not.  For example, death-march-crunches are harder to avoid.  Mainstream app development can manage crunch by managing technical debt and scope.  Video game development has more varieties of debt (art, tech, design, content production) that have to be managed differently. We cannot just cut content production for schedule reasons and ship four hours of single-player gameplay to meet a schedule. This requires a different approach.

We discuss this and many other game-development-unique approaches in my interactive workshops.  I invite you to bring your questions or challenges to discuss. We'll share what many studios have discovered through experimentation and practices that were captured in my more recent book: Gear up! Advanced Game Development Practices.


Typical areas of discussion include:
Come join the next Scrum for Video Game Development course and bring your questions and experience.


Wednesday, June 21, 2017

Sprints or a Kanban?

There seems to be some confusion that using Sprints or a Kanban is a competition of sorts with "one being better than the other".  Might as well argue whether a hammer is better than a saw.  Anytime someone gives a blanket statement that "one is better than the other" it means they misunderstands both.

Sprints are more suitable to complex problems that a cross-discipline team will swarm on to solve.  Complex work has "unknown unknowns" that require experimentation and defy planning and estimation.  The time-box is a limit of time that is established to touch base with the business side and to replan our next move on a complex mechanic.

A Kanban, a way to visualize a lean flow, is used for complicated work.  Complicated work has "known unknowns", like creating levels and characters for a game with established mechanics.  The variations are manageable. It is more predictable and uses hand-offs of work through a flow.

Using Sprints to manage complicated work results in batched work and an artificial division through sprint planning and review. It hides discipline inefficiencies and leads to split stores which create no value individually. Imagine the cost of buying a house if every one was a custom concept home built by a guild of craftspeople.

Using a Kanban to manage complex work results in turbulent flow that either creates inefficiencies and a lack of transparency or artificial deadlines to call things "done" when they really aren't.  Kanban doesn't handle the back-and-forth of exploration very well. This creates debt and can limit the creative potential of a game. It's why we don't use an assembly line to design a new car.

I often see Kanban used for complex work because there is still an "upfront planning" mindset that thinks a new uncertain game mechanic can be broken down into bite-sized discipline centric steps and pushed though the teams. Sprints are abandoned because the developers cannot be trusted to take larger goals and break down the work as they see fit.

Choose the best tool for the work.  Wielding a hammer with great skill to cut long pieces of wood into smaller ones isn't as useful as using a saw.

Saturday, June 10, 2017

Department Silos Can Kill

In 2002, GM engineers discovered that the ignition switches on some low-cost cars had understrength  springs.  As a result, a heavy keychain or knee-bump could switch the ignition for those cars off.

It was considered a rare occurrence and not exceptionally dangerous.

Before the defected part was recalled in 2014, it was blamed for over 120 deaths.  Many of those who had died were young; parents had bought the low-cost cars for their children, considering them safe.

The systemic reason for GM ignoring the severity of the problem was that the engineers who designed the ignition switch were not familiar with how the ignition switch impacted other components of the vehicle. They weren't aware that switching off the ignition disabled the power steering and airbag deployment circuits.  Disabling power steering and airbag deployment was a deadly combination.

Unintended component interaction is why I discourage the creation of most component teams.  Graphics teams, physics teams, audio teams, etc. all sound efficient and they are efficient in creating graphics, physics and audio systems, but the cost of late integration and the emergent systemic problems is too great.

Players want games, not components, but at least our mistakes don't kill them.

Wednesday, June 07, 2017

It's not about open space vs. offices

There's an endless debate about what office configuration is best.  After working with hundreds of teams over the past decade as a coach, I have the answer:

There isn't a best configuration.

The debate should be about how we can improve effectiveness as a team.  We need to communicate quickly, across disciplines and also get into the flow of our work.

Think of a team having a nervous system.  To much noise can be like a convulsion.  To little communication can be like paralysis.

Experiment.  Explore.  Regularly decide as a team how you can improve your effectiveness by tweaking your space.

Saturday, June 03, 2017

Fighter Aircraft and AAA Games

When I worked on fighter aircraft, I witnessed the harm that a lack of communication caused.  The shining example was the F-22, which had contractors in over 30 states working (to spread congressional support) with classified protection in place.  If I wanted to speak with an engineer who wrote the firmware for a board I was working on, there was a week's delay in arranging the call on a scrambled phone line with a security officer present to ensure we spoke about nothing too specific.

That was a joy.  It's no wonder the F-22, which was so late and expensive to build and maintain, was cancelled after a small fraction planned were built.

Fast forward 30 years and I'm working with a publisher on a large franchise game that has six studios and hundreds of developers working on the next iteration.  There are language and time-zone barriers, and most of the studios are organized by discipline silos that have limited communication locally.  Because it's a billion dollar franchise there are armies of project managers pumping out reams of documents that lay out a clockwork plan, defined to the hour level, about how the project will be executed.

It's the same as previous iterations, where the plan eventually fails to execute and a lengthy period of crunch and feature compromise is hit at the end.  Just like the F-22.

Large games and government projects can work.  They require breaking down silos and educating everyone about the entire system, not just their part.  We want to, as General Stanley McChrystal puts it, "fuze generalized awareness with specialized expertise".  We want hundred of people making the right decisions for the whole, rather than relying on just a few.

Agile can help, but too many times we see cross-functional swarming teams formed under rigid hierarchies of management that results in these teams working on their "parts" with a limited "need to know" about what the others are doing.

It takes a much deeper organizational change than with just development.  It's not a development problem alone.