Corollary definition for design

If design is a process which develops the value of an idea. Then a corollary to this might be:

- Design is aimed at reducing waste.

Maybe this lean perspective is the source of the first definition but I would not know.

Erlang vs. Metcalfe

In the life of Game Designer we can get a better understanding for the concept of quality by combining two old and trusty mathematical properties. I have hinted at these concepts in older posts but I have put off writing this one for a while. I'll try and make it quick.

Erlang says that quality is 1 when something does what it is supposed to do when it is expected to do it. Things that do almost what it should do, or for less than all the time when it is expected to do it has a quality which is somewhere between 0 and 1.

Metcalfe´s Law says that the number of links in a connected system increases exponentially with the number of connected nodes.

At this point I'll introduce my own definition of antiquality.

Antiquality is what you have left after you subtract quality from 1. Such as if you have a telephone line which has noisy crackles for 0.6 seconds every minute of a phone call your quality is 0.99 and antiquality is 0.01. At this level the amount of antiquality in a simple phone call is not a problem to the user. Its a minor annoyance at worst.

The interesting thing begins to happen when you connect a bunch of phone lines to each other. Imagine the phone call as a conference call with all phones connected to all other phones. If one line crackles the crackling is broadcast to all the other phones. You don't need a whole lot of phones in this system before the quality level needs to be a lot better than 0.99 to get any kind of useful communication going.

When we look at games and other experiential constructions such as a brand, we as humans have the tendency to connect every bit of the experience with every other bit. Our brains are like a super network which categorize every bit of antiquality with every other bit of antiquality presented beneath the same symbolic structure. For any product which is more complex than the most simple of things we will quickly label the whole experience as useless antiquality, unless the actual quality is a true 1.

So how can you use this understanding to build a product with true quality?

That is a different story. But it begins with understanding what the product is supposed to do and when it is supposed to do it. If need be you adjust these parameters and you make sure your user is well informed about this framing or you will quickly be labelled as junk.

Agile Failures

There has been a lot of almost mainstream media whining about how projects fail despite using an agile development methodology. Lots of blog posts about how agile cause trouble and how scrum fails in companies.

This post aims to start a journey which looks at my perspective of this trend. The journey begins with looking at the businesses which invest in projects and we’ll begin with separating these into two major factions.

Faction 1: Profitable business.

The profitable business has found a way to reproduce a profitable sale. Steve Blank uses the phrase “repeatable sales model”. My interpretation of this is that there is a potential market value which is reliably converted into money through the business activities. The repeatability causes a reliable equation to play out where you have a high chance of staying on top of positive revenue through conducting very low risk maneuvers until the equation changes when you have the option to adjust to maintain your profits.

Faction 2: Not yet profitable business

The not yet profitable business has bigger costs than earnings. This is quite simple and includes everything which is not yet profitable. In many cases you can see a profitable business include portions of this in the profitable equation, for example by making design improvements or product line extensions. The more common scenario is however attempts at creating a profitable business out of an idea.

Now that we have these two major factions we have a tool for understanding several ways to achieve failures which will make any methodology fail. Since everyone has learned that the typical waterfall project is going to fail by default it’s not that interesting to talk about, but we’ll try and stick to general failures which can be blamed on Agile.

To predict how you will fail you can start with asking yourself: where does the money that finances the project come from? If it is financed by an already profitable business you have a particular case. If it is financed by venture capital you have another and if it is financed by yourself, often as some type of hobby, you have a third. Among these three candidates you have one in particular which spells uncomfortable failure louder than the others. The least loud failure is when you are paying yourself. No one expects success from a hobby. If you are funded by venture capital you are expected to fail about 90% of the time. No one is surprised when investments fail to find a return. The loudest failure is when an already profitable business invests in unprofitable projects. These also seem to be the ones which plays the blame game and tries to blame agile methodologies for their failures.

If you look at an already profitable business from a capitalistic perspective you would think they should not invest in a new “not yet profitable business” and rather send that money to their investors. But for various reasons they generally don’t operate this way but attempts to reproduce profitability in new innovative manners. These become complicated matters.

A profitable business has generally spent a great lot of effort to achieve their profits. As a game designer knows you will be conditioned by expending effort at achieving a goal. So the profitable business has been conditioned by its own success. This conditioning is cultural within that company. This culture tends to have an agenda which prioritizes protecting the profitable business against risks. The practical implementation of this protection is commonly called bureaucracy.

Bureaucracy causes risky product experiments to have such a great cost that they have to be cancelled before they reach the market. It is better to send the investment immediately into the trash bin than to use it to cause a potential harm to an already profitable business. This also has the benefit of creating plenty of work for bureaucrats who thereby can be hired to handle the paperwork.

Eventually this causes polarization within the company where creative forces such as marketing eventually is urged to brute force the bureaucracy to revitalize a now aged brand. They can see their market share slowly being poached by competitors. At this point in time the culture has set really well. The creative forces rally enough of a budget to overcome the cost hurdle set by the bureaucrats and begin their project.

Since times change and you learn that using “traditional methodologies” will cause failure this project must begin to work with an Agile methodology, they usually try to work with scrum.

The root of the problem here is that scrum does not remove the cultural conditioning which practically has become embodied within the bureaucratic parts of the company. There will be plenty of reasons to interpret the new project as a risk to the profitable business and thereby justifying interference.

I don’t know if there is any particular solution to this problem but I do believe that a better understanding of this structure will reduce the costs of failure for any business which is investing in any type of projects. And this is just the beginning.

To propose a practical solution to this I will recommend making investments into new business areas at a healthy distance from currently profitable businesses. Mere proximity might increase the cost of failure.

From my experience with scrum I interpret some of the rules as engineered to refuse interference from bureaucracy. These rules cause a kind of cultural power struggle within an already profitable business when scrum is introduced. Power is usually owned by the bureaucrats and scrum becomes the loser and an embodied target for the blame game.

Time

Writing posts gets low priority when many things needs to be done.