Tag: Game Production

About the Game Producer role

Featured by xavierfigueras, posted in Game Production

It’s really interesting how the role of a game producer it’s confusing to so many people. It’s a role that has been in the game industry for years, however, every time I ask a new employee if he or she’d like an introduction to the role, they really appreciate having it.

What I’ll share here are just my personal views, which have been contrasted with many peers from the profession over the years. I’ll be happy to get any additional insights in the comments 🙂

What does a game producer, really?

Product Managers define the product that needs to be built, engineers craft the solution to meet the expectations, what does a game producer in this equation? what is the tangible outcome? In my eyes, the overall team.

Let’s go down to the basics, let’s say you are three people team and want to create a game, do you really need a producer? yes and no. What you really need is a way to fulfil the hands-on roles: product manager, game designer, game artist (here we can include concept artist, 2D artist, animation, etc.) and of course programmers and testers, all together will in the end be the ultimate responsibles for crafting the software, however, as the family grows, you might experience inefficiencies in the overall system, and here is where a role of a game producer can come really useful.

Is the primary job of a producer to build a highly effective team. As said before we already have team members focused on the WHAT, others focused on the HOW, is your responsibility as producer to make sure these two worlds merge effectively and the resulting combination turns out a high-performant system, able to deliver qualitative product increments in a fast pace of work. That’s why here I talk about a ‘how’ at an overall level that involves many other crafts.

The primary job of a producer is to build a highly effective team

If you stop to think, what is really the difference between a tech producer, feature producer and let’s say a cross-team game producer? in the end they all share the same goal, which is to keep the team unblocked and productive as close to 100% of the time as we can, working on the highest priority items they can work on with all the information and context they need in order to do so.

And yes, this also means that the role of a Scrum Master or an Agile Coach aren’t at all that different from a game producer. From my point of view they all have very different contexts, and, at the same time, they all share the ultimate same goal.

What is the difference between a good game producer and a great game producer?

A good game producer will remove impediments for the team, ensure we are working on the top priority items and support in case there are any conflicts within the team. A great game producer, on the other hand, will think out of the box and enable the team to flourish and reach its unique highest potential. This means that it will continuously challenge the ways of working, also him or herself, actively listening to ‘what is trying to happen’ and putting the team in the center of everything he/she does.

A great producer will remove dependencies by setting autonomous and mature development pipelines, by doing so, he or she will also be also making himself/herself non-essential in the process. Paradoxically, the team’s ability to operate and improve without a major involvement from the game producer is in fact one of the best KPIs that will distinguish a good producer from a great producer.

Does it mean we have to delegate all work to the teams? Not really, what I am saying is that’s the target state, a great producer will be able to determine its degree of involvement based on the team current status and will have ability to gradually transition towards a more autonomous structure as it makes sense to the team. This is the reason why the top priority of a producer when landing a new job is always to observe and ‘meet the team where it is’.

bUT WAIT A MINUTE, ISN’T THE PRODUCER ROLE TO HELP THE TEAM PRODUCE MORE? SHOULDN’T IT SOMEWHAT RESULT ORIENTED?

Indeed, it’s the producer’s job to continuously help the team deliver more, which is usually measured through team’s velocity. If the team velocity increases it’s an indicator that your team is increasing delivery over time, at the same time we need to be very careful on how we use that indicator, otherwise it might bias behaviours at many levels of the organization unintentionally. Judging a team by its velocity could be somewhat similar to judging a book by it’s cover, it’s an indicator, and as such, it’s needs to be used wisely, for instance as starting point for raising questions to the team so that new information can come out.

Judging a team by its velocity it’s like judging a book by it’s cover

Faster delivery doesn’t necessarily mean you have a great ‘machine’ to operate, but having a great ‘machine’ to operate will increase the chances to deliver faster. This is the reason why I set the focus on ‘having the machine right’ in the first place.

OKAY SO, WhAT’S THE DIFFERENCE BETWEEN AN AGILE COACH AND A GAME PRODUCER?

Historically the role of a game producer has been described as ‘ninja’, abstract as such is not a good sign. The video game sector has not stood out by it’s ability to create a sense of order and alignment, all the opposite, what we found most of the times was fuelled-in passionate teams with no clear direction or sense of alignment, abandoned to the fate of working countless hours in the so famous ‘crunches’ in video-games. The role of that ‘ninja’ was in most of the cases lost in the operational level, running an active part in managing backlogs and leading the team, rather than being strategic from the very beginning.

Over the years the role of the game producer has received the influence of the agile movement, systemic coaching and management 3.0 principles which somehow enriched the role and helped it find its place into the big picture. The role of a game producer has being organically transitioning from an ‘active role’ to a ‘lead by example’ role with greater levels of delegation.

As I was pointing out earlier the difference is pretty much based on the context. While an agile coach is someone usually hired to act as consultant with a very specific purpose, a game producer it’s usually part of the team, hence it’s ability to influence and detect opportunities to move the team forward will be critical. Furthermore, a game producer will normally possess a specific background on the games industry, has good knowledge of the places where the project can go side-ways and will also be able to go deep into the pipeline processes to make them better, which might take a long while for someone unfamiliar with the context of crafting games. Last but not least, a game producer requires an understanding on the creative disciplines and might also get involved in project budgeting, live operations, and many other product areas.

Isn’t the game producer some kind of project manager?

Isn’t cyan color blue at some point? being a project manager is just one or the multiple hats a producer must wear, which by the way can be worn in many ways, and won’t definitely define you. As we have seen previously there are many aspects related to processes, team and product management that are far beyond the concept of project manager.

The way to manage ‘project manager’ responsibilities within the team will differ from one producer to another, also depending on the levels of unpredictability a company is able or willing to handle.

THE RESPONSIBILITIES OF A GAME PRODUCER

Although ultimately a producer will be judged by the team’s ability to deliver, there are many other responsibilities on the way, from forming strategies and communicating them, through motivating teams and individuals, to managing stakeholders expectations. This means the producer will be heavily involved in coordination, game design support and milestone planning.

Depending on the case, a producer might also be in charge of budgeting and resource allocation. Ensuring an efficient team’s allocation within the financial constraints will be key to set a baseline for success.

Last but not least, the producer will be in charge of setting the right processes in place. Creating the structures to enable the desired levels of alignment, focus and collaboration it’s ultimately a producer’s responsibility.

WRAPPING UP

As you’ve seen this is indeed a complex topic as there are multiple dimensions to consider plus it has being varying subtly over time. Hopefully the descriptions above gave you a greater idea on what’s expected from this role. Please do not hesitate to drop any questions or comments. Thanks for your time!

(header image by http://www.freevector.com)

My top 3 learnings for running a good retrospective

Featured by xavierfigueras, posted in Uncategorized

As you all know I have been running retrospectives for several years and I can say I had the chance to learn from awesome facilitators during this time. Today I’d like to share with you my top 3 learnings.

Focus on the actions

In the end the success of a retrospective is measured by the quality of the resulting actions. Therefore it makes sense to invest a decent amount of time in discussing them and ensure alignment. A common mistake is to spend way too much time in the problem solving phase, which unavoidably force us to speed up to define the actions.

If in a 1:1 coaching session the recommendation is to invest a 80% of time to discuss issues and 20% to jump to action, in team retrospectives I’d adjust these percentages in the following way:

  • 10% to share the agenda and make sure everyone is present in the meeting (check-in)
  • 60% dedicated to raising problems and discussing them
  • 30% dedicated to action refinement and feedback

In order to get to quality actions I suggest:

  • Less is more: it’s better to leave the room with one good action rather than three regular ones.
  • Do not hesitate using extra frameworks such as effort-value charts.
  • Use the soup retrospective to help the team understand what are the areas where the team can control and the areas where the team can influence.
  • Using the SMART approach (specific, measurable, achievable, realistic, time-based) after the voting session.
  • Measure alignment: making sure we all have the same understanding on what should happen.
  • Have a clear DRI (direct responsible individual) over leaving it to the entire team

FOSTER DIVERSITY

A game changer for my retrospectives was to find ways to bring up the best of what’s already in the room. Based on the believe that wisdom lies within the team, it’s on our interest to make sure all ideas blossom. Everyone has great knowledge on how things should look like, however, when we simply ask “what can be improved?” certainly there are many aspects that can be easily left out.

Ways to foster diversity:

  • Show a video that can serve as a metaphor during check-in phase.
  • Draw the latest iteration.
  • Ask open questions related to the vision: what is the best team you’ve ever worked with? what was present there?
  • Run a previous hopes&concerns session.

You can think of it as giving a lantern to the team and ask them to look left, right or in any specific directions before jumping into a broader question.

ENSURE PRESENCE AND CONNECTION

The hybrid format brought up an underlying problem in many meetings and is that easily we lack the team members engagement at some point during the process. As facilitators it’s on our best interest to make sure to reach high levels of participation so that quality discussions happen.

Since it’s very likely that our colleagues have concerns or out of scope thoughts distracting them, it’s a very good idea to do something to help them be present. Here are some possibilities:

  • “Pass the ball” and just share something quick related to the latest iteration, for instance, a rating from 0 to 10, also metaphors can work wonders here.
  • Do not hesitate using the ‘liberating structures’ (an example here). For instance, it can be a good idea to run a “hopes&concerns” 5 minutes chat with just one of the team members and then bring scale up the group until you reach all attendants. In this way, people will feel aligned an connected.

Summary

Retrospectives are unpredictable in many ways, however, I strongly believe that:

  1. Ensuring presence and connection
  2. Creating diversity.
  3. Focus in reaching quality actions.

Will work wonders to bring your retrospectives to the next level.

Product Roadmaps – Book Review

Featured by xavierfigueras, posted in Game Production

Here you can find attached my learnings from ‘Product Roadmaps Relaunched – How to set direction while embracing uncertainty’.

What is the book about

Written by:

A good product roadmap is one of the most important documents of the organization, as it helps align stakeholders around product goals, giving a visual representation of a strategy. ‘Product Roadmaps’ comes to provide a detailed summary considering all aspects to be considered when designing one.

This is a book mainly addressed to product managers, but also useful for other roles who need to take care of the roadmap in order to communicate and manage expectations.

wHAT i LIKED ABOUT THE BOOK

  • It consistently works on the mindset behind product roadmaps. Stating clearly that a roadmap is not a project plan. Plus it goes to the why, talking about the importance of aligning it with the company’s vision and mission. The book explains how the themes and subthemes of our roadmap need to relate to the objectives that will in the end push toward that product vision.
  • The holistic approach when defining the contents of the book makes it a very well-rounded book. Plus it makes it easy to collect ideas fast with minimal effort. You can perfectly skip some pages and still get a lot of value out of it. Its combination of tools with ‘light theory’ provides a healthy balance that makes this book compatible with experimented experts and also beginners in the product management world.
  • The format is extremely friendly. It clearly aims to cover many user cases so that you can get the answers that you are looking for, and it makes it with images, charts, tables, etc. It makes the book very clear and easy to read.

What I disliked about the book

  • Although I understand that the product roadmap is quite a broad topic by itself, the way the contents are distributed around the book feels quite random. It would be nice if the authors had found some way to make it a bit more sequential. For instance, chapter 3 ‘gathering inputs’ could have been followed by chapter 8 ‘achieving alignment and buy-in’, and later on chapter 7 ‘prioritizing with science’.
  • At some point, I believe this book is not pragmatic enough when not mentioning at all engineering or the actual development teams, who are the ones responsible for making a technical assessment and setting expectations in the first place. I would have appreciated greater clarity on how all parts contribute to the roadmap rather than focusing on the product side only.

Summary and rating

This book handled multiple aspects of the roadmap in a very detailed manner, covering delicate topics and considering the different stages from ideation to the actual roadmap plotting. Clearly written and to the point, it’s a book that almost anyone can benefit from, however, I would have appreciated a better index and a natural involvement from the development side when defining a roadmap. If roadmaps are an interesting topic for you and your everyday life, I totally recommend this book.

Rating 4/5

The Hackathon Experiment

by xavierfigueras, posted in Game Production

Last week we run a Hackathon experiment at my company. The overall experience was a blast, it was my first time in an event this kind and honestly, it’s hard for me to understand how these sort of events do not take place more often everywhere. Here you can find what I learned from it.

First of all, what is a Hackathon?

A Hackathon is a collaborative engineering event where domain experts join efforts to come up with experiments in a relative short amount of time, usually 24 to 48 hours.

Gigantic ROI

Companies in general seem to be afraid of running this sort of events as in the end we are talking about tons of working days that are not invested in “what we are expected to do” so, why doing it?

Team Building

It was amazing having most of the team together in one place for an extended period of time without daily operation interruptions. We all had the possibility to interact and develop with different team members than the ones we usually do. By bringing our best into the group, the bonding level within the team became even stronger.

Creativity

Running this hackathon was another demonstration that wisdom lies within the team. Everyone had amazing ideas to bring the product to the next level. The end results shown a great variety of results and lots of ideas can now be taken into consideration for the final product.

Passing the ‘I don’t see it’ threshold

Sometimes talking about it or sharing slides it’s not enough, you need to spend a minimum amount of time to shape and make that idea real so that everyone can understand it better and get the deserved buy-in.

Actual Progress

It’s amazing to see the progress a team can do within a short amount of time. In most of the cases we can consider the work done as actual progress that can definitely be incorporated in the long term plan.

Increased Product Engagement

One of the things I love from the game industry is the level of passion of everyone around. When running this sort of events this passion connects with the product at a deep level, everyone has a much better grasp about the product and its potential behind.

PRODUCTION LEARNINGS

As said before one of the learnings is that is very interesting to see the progress teams can do in such a short amount of time. It shows multiple things:

The power of focus

By removing distractions and creating momentum, we are providing the environment where great progress can emerge. It’s also a demonstration that pair programming works well for exploratory projects.

No requirements experiment

Interestingly one of the factor that changes in these productions is that the communication between ideation and implementation is immediate given that ideation is run by the same developers in many cases. This means that the time invested into defining requirements it’s really minimum, and what really matters is the discovery process, adopting a more agile approach overall.

The time invested into defining requirements it’s really minimum, and what really matters is the discovery process, adopting a more agile approach overall.

About the hybrid format

In our case some team members could not come into the office for the event. Although they could fully contribute at every level in the same way, I still feel it’s an organizational challenge to make them feel as if they were in the office.

Conditions FOR success

Finally I’d like to share my view on what I consider were the keys for success.

With freedom comes great responsibility

The whole event was running very freely. All we were asking was for ideas minimally related to our product. During the event I got the feedback that when they felt so much freedom, they also felt the responsibility to come up with something valuable.

Product strategy

I saw other hackathons where the organizing team was trying to influence the proposals by incentivizing somehow. For instance: we are looking for the best solution to increase engagement. By bringing a push into certain goals we might be missing the cost of opportunity, and many good ideas might never see the light.

My takeaway here is that is good to share about the product strategy so that everyone can consider it during the ideation process, at the same time keeping the freedom spirit to blossom ideas in any other direction.

The right time

It’s important to be strategic and intentional in terms of timing. You don’t want to break the focus in the middle of other developments.

Great team

Fortunately in our case we were counting on mature senior teams with great ability to self-organize, ideate and a strong determination to bring ideas to completion. These are really important ingredients to make the recipe work, the credit goes to them!

Processes: Between Chaos and Order

by xavierfigueras, posted in Game Production

What is a process?

A process is any kind of event that takes place with the purpose of giving structure, it could be a document, a meeting, or simply an action among a few individuals with a specific outcome.

When should I review my processes?

Constantly. Given the self-evolving nature of any organization and their needs, it’s natural to adapt processes continuously. Here I would invite anyone to apply the PDCA cycle based on: plan, do, check and act.

Introducing processes: a delicate balance

Processes come into place to establish order and remove uncertainty. At first sight one may think that of course we want as much order as possible and therefore as many processes as possible. However they come at a cost. Introducing processes by definition will bring constraints and boundaries in all operational aspects, reducing the margin for adaptability and flexibility in the organization. Therefore we need to target the right balance considering:

  • What is it that we are trying to solve?
  • What is the benefit hypothesis?
  • How is it being done right now?
  • What is the buy-in for a change?

For this reason I highly recommend working with more people to brainstorm ideas and come up with better solutions that are tailored to the organizational needs. There is no one for all.

So, how would the processes for introducing processes look like?

  • Problem framing: what is it that has changed? where is the problem? why? let’s make sure we have the full context.
  • Brainstorming: let’s gather ideas to solve the problem and come up with a proposal.
  • Selling: to get organizational buy-in before implementing.
  • Landing: phase where all processes fall into place, can be a sudden change or gradually.
  • Operating: here the process reach its full potential and it’s deeply understood by everyone.
  • Evaluating: here we are in a position to do an assessment and iterate.

In my experience

Between boredom and freedom

I have witnessed how extremely well structured organizations led at some point to boredom and messy organizations came with a feeling of freedom. More than that, it’s proven that teams are more efficient when the right balance between those two extremes is met.

The ‘too many meetings’ syndrome

It’s interesting how in many organizations the same problems or sayings repeat, in this case the ‘too many meetings’ one. Here I would kindly invite to dig deeper: what meetings? and do an exercise where we classify them with their ROI in team members eyes and understand exactly where is the leak in the process so that we can adjust accordingly. Is it in the contents? is it in the format? In the end, no one loves meetings or rules but we need them due to the value they provide.

Help understand the purpose

There are times that teams miss the final goals. It’s never enough of sharing the purpose of a process. A classic one is the daily standup, which only purpose is for the team to sync and not a reporting one. Does it feel natural sharing what you did yesterday? does it bring any new information to your colleagues? if not, skipping it’s fine.

Meet them where they are

Before helping others understand it’s important to understand them in the first place. How are they perceiving their current processes? What is the culture? for any implementation to be successful you need to connect at a deep level before applying any change.

It’s all about value

If we do the metaphor of an organization as a person, I like to think of processes as the brain organ. Certainly we don’t produce while having a meeting or creating a document, at the same time we need that to make sure we are having the correct approach or going into the right direction. And here I invite you to think: is your organization too focused on the thinking mode? or is it running just flat out?

To understand if we are ‘too much’ into one direction or the other, we need to come back to the purpose: how is it helping me deliver more value? We should always be able to answer that question when introducing or modifying a process.

Improving your processes will help you organization achieve increased levels of engagement and efficiency, reaching a higher sustainable development pace.