Tuesday, February 16, 2010

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.

Monday, February 15, 2010

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.

Wednesday, February 10, 2010

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.

Thursday, November 5, 2009

The Cost of Art Forms

This is a relative type of general production cost.
  • Poems are cheaper than Pictures
  • Pictures are cheaper than Music
  • Music is cheaper than Movies
  • Movies are cheaper than Games
Hence games are the most expensive art form, unless we consider architecture to be an art from but I don't think architecture belongs here. I kind of tried to fit "website" in this list first, but it isn't an art form, just a technology which carry these other art forms.

Games are the most expensive in this list. There is however a component of the structure that I ignored here which games exploit to reduce the cost per minute of entertainment which is recursion. You can't effectively reduce the cost of a movie by reusing the same scene or the same music. But you can effectively extend the duration of a game by reusing the same rules with only minor variations of the underlying data.

Wednesday, October 28, 2009

A General Learning of the whole Cat Team

This is a much simpler lesson than the hardest lesson of the cat team. Maybe you shall find it easier to grasp too.

Before the Cats got Lean and Mean
When the Cats were going through the last phases of kittenlife and almost had grown up they began training at doing work together. In the beginning they had a hard time getting anywhere. Ofcourse such young Cats are going to need to learn a lot of things along the way towards greatness. This is one of the things they learned early.

How to keep Cats busy with doing work
The cats sat down in a room together, looked at each other and talked for a while about what they are really good at. You probably already read the post about the team and know what their skills are. They got a lot of skills, and they made a plan to make sure all the skills are used as much of the time as possible. Wizzard Cat makes awesome Magic, Fixer Cat fixes a lot of things which appear to need fixing, Artist Cat makes much of the emotional Art and Expert Cat makes many great plans.
Working with this plan the whole Cat team made themselves very busy. They worked late nights, they made marvellous things and they had a lot of fun. They kept up this production for a long time since they knew it takes a long time to get any good result so they produced a lot of things.
After a few years the Cat team looked up and realized all the work they had done had resulted in nothing more useful than good times, practice and things. This is not a very useful result, what were the cats doing wrong?

Doing things rather than achieving goals
The Cat team had optimized the work effort for local optima. Keeping the team busy with doing what each Cat is really great at had caused them to fail at reaching the results with only can be met by Cats who help each other meet common objectives. This is an insidious trap which will catch unwary Cats who fail to maintain the discipline needed to keep the whole team focused on the most important objective, which for Lean and Mean Cat Teams is profitability.
By making sure all the cats are busy doing the things they are really good at doing they don't have time to learn about the things at which they suck. In this case they were sucking at setting priorities for the team and they failed to realize that what they were doing instead was waste.

The one trick which turned the Cats around
After realizing that the first few years of optimizing the work to do the wrong thing they turned the whole problem upside down. Instead of even worrying about what they are the best at they began figuring out what their product really needs right now, thereafter do that work together. They began testing their product against the userCats they were building it for and started to see that some things were decent, but most things were quite bad compared to what the Cats had though before they tested.
Now they were on to something. But there were some problems. Often they found that the product was full of bad magic which broke when the userCats tested it. Since Magic is what Wizard Cat does this made the other Cats scared that they would be unable to help Wizard Cat with fixing the broken Magic.

How the other Cats become assistant Wizards
The Cat Team of four cats, with only one Wizard Cat who needs to repair the broken Magic figured out what to do with the problem. The first bit is simple, the other Cats can make sure Wizard Cat is well informed about the symptoms of the broken Magic. The other cats in the team make sure there are userCats ready and waiting to test the new and improved Magic every time Wizard Cat finishes another spell. The other cats in the team can also help Wizard Cat with doing continuous exploratory testing and workshops to keep Wizard Cat really well informed about the value of the improved Magic.
When the problematic Magic is really badly broken the other Cats start talking to their friends to hear if any other Wizard Cats might have cast this spell successfully in the past. They dig up information and possibly seek out Greater Wizards who can help get the Magic in place. Since the other Cats sometimes can't do anything to be very helpful to Wizard Cat they begin spending more time together with Wizard Cat to learn how these Magic spells are cast. This makes the other Cats become low level Wizard Apprentices who will be better at gathering reagents which are more useful to Wizard Cat than what they otherwise usually produce.

Wizard Cat can not always be supported by the other Cats
Sometimes Wizard Cat also needs to be alone with his Spellcasting. At these times when the other Cats are unable to do anything else which helps Wizard Cat they have a few options. They can do some work on customer research and get better at understanding what type of product the market wants. They can do various planning experiments and test if they can come up with some neat solutions to the other problems the userCats have encountered while testing. They can even start sketching on something which is less important than the thing which Wizard Cat is working on. They can practice their skills at making tests or teaching each other about the deeper understandings of their methods.
They can even spend some time with the tools they use and build various little prototype things which in almost all cases are waste. But the practice is not waste so it has some kind of value. They can also do random things such as visiting their grandparents, have some coffee and get a bit of a tan. Someday in the future there will be room for Wizard Cat to enjoy these kinds of breaks when maybe Artist Cat gets stuck with needing to fix broken emotions in the product.
On a general level the cats found that even in these cases where one of the Cat Team Members gets really stuck with the most important piece of work it is better to avoid trying to produce other work with the rest of the team while the big hurdle is overcome. The really scary part is when the stuck cat is totally unable to know if the problem even can be solved. If such an unpredictable situation happens the Cats might have to back off and change their idea about the product. But first after trying to solve the problem.
Maybe next learning is how the Cats figured out to avoid Broken Magic...?

Saturday, October 24, 2009

The first hard Learning of the Cats

This post begins a journey of unpredictable length which describes things the Lean and Mean Cat Team has learned along the way towards achieving significance within the games market. We will begin with the hardest lesson first, then possibly move on to easier ones later.

A hard lesson for Expert Cat: Mastering Perspective
This is a lesson about communication and understanding where one of the biggest risks with your product really lies. Expert Cat has gone through a life long journey to develop an understanding for this type of situation so it will not be a nice and easy lesson to describe. But we shall give it a try, Expert cat is whispering his s33kritz into my ear as I try to write them down.
This is what Expert Cat looks like as he is trying to convey this message for me to write down.
As you can see he is sitting next to little blue dots and lines which say Node, Link and System. This might not seem like something which is a learning, but it is a pillar of the most fundamental learning he wants to tell you about.
He says that in the beginning he thought about the world as if it was made out of Nodes. That means things which has properties in themselves. It is an effective way of observing things to treat them as nodes and it makes life for the Expert Cat easier on the surface. He can describe them and point at them and people who listen to him has a decent chance to understand what he is talking about.
Links are a bit trickier to understand. They are the connections between nodes which describe that the nodes are interacting with each other somehow. This is a lot harder for Expert Cat to at first understand, even harder to make use of and almost hopeless to describe. How do you describe that the car and the road are connected through a link, you cant see it? Maybe the tires are a link, maybe it is the driver which wants to travel who is the link or maybe it is the engine which make the tires turn with force. Expert Cat almost goes crazy trying to describe this to other cats.
Systems are a bit easier to describe but harder to create. Expert Cat can lump a car, a road, an engine and a driver into a clump of things which together are a system. When he describes the whole system to other cats they intuitively understand that they could make some use out of the ability to drive along roads to places at speed and derive some type of value out of it.

When Expert Cat was young
As a youngster Expert Cat wanted to do great things for the other cats in the world and began working on creating things. Since back then he was only really able to understand the concept of Nodes he went about and made things. Sometimes his things caught a litle bit of interest among the other cats but nothing really worked. What is wrong with my things? - he though a bit sadly.
No one really wants things it seems. Well, actually there are situations where thing are wanted but those are special cases which Expert Cat will tell us about later in this story.

Expert Cat is trained by Master Cat
After making a series of failed things Expert Cat went out looking for a Master Cat who would become a great teacher. Master Cat began training Expert Cat at using different perspectives of looking at the world and introduced Expert Cat to the idea of systems. The things Expert Cat had been making were failing because they were not part of a system which the other cats were part of. The things which had partial success had by a chance become adopted by other cats as pieces of their personal systems which are hidden in the mystery of cat souls.
Master Cat spent years and years and mentored Expert Cat to learn how to observe systems. About ten years after meeting with Master Cat our Expert Cat emerged as a fully trained systems observer.

A trained Expert Cat
To make things successfully our Expert Cat learned to create links. Sometimes links demand the creation of Nodes, and sometimes links demand other things. The core understanding of Expert Cat was to see that things without links are dead weight, waste and useless creations in general.
The next problem for Expert Cat is to describe what a link is. This is a fundamentally tricky problem because they are always different in detail but similar in the abstract. Since the details always differ we can make one detailed example and try to move onwards from there.

Details of a Link
Lets us begin describing a link. We will describe the link of Eating. We can look at something and notice that it is getting Eaten. A good start. Expert Cat wants to create the link of Eating.
To create the link of Eating our Expert Cat needs to become dependant on two nodes. One node is a Cat, who Expert Cat thinks will be interested in eating. The second node is a Fish which Expert Cat thinks has suitable fit for the occasion.
This is a deep understanding of the Expert Cat. The value in the system of "Cat eats Fish" lies within the interactive process which is commonly called eating. The value of the fish which is not eaten can be considered "inventory" which according to lean is a risk. From now on when Expert Cat make things he defines his thing as the interaction between the nodes in the system. The ten years of training which Expert Cat has contained a few weeks of trying to understand the writings of Guru Cat Chris Crawford who says the trick to creating games lies with defining the design from the verbs in the design. Expert Cat believes this argument says the same thing with different words. Expert Cat believe verbs are quite useful when defining links.

Creating systems through Links, Nodes or Systems
While training with Master Cat our Expert Cat learned a few other things about systems. Different types of systems require different approaches towards their creation. To avoid needing to write far too much text we will narrow the problem down to two extremes.
The two extremes are described by a Guru Cat called Steve Blank. He uses a model which is a useful framework to dig at this problem. He uses the words "Customer Risk" on one end and "Technology Risk" on the other. Then there are things which has both...
On one extreme end we have a system where the risk is the functionality within the nodes. At this extreme end we find things such as a Fusion Reactor. If you can get the Fusion Reactor to work as it should then you have your value right there. Infinite power for a low cost. We can define this value as its node. If it works it will also have value for the other cats in the world.
On the other extreme we have the taste of Fish. Does the taste of the fish which Expert Cat is creating have any value on the market? The risk here is not that the Fish has a taste, or even if the fish exist, but rather if the taste causes the cat to eat. How does the cat eat the fish? Oh noez! This is so complicated Expert Cat is almost trembling at the notion of describing the situation.

To describe the problematic description as hypothesis
We need to use another lens to look at the problem to get a perspective which has a better chance of succeeding. To create the correct taste when cooking the fish our Expert Cat creates a hypothesis that says: "The fish tastes good enough to make another cat eat it." This puts the link to the test!
Now our Expert Cat can cook the fish with an inventive recipe and try to make another cat eat it. He can modulate his test and see if he can make another cat pay for the cooked fish, and see which of all the cats are willing to eat it or not eat it.
By successfully describing his fish recipe as the properties of eating he has obtained the all powerful insight into how changes to the recipe influence the value of the system. Wewt!

Ok, so what does this mean in practice?
Our Expert Cat understands how to differentiate customer risk versus technology risk. When Expert Cat joins a Mean and Lean Cat Team he knows that his team will be more or less suitable to handle the different types of risks. A team full of scientist and engineering wizard cats is likely to be suitable for taking on technical risk, which a team full of marketing Fixers and emotional Artist cats is suitable for taking on customer risk. A team which has a healthy balance of both is likely to take on challenges which contain both types of risk.

Kinds of risks for game creating cat teams
This is a pretty big system which practically is rather simple to understand.
Games with some Technical Risk:
  • MMORPG's
  • Next Gen AAA Console Games
Games with Customer Risk (Everything else):
  • Flash Games
  • Web based community Games
  • Facebook Games
  • Marketing Campaign Games
  • Indie Console Games
  • Indie PC Games
  • Oldskool Games
  • etc
Note that no games that the Expert Cat think is a game has purely Technical Risk. Defining a game Hypothesis as Nodes is thereby almost a guaranteed failure. Alright, Expert Cat jumped over a long series of arguments to reach that conclusion, but his time is running out and he wants to get out of here rather than keep on telling us the details of this story.
Farewell Expert cat, enjoy the sunshine and the Fish cooking! *waves*

Fixer Cat comes in to finish the lesson and says:
- Lean and Mean Cat Teams that use Agile or Scrum to create games need to learn how to define their Backlogs as links. If they fail to do this and instead base their work on creating nodes they become statistical death marches. However, if you create an MMORPG or a Next Gen AAA Console Title you can use a bit of both nodes and links to deal with technical risk.