Pull Schedule - everything?

So its commonly accepted that pull scheduling is efficient, quite a lot more than push scheduling. If we look at it from the information network perspective as I brought up here http://gamesartdesign.blogspot.com/2009/02/productivity-as-information-network.html previously it appears as if there is a general trick to it.

User Value and its derivates pulls development from the team. The derivates of user value is in this case stuff like product vision, strategy, audience, test feedback and such.The whole team process the User Value requests as a unit. Each team member is always ready to have information pulled on request from the team.

To avoid getting interference from management the team is likely to benefit from keeping track of progress towards the User Value derivates. Post it on a wall and update continously so this information dosnt become a burden to deliver.

Limits of art?

What message is beyond art?

This question is interesting on a general level. I would not directly label myself as an artist, maybe a musician or at least having had an income from writing, recording and engineering music. Everyone who is involved in making music has at least one leg in the artistic aspect of the art form. Even the guy who connects microphones to the recording technology is developing artistic skills. Once you leave the making of music and go to the business of selling music some people quit thinking they are artists, but really they are also involved with delivering the message to an audience, which is of some relevance to the experience of listening to the music.

I would believe the same can be said about movies, books, comics, oral tradition and everything else, and… games.

I can imagine quite well how to use music to convey almost any type of message. The exact meaning will be relatively irrelevant but the topic is up for grabs. The market for music would probably not be interested in paying for an opera about riding the bus, unless it is made by someone who is generally interesting for some other reason than the particular piece of work in question.

The same can be said for games. You can make a game which conveys a message about being a tree, it is not likely that the game will accurately make the player feel like a tree but I am sure a player can be made to identify with a tree. Raph Koster says he really wants games to be able to convey the feeling of being a tree, I don’t see that as very doable. But I do see a game where you pretend to feel like a tree, or maybe get to care about what the feelings you might have as a tree.

Is there a limit to the artist?

Does it require a Mozart to make classical music, or a young male to make a first person shooter? This really becomes more of an interesting topic when you aim at some specific resonance among the audience. I don’t see this as an existing restriction unless you try to impose severe limitations on the details of the production techniques involved.

Forcing Mozart to make a death metal song would probably not be a very good way to use his talent towards meeting a demand among a certain audience. However I am quite sure that Mozart would be able to entice this audience using more of his familiar tools if he put his mind to it. Well, back in the days. The direct problem with the game industry is that most have imposed severe limitations on their production techniques.

In most cases where you aim to remove these limitations you are quite likely to also remove every other chance of success you had. Understanding the abstract principles of making art is limited to relatively few people. This is also not an easily measured skill, its harder to use a theoretical measurement to measure a game artist than it is to use a theoretical test to measure the skills of a musician. Maybe someday this will change, but games will require a heavier effort than what it took to bring music to a level of theoretical measurement of accomplishment. Lucky us the productivity of the world has increased a bit the last 500 years or so, maybe I will see this development happen.

Productivity as information network

There are some great descriptions of how to achieve productivity around the web. A culled list of things which the more enlightened models seem to agree on looks like this:

1. Measure productivity in market value change, often derived from user value.
   
2. Maintain a special interest in anything you did which has negative market value so you can remove it.
   
3. Avoid anything which reduces your efficiency towards creating value in the future.
   

This list can be described with other words:

1. Test the production output before attaching it to the product.
   
2. Handle all kinds of defects consciously, from bugs to bad ideas and everything in between. Lean says; stop the line quality.
   
3. Never sacrifice product integrity to increase productivity.
   

To achieve positive productivity and develop market value there are several techniques in the production toolbox which probably are more or less familiar. There are lots of bad or outdated techniques which have been tested and found to be bad such as working over time, measuring productivity in code or features and developing towards a rigid specification. These bad ideas are not that interesting, but it happens that even a modern team fall in their traps.

The interesting things happen on the good idea side.

• Team size limits
  

Team size around 7 members. If this is because our brains are good at chunking the function of each team member, because biological networks get saturated with communication if nodes recieve information from more than 7 sources, if it is for some other reason such as creating a temporary family or that this number is about where you can find all relevant disciplines for creating user value I don’t know. The good thing is that it (the reasons) does not really matter.

• Responsibility distribution
  

The team, not a boss, determines how to create value within given constraints. Scrum does this partially by defining goals which the team convert into tasks aimed at realizing the value of a time box. Lean appears to approach this through something I recall as “on demand production” via pull scheduling the development when the market demands it.

• Understanding of User Needs
  

The whole team understands what the product aims to be and how it aims to meet a demand. This often shows up as a transparent product vision and the methods used for testing user value where the whole team is involved with understanding the needs and problems of real users.

The whole business as a biological network

I will now make a very poorly grounded statement:
- The whole business is a biological network with nodes made out of humans.

This network exchange information about what needs to be done to satisfy a market with the goal to make a profit in money or sometimes a less direct unit such as “cred” or brand awareness.

Biological networks are relatively well documented on a scientific level. I am not well informed on the subject but there are some properties of biological networks which even I understand and which may be interesting when optimizing information flow towards meeting market value.

• Information degrades every time it passes a node.
  

The network specializes towards dealing with certain types of information. Common specializations are to improve short range communication at the cost of gimping long range communication. We cannot, for example, well understand the emotional stated a source node which is at some distance and emotions carry a lot of information.

• The cost of relaying information across the network affects the amount of information relayed.
  

If I understand this correctly we humans have learned that communicating information across several nodes is close to impossible. We end up either limiting the message to something insignificantly small and useless or we end up saturating the network with protocols which becomes needed for the information to survive its journey through the network. Btw, such measures does not work very often. When implemented they provide a structure for social mobility and people create links when communication is needed.

• Node failure is random
  

A node which gets swarmed with information will fail to operate properly. This causes some hesitation towards accepting information among hub nodes. The practical effect is the same as above, the network limit itself to avoid non-random node failure.

It looks like the good ideas of productivity are natural adaptations towards optimizing the biological network.

• The product vision is integrated with the team.
• Defects are seen by the whole team.
  
• The actual user value is measured directly by every team member.
  
• The decisions on how to react on feedback are determined by the team.
  

Relevant information for the team is at most 1 node distant.

• Constraints are negotiated between the team and the client.
  
• End users deliver feedback directly to the team.
  

The interesting part here is that I don’t see much other organizational structures having taken on this approach towards optimization. They probably have a slower darwinistic evolution cycle, while software development productions often mutate several times per year. Lots of large organizations appear to try strong arming their biological networks to work as digital networks and actually go ahead with implementing communication protocol rather than reorganize the network to fit naturally with our human senses. (Hello email rules and conventions.)

The infrastructure problem

If your user value is heavily dependent on large infrastructure, such as a nuclear plant and a power grid I would not guess if this type of optimization scales up. It would appear reasonable to think that you can scale the production of such a large system efficiently by optimizing the information network to fit the properties of the biological network which build these kinds of things. You will probably get a few layers of abstraction between the development team and the actual user value, defects and future velocity.

This little post should have had some nice images with it. Maybe I'll update it someday if it still makes sence in the future.

User Value measuring is art, craft or science

Measuring user ualue can be considered to be more or less scientific. There are arguments for the scientific approach, but there are also arguments for an artistic approach especially when the values you need to measure are subjective.

There are some parts of user value you definately can measure with a scientific methodology, if you can do so it makes sense to use the available scientific methods. Most common entertainment productions will usually not have this ability readily available. Using an artistic approach towards measuring user value would in my book be the last resort, and whenever going down this route expect a lot of failures.

>skips past what a craft is.

The measuring of user value appears to best fit as a craft.

User Value, by looking at users

With a definition of design fully focused on creating user value it appears important to have a decent understanding of what user value is. The most important aspect is that it needs to be something you can measure.

The first and most useful method comes through looking at and listening to users, or testers who reasonably well represent users. This method is a bit ugly because it will not give you much hard data. The lack of hard data will inhibit the ability to communicate the result to anyone without insight into the actual test itself. People you need to communicate the result with will have to trust your interpretation of the behavior exhibited by the user during the test. You are already fully loaded with test analysis hardware for this particular type of test, use it. We’ll look at methods for scaling up this type of test later but for now think small.

You can start measuring the value of any design as soon as you can find a test subject. A good start may be to talk about the idea with someone. This is extremely cheap, but the test output is very unreliable. However if your design gets shot down by such a primitive test then go back and start over. Or adjust accordingly, possibly by replacing the test subject with another tester.

If your cheapest test is successful it might be time to invest a bit of effort into the design process. What kind of investment you will benefit from depends a lot on the idea itself and your own skills. At this point I tend to find myself needing to develop my own understanding of the idea which is getting developed so I sketch up a series of takes on the idea. If the idea is associated with a game type of product or if the idea is the whole game itself I tend to find a primitive sketch of interface components to be a decent start. This helps me get a better grip on what actions the user should be taking. The end result does not inherit any particular components from this simple sketch, but it gives me a better fundament for testing the idea on more test users.

If the idea survives this far and if it is simple enough it is time for a functional prototype, some paper prototyping is a good idea to start with. If the idea has a close relative implemented in an existing product you can look at altering that product to fit the idea or if you got plenty of time and access to the right skills develop a prototype in code. However most ideas are critically dependant on the value of other ideas, after you got the first idea to the point of where you can invest some time in it you are likely better off measuring the value of the other ideas which it depends on. Take your time and go through each idea until you have collected a firm picture of all the relevant ideas and their individual value before promising any end result to anyone.

Keep in mind that ideas are cheap, plentiful and most often bad. Avoid promising that an idea has value until after you have verified its value against a decent representative of users. By continously measuring the things you do against test users you increase your chances of designing successfully. When you fail to get a successful test from an effort you have produced waste.

Approaching Design as topic

From what I can find there is no common description of what design is. There are quite many different definitions around the web and several additional ones if you look through books on the subject.

Let’s have a look at the better candidates of what I found by googling the topic.

As a verb one definition I like is “to plan and make (something) artistically”. As a noun there are other good ones such as “an ornamental pattern” or “the arrangement or features of an artistic or decorative work”. These speak about the artistic nature of the word which is highly relevant.

Another way to look at is through formal definitions. A good one by Dick Buchanan who is a professor at Carnegie Mellon University School of Design says:

"Design is the human power to conceive, plan, and realize products that serve human beings in the accomplishment of any individual or collective purpose."

This is nice. It takes into consideration the human component in the creative process and in the perspective of the end user. It also, the way I read it, takes into consideration the realities of turning an idea into a product. This is a useful insight but I rarely find it to be properly attached to design in particular and more associated with product or business development in general, where design is of relevance but not the primary responsibility. I can't claim to understand what the last third of the definition really means, “in the accomplishment of any individual or collective purpose”. Maybe it exists to exclude that which has no purpose. Maybe I should take some time and study the topic in question rather than ramble on about it.

Despite the fact that I like this definition by Dick Buchanan as well as some descriptions of the meaning of the word design I don’t find them useful to serve the purpose of approaching the everyday problems of designing products.

Instead of spending a lot of time to find a definition which works for me I’ll make my own. I want a definition which is useful when describing what I do. Which also brings out the kind of goals a design effort aims to meet. It would be nice if the definition also is easily understood by normal people. A definition made for specialists may be helpful when digging deep into the problem but a definition suitable to the topics I intend to dig at with this blog needs to be relatively simple.

My definition of design becomes this:

Design is a process that realize the value of an idea.

Is this enough, or is it too wide? A potential point of failure for this definition is the concept of “user value”. This definition becomes all about user value, but it excludes the conception of the idea. Unless the idea is to come up with a valuable idea in which case we can apply the design process to develop the idea in itself, messing around with paradox is not a hobby of mine so I’ll quit here.

If I am lucky someone will come along and shoot this definition down before I get horribly entangled with it. Next topic might take a closer look at user value in particular.

Blogostart

So this blog is started. I don’t have much ambition with it but the idea is to collect various thoughts about designing games in one place. Alright, this is not a very novel idea and there are a lot of great game design blogs out there. I don’t expect to add any value to the game design blogosphere with this effort. All I expect is to collect information for myself.

If you happen to come across this blog feel welcome to make comments.