Wednesday, October 7, 2020

Project Steering for Games

The Games development is a highly competitive global industry; with hundreds of games launched or updated every week. To achieve anything more than mediocrity requires the entire value stream of game development to be working together effectively with each individual along that stream delivering a stellar performance. Maintaining a healthy company balance sheet, means each game project needs to have solid indicators of future success before significant time and effort is sunk into it. The Project Steering approach described in this article was something I helped to design and implement to keep multiple game projects on track while allowing those game projects the flexibility needed to find the next hit game. 

Context on company structure

The year was 2017. Game teams were the basic building block of the company. Generally, each game project was executed by one game team. Each game team was deeply cross functional including people who can cover the following as a minimum: design, development including engine development, QA, art, marketing, analytics. Each team was led by a Product Manager (effectively Product Owner and Team Lead). There was a strong emphasis on the PMs being servant leaders, who grow and develop a self-organising team. What I observed in games was that everyone was very passionate about the game they were developing and wanted to have a say in the direction it took. While this passion is intoxicating it could also lead to chaos; this why the Product Managers (PM) retain authority to make decisions. Retaining creative control ensures that the product follows a clear vision. 

Objectives of the Project/Product Steering approach

  • Ensure each game team is focused on regularly assessing if their current project is the best use of their skills, time and effort.
  • Balance the autonomy of new Product Managers (PM) with the control mechanisms that prevent significant mistakes from occurring. 
  • Support the Product Managers and teams to maximise ROI for the company over the long term; through feedback and guidance from experience leaders within the company.
  • Transparency of project Steering so that the whole company can choose to be aware of what is going on and learn from the success/failures of each game team.

Monthly Product Steering meeting

The key element of the Product Steering approach was a monthly public meeting held for each game project. During the meeting the Product Manager or a representative from the team presents from a standard template. The primary attendees are the Product Steering Committee*; however the meeting is public so anyone from the company may attend. The Product Steering Committee asks clarifying questions and provides non-binding feedback and guidance. Initially everyone apart from the Product Steering Committee was asked to observe only. Over time this gradually changed first with specific audience members being asked questions, then later open question time at the end of the meeting. 

These meetings were scheduled for 1 hour and some of the early ones took that long. However, in the matter of few months they were regularly completed in 30 minutes including question time.

Product Steering Committee

The Product Steering committee was composed of senior leaders who held a vast depth of experience in the games industry from around the world. I was also included; initially to help refine the template I had created for the meeting and after that stayed on as me asking the questions a 5-year-old would ask seemed to provide some value.

  • CEO
  • CFO
  • CTO
  • Head of Product Development
  • Head of Business Intelligence
  • Agile Coach

Preparing for the Product Steering meeting

While the Product Steering meeting was often insightful and helpful for all involved. The act of preparing for the meeting also provides a lot of value; especially for those Product Managers who were considering not holding a meeting. Often their desire to not hold the meeting is a subconscious move to avoid facing some uncomfortable facts about their project. 

Another positive aspect of the preparing of the meeting was that the Product Managers often reached out to members of the Product Steering Committee for assistance with preparing their presentation. These interactions were a chance to learn from each other and improve the direction of the project.

Regular feedback

Completing the Product Steering approach was regular 1 on 1s and feedback from the Head of Product Development to the Product Managers. This is massively important for less experience Product Managers and still very useful for the remaining Product Managers.

Common Presentation Template

The template was a two-page slide deck that provided answers to the key questions the Product Steering Committee wanted to see from every game project. Without answers to these key questions the committee members would struggle to provide effective feedback and guidance. Creating a consistent template helped both the Product Managers and the committee. For the PMs it cut down their preparation time, for the committee it meant they did not have to translate the information provided to them in different formats by different PMs. Additionally, it meant the committee had could compare game projects.

The PMs were free to add additional slides showing whatever detail they felt appropriate. Roughly three quarters of product steering meetings include extra information; such as partnering deals, highly feature maps, results of experiments etc.

Page One:

  • Product goal in one sentence
  • Declared intention (Persevere, Pivot game, Cancel game)
    • Sub section seeking input from Product Committee on specific topics
  • Product Health
    • Is the team learning what their customers will respond to?
    • Is the team delivering with suitable throughput?
  • Team Health
    • Overall morale
    • Specific issues affecting them
  • Financial summary, last three months
    • Costs, revenue, ROI
    • Projected financials, next month with certainty, next 6 months with low certainty
  • Results of objectives
    • Were last month’s objectives completed?
    • Did those objectives change?
  • Objectives for the coming month.
    • High level deliverables, learning outcomes, etc.

Page Two:

  • High level road map of deliverables, experiments, deals, etc. 
    • Current quarter was more detailed and showed when items were completed.
    • Next two quarters were highly level and subject to significant change

Sunday, July 12, 2020

Achieve more by delivering less: descoping is the secret sauce of agile teams that quickly achieve business objectives

Switching from traditional development to agile development usually results in a significant increase in the speed of delivery. This increase in speed partially comes from agile practices speeding up the people’s ability to build and test functionality. Interestingly the vast majority of this speed improvement comes from dramatically reducing the amount of functionality we are working on at once. By reducing our scope, the people are able to focus, gain fast feedback and quickly deliver outcomes. What is most interesting to me is that to further increasing the speed of building and testing functionality has a high cost; while further reducing the scope has a medium to low cost. This means that to achieve the greatest impact we should turn our attention to cutting scope where ever we can. This is the key to FAST deliver with agile.

To put all of that in numbers, adopting Scrum compared to Traditional methods usually delivers a 20% increase in speed of delivery. This can be gradually improved year on year, say 5% increases each year. When we cut out 30% of our scope from the first years’ worth of work, we are already two years ahead for a lower investment in effort. I am not saying stop trying to improve your development speed; please continue and add that to the gains to be made by reducing scope.“But our stakeholders have been promised X, Y and Z, you can’t just remove any one of them.” I hear you say. That is fine, we not going to remove those items, we are going to reduce the scope of each item, honing it in on achieving the business objective(s) it relates to. The business will still get X, Y and Z, it will meet all of its objectives; it will just be achieved with slimmer versions of X, Y and Z.

The approach to delivering business outcomes faster for less effort is not magic. It is a composition of basic agile practices, wrapped up in a feedback loop and supported with lots of collaboration. To start achieving more by delivering less, follow these steps.

  1. Scope what you know: google “User story mapping” to start.
  2. Split work into smaller pieces that are vertical slices: google “splitting user stories” to start.
  3. Forecast your delivery outcomes: Please refer to my blog post of Forecasting.
  4. De-scope to fit your objectives: explained below.
  5. As you learn more, repeat those steps just for the changes/additions/removals. 

A forecast indicating late delivery

Descope to fit your objectives

While this is titled as “descoping” it will not descope everything, some items will be deferred for later releases, some will be cut never to return, some will be split with bits done now, later and much later (aka never). Any item that is removed from the current release has reduced the scope of that release and hence will increase the speed at which we can achieve the business outcomes attached to that release.

To stand a good chance of succeeding with this approach you will need to understand the business environment and the objectives that the business (aka stakeholders) are setting out to achieve now and in the near-term. Understanding this will help to guide the splitting and descoping discussions; without this knowledge you are effectively operating blind. 

The work of “descoping” should be done collaboratively with a small group that represents a cross section of those involved, such as Product Owner, experienced Tester, experienced front-end developer, experienced DevOps developer. This small group should be able to move quickly, creating a view of the work that can then be reviewed more broadly.

Together the small group will repeatedly prioritise the backlog, split up larger items and move items between different releases until the delivery forecast indicates we have a chance of success (aka we have a chance of completing the release ahead of the targeted release date).

Forecast after descoping; indicating that delivery will occur ahead of the milestone

Prioritise the backlog

To figure out what to descope, and what to spend effort splitting up we need to prioritise and order backlog. When I say prioritise the backlog I mean ruthlessly prioritise by value! Forgort MoSCoW prioritisation it is too emotional; “oh I must have that”, “we should have that”. We need to be RUTHLESS! To get you started use “above the line” prioritisation. To do this visualise the backlog, draw a very clear line, then collaborate with the group to end up with only 50% or less of the items above the line. Now draw another line above that line, and repeat. You will end up with three sets of items: Top Priority <25% of the backlog, next priority <25%, and lower priority >=50%. These sets don’t have to correlate to your releases. What these sets give you is a clear view of what is important and not so important. You can even remove those lines if you like, they have no served their purpose. The backlog should also be ordered for dependencies.

Split up larger items

Larger items often hide within them some work that is crucial, some that is nice to have, and some we don’t need to do at all. Splitting up larger items helps us to uncover the work that we can move to later releases or not do at all. 

I recommend that you find the largest items in your backlog, split them up, move and/or descope those smaller pieces, then go onto the next largest items. The key to remember here is to split the work into vertical slices, it is all about finding what is valuable and what is not so valuable. If you split horizontally the value is spread across all of the split-out items and you will have wasted your time splitting it up in the first place. 

Move items between different releases

Whether your work starts out as separate releases/backlogs or as one larger backlog that you cut up into separate releases; having your work in separate releases provides you with flexibility in planning and how you communicate to your stakeholders about what is going to be done when.

I recommend that you always have one more release in your backlog then you include in your published delivery forecasts. This is the lowest priority release, the YAGNI release, later, never what ever you want to call it. This dumping ground allows us to keep all of the items around, reducing tough conversations with stakeholders that are deeply attached to something that should never be built. 

When you move an item from an earlier release to a later release you increase the chance of the earlier release being completed by its target date. Of course, the work has not disappeared just been deferred. With the rate of the change in most businesses deferring that item may mean it is never done; depending on your point of view that may be a win or a loss. 

As your small group updates these releases and their corresponding forecasts of deliver it is important to get the whole team to review them and to share them with your stakeholders.