Pretty much all organisation run social “team-building” activities, from informal drinks, team/office parties, to more formal off-site adventure course type events.

The idea is that this will develop social cohesion and allow personal trust and favours to smooth over bad or unclear work protocols.

When I think of trust in a work context, I break it down into two aspects:

1. Competence: Do I trust that the person is capable of doing the work?
2. Expected behaviour: How do I trust the person will behave?

Will a non-work-specific social activity develop trust in work-specific competence?  Does a person’s behaviour in a non-work-specific social activity develop trust in their work-specific behaviour?

It seems reasonable that some aspects would transfer but surely not all of it would be relevant.

Does a focus on socialising discourage diversity?
Even if trust actually does transfer from social to work contexts, if we couple team membership to ability to socialise outside of work, does this act as a force towards team homogeneity?

Imagine that instead of focusing on socialising, we focus more on developing our trust in mutual competence (practicing together, actually working together) and developing our trust in expected behaviour (agreeing on team interaction protocols).  So even if I hate the person, as long as I trust s/he is competent and we both have agreed to interact in a particular way, then we can work effectively together.

The consequence is that now we are not limited to only working with people we like socially.

What happens with the diversity of an organisation when we change the balance between personal trust and protocol trust?

As an Agile advocate…


…have you noticed that you’ve had to explain the same concepts repeatedly?

In many of my engagements I find myself having to repeat explanations of certain concepts, primarily Agile and Lean concepts, but also technical or business concepts. The most effective, sticky explanations tend to be a combination of a sketch and a narrative about the concept.

Would it be useful to have pre-prepared props to help with these kinds of situations?

I learned about One-Point or Single-Point Lessons from the Lean community. The basic idea is that developing people should be a continuous process; instead of teaching a whole bunch of things at once, teach one concept at a time (aka one-piece learning vs big-batch learning). In order to do that, create lessons based on a single point, typically on a single piece of paper, which is then reviewed during the daily meeting.

What would a good One Point Lesson look like?

• Useful Prop: When a situation arises during an engagement, you will have a prop to hand out and reference to tell a compelling, sticky narrative around a single, useful concept.
• Memory Trigger: Having a set of one-point lessons is a nice way to remind you of what might be a useful concept to introduce to the current context. This is similar to IDEO Method Cards.
• Development Tool: For the less experienced, a set of one-point lessons provide a way to learn about what kind of concepts they are expected to understand.
• Social Object: One-point lessons, if they are cool enough, are something that people will want to put up in their workplace. They are something that invites others to ask about, to start conversations about.

An example:

Notes:

Typical approach: get everyone to think the right way -> values and attitudes change -> naturally start to do the right things

NUMMI approach: start with behaviours (aka what we do) -> values and attitudes change -> everyone thinks the right way

“Define the things we want to do, the ways we want to behave and want each other to behave, provide training, and then do what is necessary to reinforce those behaviors. The culture will change as a result.” John Shook

“It’s easier to act your way into a new way of thinking than to think your way into a new way of acting” (Millard Fuller, founder of Habitat for Humanity)

“Act the way you’d like to be and soon you’ll be the way you act.” (Dr. George Crane)

Edgar Schein’s (coined phrase “corporate culture”) definition of culture:

“The pattern of basic assumptions that a given group has invented, discovered or developed in learning to cope with its problems of external adaptation and internal integration and that have worked well enough to be considered valid, and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems.“

References:

• How NUMMI Changed Its Culture – John Shook 
• Change models: Shook, Schein, Dreyfus and Constructivism – Allan Kelly

When talking about motivation, many people will reference Drive with its three key factors:

• Autonomy
• Mastery
• Purpose

Once again, Frictional Games is hiring and this time we are looking for an environment artist. The employment will first only be a on project basis lasting about 6 – 8 months, but if all goes well it can go be turned into a proper employment.

Introduction
I just stumbled upon Raph Koster’s “Narrative is not a game mechanic” and found that it contains some stuff that I do not really agree with. Now, thinking somebody on the internet is wrong happens all the time, but I think this article brings up some stuff that warrants a reply. While it has up a few good points, it also contains views on a few concept that I think can be quite damaging when trying to expand upon the medium of videogames.

“Game”
The word game is a very broad and fuzzy one. I can refer to boardgames, gambling, politics, drug dealing, sports and whatnot. For more part of the the article, Raph seems to be talking about videogames (given the black box analogy and that he specifically says “racing videogame”), but then later on slot machines and choose-your-own-stories are used as examples. Now one can see this as just using simply making a point, but I think the unclarity leads to an important issue: Videogames are very different from other games like chess, football, etc even though they are often lumped together.

The main reason why videogames are different is because they strictly impose rules upon the player. It is not really possible to play a videogame wrong, whereas playing football or chess (the physical versions) the wrong way are very easy. A videogame is more than a few game-rules, it is every single rule that you can possibly experience. Even basic laws of nature like friction and gravity play an essential role in a videogame. Videogames are not about following a specific rule-set, they are about being present inside a virtual world. The only way to really play a videogame incorrectly is to change the very fabric of its virtual reality, or to find some kind of exploitable flaw. (This is not strictly true, as one could say playing Mario and only running back and forth the first few pixels is not the correct way to play it, but I think I make my point).

In case you want more discussion on this, Chris Deleon goes into the issue a bit deeper here. My main point here is just that when discussing videogames, it is very common that all other kinds of games get thrown into the mix, and that is exactly what happens here. This does not mean that we should try and learn from other kind of games, but when we want to talk about the strength and weaknesses of our medium, we need to be clear what it is we are really talking about.

(I know I do say “game” when I really mean “videogame” from time to time. I hope I have become more clear on what I mean in later posts though. Also note that I sometimes simply use “game”, after having just said “videogame” to make the text less repetitive. With that said, I hope I do not get too hammered because of improper usage )

A series of problems
This is something that have annoyed me for some time. It is the idea that videogames must pose some kind of challenge to the player. It leads to all kind issues, most importantly the idea that one needs to have trial-and-error in videogames. In my mind it is this kind of thinking what has been holding back videogames for quite some time.

In Raph’s article, this thinking is best exemplified by:
“Cut the problem inside the black box, and you have a slideshow.”
Once you get into this kind of mindset, I feel that there is so much you are missing out on. For instance, Amnesia would not have been possible to create if we had not let go of the belief that every meaningful interaction must have some kind of problem and challenge at heart. It is also a statement that makes videogames like Dear Esther impossible to create. It even dismisses a lot of what makes Silent Hill so great as bad videogame design. Needless to say, I think this is a very silly statement to make.

My view on the core of videogames is not that should to provide us with problems, but to immerse us in engaging virtual worlds. Sometimes problems are useful for doing this and sometimes not. But they are never what lies at the core of the experience.

Feedback is for fun
The way the article talks about feedback (graphics, sound effects, etc) is in a very simplistic manner: They are simply there to enhance the underlying mechanics. I believe that feedback, in any sensory form, can be a lot more than that. I think that visuals, etc can lie at the front and the mechanics can be a way of exploring them, hence you tweak the gameplay according to your visuals instead of the other way around.

Instead of seeing feedback as rewards for problem-solving, I think we should see them as a way to increase the feeling of presence in our virtual worlds. It is the ability to “kick back” that makes the virtual worlds of videogames so compelling and so different from other media like novels and film. If we see feedback as a tool of immersion, we can also stop seeing all interaction as problems. I think this brings forward a more inclusive view of what a videogame can be and is also much better at forming a platform for evolving the medium than the old narrow view.

“Narrative”
I think there is a quite a confusion with words in the article. Narrative, in film theory, is how the story is told (how characters and plot are put together). When Raph talks about narrative in the sense of choose-your-own-adventure games, he is really referring to the plot. It is not narrative, but plot (ie some very specific events), that act has the reward for the player whenever they provide input.

It is much better to say that narrative is the subjective entirety of the session. This also goes along with Chris Bateman’s view that all games tell a story and more interestingly that all art are games of some form. One could also take the view (which I do not) that narrative is, like in film, the way in which the story (plot and characters) are told, in which case narrative would be an umbrella term for game mechanics. In any case I do not think Raph’s usage of the word is correct and a better title for his post would be “Plot is not a game mechanic”. By saying it this way, I think the main point gets no stranger than “animations/sound/etc are not gameplay mechanics”.

This might seem like a useless discussion in semantics, but I honestly think it is quite important. Right now, story, plot and narrative are mixed up to mean pretty much whatever, making discussions like “should our game focus on story” pointless. Language is our main tool for thinking, and if we cannot have a proper terminology, we will not be able to think properly.

The article’s example from Batman: Arkham City is to me a very clear example of this kind of bad thinking. By saying that the “video of the Joker playing on a television set” is a narrative element, but then dismissing the entire climb that came before it as such, one is really missing out on the strengths of the videogame medium. For me I the Joker video is pure plot, a bit of needed exposition and not what is interesting. What is interesting is the climb up the cathedral. Here the player takes on the role of becoming Batman and, while performing interactive actions, forming a very compelling narrative.

As I have written before, in order to improve story-telling in games we need to consider stories beyond their plots.

End notes
Most of this post has been about meaning of words and of how to approach some concepts, but I hope that I still showed that it is a very important issue. Videogame is a medium that have grown from simplistic simulations, arcade machines and boardgames. This legacy has put its mark on a lot of nowadays thoughts on design, many of which are holding the medium back. The only way to move forward is to reassess this line of thinking and remove ingrained preconceptions of what a videogame is and needs to be. Not until we break the bonds of the past can we freely explore the future.

One of my favourite concepts from The Personal MBA is The Five Parts of Every Business:

• Value Creation - discover what people need or want and create it
• Marketing – attract attention and build demand for what you’ve created
• Sales – turn prospective customers into paying customers
• Value Delivery – give customers what you’ve promised and ensure that they’re satisfied
• Finance – bring in enough money to keep going and make your effort worthwhile

It occurred to me that for any business that survives long-term has to have another part:

• Human Development – develop people to be better at the above

As long as IT Operations is in constant fire-fighting mode, there can be no significant improvement.  To help shift from a tactical to a more strategic focus, I find it useful to create a True North.

True North is about answering the question:

If IT Operations was perfect from the perspective of your customers, team members, and stakeholders, what would it look like?

Note that True North doesn’t even need to be actually achievable because the purpose is only to provide direction.

What to do:

I’ve found that determining a True North tends to be just a discussion.  Preferably all of IT Operations participates but at least leaders and influencers should be involved.

It’s also useful to understand what industry leaders are capable of such as Etsy, Amazon, Netflix, Flickr, etc.

The IT Operations True North should be aligned with the larger organisation’s True North but that may or may not exist.  Do the best you can with what you do have.

Example:

See also Toyota Kata and Getting the Right Things Done.

For Agile / Scrum / Kanban advocates, questions about Waterfall vs Agile, Scrum vs Kanban might seem quite important and essential.

Just remember that most people don’t actually care.

What we consider problems worthy of blog posts, multiple tweets, and e-mail flame wars are actually quite unlikely to be problems that most other people consider worthy of even thinking about.

If you want to help people, remember that your ideal is not their ideal and your problems are not their problems.

Instead… try understanding what their ideal is and therefore what their problems are.

People don’t know what you’re doing.

This is especially likely for non-technical “business people” but there may even be a large number of developers that have very little familiarity with what happens in operations.

The consequence of this is that there is a tendency to treat the operations team as if it’s a magic bucket with unlimited capacity.  If I don’t understand what they do, then they’re probably not doing anything.

To deal with this, you need to make the work, which is naturally invisible, visible.  One way to do that is to setup a kanban board.

An example kanban board
Imagine a board with the following:

The work would be represented by index cards that would be moved across the board as the work progresses through the workflow.

A key point to be note is the Do-Wait cycle that occurs in In-Progress.  The nature of operations work tends to exhibit this kind of phenomena where you do something and then you have to wait for a third party to respond.

The work is represented by colour-coded index cards based on the type of work:

Avatars are attached to the cards in order to communicate who is working on what:

If work becomes blocked, there is a blockage reason attached to the card:

If the work must be done by a particular date, that date is attached to the card:

Note that your specific kanban board can and probably should look different.

A few other examples:

Sysadmins Board from IT Ops Kanban: http://itopskanban.wordpress.com/sysadmins-board/

“Our first Kanban board for IT Operations and Support”, http://www.systemsoup.org/2009/12/our-first-kanban-board-for-it-operations-and-support/

Spotify operations kanban board: http://www.infoq.com/articles/kanban-operations-spotify

What to do

• Create your initial board with columns, avatars, etc. reflecting your understanding of the flow of work.  I would recommend that this first version should be kept simple.  Note that even if kept simple, you want to show what is actually happening NOT what you want to happen.
• Modify the design of your kanban board as you realise that it is not quite communicating correctly and / or as the workflow evolves