Tag: agile

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)

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.

MeetUp: Company Agility in Action

by xavierfigueras, posted in Uncategorized

Last Wednesday I had the pleasure to attend a meetup event about agility organized by InnoIT in the center of Barcelona. The goal was to share tools that supported multiple organizations in their agile journey. So, what’s there?

1. Wardley Maps

The Wardley Maps come up as a solution to measure the organization’s capacity to anticipate technological change, demographic change or how user’s preference it’s going to impact us.

If you check out the web page www.learwardleymapping.com you’ll see they have a video that explains briefly what the wardley maps are about. As you can see we categorize each part of our process into the uncharted – industrialized axis, while on the Y axis you can see how we target our purpose strategically.

I found it extremely powerful in the sense that it obligates you to position your product and visualize your business strategy and creates awareness of the weak points and strenghts around it, so that you can adapt better as information emerges.

I really enjoyed this article which explains very well how can you operate based on that framework: https://medium.com/@hendrik_esser/fit-for-purpose-e442b9015ec7.

2. Flight Levels

Flight levels come in from the point that ‘agility is not about teams’. What this really means is that it’s more than that. Of course agility it will end up affecting the way teams work, however it should be the starting point, we need to see how agile we are at a strategic and end-2-end coordination level and here is where Flight Levels jump in.

If you are still interested in knowing more about flight levels I would recommend you to watch this video:

And buy this book from Klaus Leopold, as I just did 🙂

3. OKRs

I assume this is by far the best well-known tool from all so I won’t expand myself much. OKRs are meant to set a desired target state and find ways to measure our progress towards it.

In this website you’ll find some practical examples of how it works: www.whatmatters.com

4. EVIDENCE-BASED MANAGEMENT

As you can see Evidence-Based Management goes around the idea of focusing on customer outcomes (top axis) and organisational capabilities (bottom axis) to make better organizational decisions.

As you can see in this video:

One of the goals of evidence-based management is to ensure we capture all evidence by following six steps:

  1. Ask an answerable question to help you identify problems or possible solutions
  2. Acquire relevant information or evidence that will answer that question
  3. Appraise the quality of that evidence for its trustworthiness
  4. Aggregate the evidence by summarizing or pulling it together
  5. Apply it to the decision you are making
  6. Asses the outcome of that decision

I think the video explains quite well what the approach is, still, if you are interested in learning more, there is also this book available in amazon.

5. F4P

Fit for Purpose goes around the idea that in agile there is no “one fits all”. Here we are looking at our product from different angles:

  • Product
  • Metrics
  • Costumers

And we can go into deep to analyze how well we are performing at each front. An excellent example that they put was that for instance if you go in business class and they are constantly bothering you to offer you things the overall experience it’s ‘unfit’, within the fitness criteria metric.

To be honest it was not straightforward to find a video or explanatory site around the topic. This is the best I could find:

Recommended Bibliography

Summary

The meetup was very valuable to me. To be honest it was the first time I heard about the Wardley Maps and Fit for Purpose framework, plus it allowed me to have a better understanding on evidence based management and flight levels.

It is also true that during a meetup you really don’t have the chance to go deep into any of the topics, putting real life examples and discussing them with the group. Again, I think the goal of the meeting was accomplished which is to share and give an overview of the tools therefore I am grateful I could be there. Thanks Jerome!

Agile Game Development – Book Review

by xavierfigueras, posted in Game Production, Leadership

The Game Production subject I teach ‘Game Production’ at TecnoCampus as College Lecturer it’s based on a book called ‘Agile Game Development’. Here you can find my thoughts on it.

What is the book about?

The scope of the book it’s quite broad: starts sharing a historical perspective on how the game development has changed over time, explaining the impact agile had in the game industry and constantly relating to the experience of the author: Clinton Keith.

For those who are getting started into agile, ‘Agile game development’ offers a deep introduction to elemental agile related aspects such as the methodology (scrum, kanban and lean) and the product backlog, all of it in a gaming context.

Clinton Keith did not only stick to the basics in this book. He went above and beyond explaining how self-organized teams look like, how to scale agile, and gave an introduction to agile best practices such as extreme programming.

What I liked about the book

  • Undoubtedly the top takeaway from this book is the multiple examples it offers putting agile into the game context. Not only from a artefact perspective (user stories and roles) but also exposing usual production mistakes and how agile helps preventing them.
  • Its all-in-one approach it’s very adequate if you are getting started as producer. If you are experiencing ‘first time’ challenges, this book will most likely solve your questions.

What I disliked about the book

  • The book chapters are not synthetic enough. By trying to cover all possible ‘use cases’, it fails to communicate clearly the final message. I believe other books like ‘The Agile Samurai’ and ‘Agile Coaching’ can help you understand the exact same concepts in a much more concise and better structured way.
  • Not all chapters are treated with the same depth. I could not find the level of detail observed in scrum and user stories when going through the self-organized teams and scaled agile parts. This is a book that could have been easily divided into many, giving a more balanced level of detail.
  • Mixing concepts with examples of what not to do. Although I understand the good intention behind sharing personal experiences, at some point it turns out confusing and do not add value when those experiences relate to bad practices. I would have appreciated a ‘this is the theory’ and ‘this is how it’s done’ simpler approach.

Summary and rating

In spite of its complexity and lack of conciseness, it’s all-in-one approach and its multiple game related examples, make of this book a unique partner for anyone who wants to get started in any of the aspects related to agile game development. If you are already an experienced producer, I would recommend you to get specific books specialized on your topic of interest.

Rating 3/5