Valuing value

Value should be an important word for any modern developer. It does not only describe how we view people internally or how we think about our customers. It also describes what we are doing on a daily basis, building value.

Value flow

A modern product development team focus is on delivering small increments of value (from here on referred to as a feature) to the customer frequently. We can view the process that a feature goes through from idea to release as the following:

An idea starts in the backlog awaiting its turn to be realized. When there is room to handle the feature, it will be taken into development. A completed and signed-off feature ends up in a virtual inventory of features which are ready to be included in a release. Eventually the feature will be made available to the customers in a public release.

Lean thinking defines value as something that benefits the customer, but it cannot be realized before it is in their hands. With that in mind a product development team would have a strong incentive to minimize the time a feature spends in the virtual inventory. The best way to achieve this is by releasing the product frequently.

Optimizing the flow

In order to optimize the flow of features, there are a couple of metrics that can be used in an effort of becoming streamlining the flow.

The first metric is Time to inventory, which is the time it takes for a feature to be completed and placed in the inventory. Ideally, this includes the time a feature spends in the backlog before going into development to ensure that a qualitative backlog management. Following that definition, innovative organizations with lean backlogs and focused attention in development would score low on this metric. However, in products with a big design up-front, a “fat” backlog will make this metric quite useless. It would then make more sense to limit the Time to inventory-metric to the development stage.

The second metric is Time in inventory, which measures the time features spends in the virtual inventory. The less time spent there, the faster features can provide value to the customers and hopefully generate profit for the team.

Small drops versus big bangs

Optimizing on these metrics makes perfect sense in SaaS products, but some products are bound to do big releases, for example console games. For these products the concept of value does not come as naturally.  When the release date is immovable, there is little incentive to complete features in the short-term, they will anyway just lie in the inventory waiting for the final release. Hence, in most console game productions, the majority of the features are being completed during the final hectic period of development. The short term optimization decisions in product planning are typically work-driven. The question asked is “What should we do next?” rather than “What should we complete next?”. Does it make sense to be short-term value driven in these kinds of productions?

A case for value-driven mentality

In my experience the work-driven mentality is one the greatest problems in large scale game development, causing failed productions and also quite miserable work environments. The upside is that there is a lot of room for improvement and one step in the right direction is moving towards a value-driven mentality.

If you are value-driven, you prioritize completion of features over optimizing of workload.  By diligently focusing on completion early on the team has plenty of chances to learn from successes and failures.  But more importantly, the “last ten percent of quality” of a feature is the most expensive part. If the team is not delivering value continuously throughout the production it is pushing a pile of trouble in front of them. This pile will come back to haunt the team during the end phase of the game, possibly even risking the final release date. Thus a value-driven mentality can also help to increase predictability, but there are a few obstacles along the way of such a transition.

1.       Distance to the customer

Most console games are developed “under the radar” without any connection to the potential customers during most of the production. There is no feedback given on value delivered from the players until it is too late, so the concept of delivering value feels very distant.

2.       Discipline capacity thinking

It is very common that the production is optimized based on capacity within disciplines. This means that features need to be broken into work at an early stage. That way the best way to utilize the resources can be found. The game must be as enticing as possible, so we need to pack as much features as possible into the product. But is optimizing on capacity the best solution to maximizing value?

3.       Lack of trust

Trust is an important component of a modern development organization. Leads must trust their teams and teams must trust their leads. The leads need to trust the teams to optimize on value given a description of the intent rather than a detailed description of the work required to reach the intent. The teams need to trust the leads that the intent is a good heading. Commonly people in large teams work off of lists of tasks delivered to them by leads, with limited understanding for the value that they are optimizing on.

4.       Hard to formulate the intent

It is time consuming and difficult to formulate the intent. Even though the vision might be crystal clear in the head of the vision holder it might be very difficult to describe it in terms of individual pieces of value. It is more comfortable to describe it in actions and start interpolating towards the vision. Much like saying: “I know what I want and I’ll tell you when you get there”.

5.       Specialization

Most features in a game need a variety of different components in order to be completed. With a large number of competencies in a game team it is often hard to give a group of people the full ownership of a feature as a whole. The solution is then to identify the pieces of work required and focus on that rather than the value in itself.

6.       Feature weariness

One argument that can be made against completing features early in large game productions is the risk of waste. It is highly risky to spend too much energy early since feature weariness kicks in; the features that are completed first in a two year project will look very dull towards the end of it. Even though the customers have yet to see it the first time, the early features are likely to receive face lifts several times during the project. Not always for the better.

How to become more value-driven?

It would be a paradigm shift for most console game developers to change to a value-driven mentality. Thus it would be foolish of me to claim to have a solution to that in a post like this. I can at best share one small piece of advice that I think can help along the way. If the team starts looking at Time to inventory (in this case the time a feature spends in development) and works to reduce this time, a few things would probably occur:

Each of these components is a good step along the way towards a value-driven mentality.

(This post can also be found at http://www.hansoft.com/expertblog/valuing-value/)