Tuesday, April 12, 2016

Mechanic Driven Development

I was sitting around this morning with my coffee thinking, "what the world needs is another 'X Driven Development' approach to creating products".

Well, not really, but I have been thinking about this approach for awhile and observing it in action.  This post describes a variation on how some agile game teams have changed their approach to planning and executing sprints.

A video game usually has several core mechanics that we want to develop in depth.  For example, a platformer might have movement/control, environmental challenges/enemies and power-ups/rewards.

Given this, we can start by building three branches of the product backlog:

These are core mechanics.  They are core because we have to ship with all three and they are core to the player experience.  Outside the game industry, this might be called the minimum viable feature set.  This is different.

Mechanic Driven Development (MDD) focuses on delivering a narrow set of features each sprint, which are dynamically linked to move a mechanic's playability forward.

For example, let's say we have three team each centered around a core mechanic.  The movement/control team might break down their core mechanic even further:

Now we have running, jumping and offensive moves, each broken down further.  In what order does the team develop these items?

In mechanic driven development, the question for the team becomes, "what can we do over the next iteration to move this mechanic forward?".  In other words, "what's the most important work we can do for the movement/control to make the game more playable"?

To me, running and jumping would seem to be the most important.  Other people might feel differently.  We'll talk about it as a team (including the product owner).  This conversation builds vision, creates consensus and drives developer engagement.  The resultant sprint goal contains progress of some or all of the sub-mechanics derived from that discussion.

When a team does this, the result is a sprint that is measured by the progress of the mechanics rather than a collection of stories completed, etc.

What benefits does MDD bring over more traditional approaches?
  • It engages the team in discussing the game's mechanics as a target every sprint, not just the completion of a set of stories.
  • It creates opportunities for more creative input from the team.  A ton of small user stories from the backlog often suppresses creativity.
  • It keeps the product backlog very simple
  • It makes the sprint goal very meaningful (again, instead of just a collection of stories)
  • It drastically limits design debt

MDD is a direct application of the "working software over comprehensive documentation" value in agile.  It'll often result in a direct path to playability and an elimination of excessive work called out in a detailed plan written in a design document.  This approach can also be used with a detailed design document.  We just prioritize the work and sprint deliverables that grow the mechanic and reflect the emerging game against the plan.

Give it a try!


Unknown said...

I've been looking for good flow chart / mapping software. What are you using for the graphics in this post? I'd also be curious what tools of the project management trade you recommend. Thanks!

Clinton Keith said...

Joel, I use Mindmanager. iThoughtsHD is good too.

Re: PM tools. It really depends on what you are trying to track.

Small teams get by with Trello, but console/AAA games use Jira, Hansoft, etc.

I steer away from tool features that demand too much detail tracking as they lead you into the false sense of certainty and impact team culture: