Tuesday, 9 August 2005

Winning on a Level Playing Field

Competitive bowling is an interesting game. Each player throws a ball the same distance to 10 identical pins. A player becomes a professional by knocking over all 10 pins consistently. This level playing field makes bowling one of the few sports where winning is screwing up less.

Watching some back episodes of the Amazing Race, I was reminded of bowling. For the unfamiliar, the Amazing Race pits a dozen teams of 2 against each other in a race around the world. At any moment, a multi-hour lead could vanish as all teams await the same train.

It doesn’t take the Bowling Moms to see the similarities between the two games. In the world of economics and game theory, it feels like complete information.

Seems to me, there’s 3 lessons for winning on a level playing field:

  1. Believe in the strength of your competitors.
    If all the competitors weren’t equally skilled, they wouldn’t be playing and the game wouldn’t be any fun. If Joy’s Law (“the smartest people work for someone else”) applies, then the most talent players aren’t even in the game. I remember a college football coach (though not his name) known for praising the losing team.
  2. Sharing is better than not.
    Bowlers and the Amazing Racers operate in parallel with each other, one player’s progression doesn’t necessarily mean a competitors recession. The next gutter ball or compass mis-read could even things out again. It’s actually in the players’ best interest to share information. The value of information is subjective – so sharing garbage and sharing wisdom costs the same. Sharing puts the focus on the game, not sharing puts the focus on what an ass the non-sharer is.

Tying 1 and 2 together, it’s nice to double check the competitors are trying to win the same game. Rob and Amber were trying to win Survivor a second time. Apple went for simplicity, Microsoft for ubiquity.

I should dust off my game theory books.

Tuesday, 30 November 2004

How to Stifle Teamwork – Part 2

“Rating and ranking engender competition, not collaboration” – Esther Derby, An Alternative to the Yearly Performance Review

I always felt annual performance reviews existed for disconnected management to reinforce hierarchy. To know that their prime purpose (in employees’ minds) of securing an individual salary increase actually incents people to not collaborate is doubly disheartening.

Compare this individual-focused structure against a work environment where: everyday at 10am the entire team, manager and all, meets for 15 minutes to review the previous day and prepare for the current day.

That simple, regular, act promotes collaboration among the team members and an engaged, connected manager.

In this new world, how do you determine an individual’s salary? The same way you did originally, compare what they’re doing against the market.

Sunday, 3 October 2004

Yes, and – not But

Improvisational comedy, like all team sports is about effective, high-energy, spontaneous collaboration. One of the seven major tenets of Improv is building off each person’s comment and suggestion with “Yes, and…” rather than dismissing it with a “but…”.

“Yes, and…” extends, explores, and enhances the previous suggestion – building trust among all the team members, moving the entire team closer to a successful solution. “But…” stalls the conversation. Cold. Even worse than dismissing the initial suggestion, team members are now second-guessing their solutions to the problems for fear it will be destroyed by the next “but..” This provides a disincentive to solving to the current problem. Turning the team and project into the stagnant, stereotypical office meeting blah. On a related note, questions frequently have a similar effect on teams – see Stop Asking Questions.

In working with different teams, I’ve heard “but..” used in 3 major ways. Though each usage may not contradict the preceding statement, it does stall the conversation and turns a peer-to-peer collaborative opportunity into a unequal power play.

    The 5 Breeds of ‘But’:

  1. “I have information you, the ignorant peon, didn’t consider.”
  2. “A different team tried that under different circumstances, so it won’t ever work.”
  3. “I don’t want to do and don’t actually want to be involved in this project.”
  4. “I have something off-topic to say, and don’t know how else to make my opinion heard.”
  5. and my own personal favorite:

  6. “I completely agree with you and want to take credit for your suggestion.”

    Here are 3 tips for transforming a serial “but” into a ‘yes, and’:

  1. Firmly focus on starting a solution.
    The final solution is rarely needed immediately. An initial starting point and direction will go far in gaining forward momentum. This means any solution is viable, and the objection raised in the ‘but’ can be addressed when it arises.
  2. Question specifically how the ‘but’ affects the situation at hand.
    This is a simple and effective way to specifically identify which one of the 5 breeds of ‘but’ you’re dealing with.
  3. Force the ‘but’ into a solution
    For often entertaining results, have the offender, repeat the statement back substituting ‘yes, and’ for the offending ‘but’.
  4. Completely ignore the ‘but’.
    There’s a fair chance, the objection is a defensive reaction to a fleeting situation. This is especially true for a #1’but’.

Wednesday, 11 August 2004

Want Better Collaboration – Improvise

The earlier collaboration techniques post (Stop Asking Questions) was based a key to successful improvisation. This post digs further into the relationship between improv and collaboration.

Good improvisational comedy teams believe a group of individuals working together can start with nothing and quickly create something engaging, desireable, useful, and valuable. From this perspective, the keys for successful Improv apply to any collaborative effort.

As such, there are 7 keys to successful improvisational collaboration:

  1. Acceptance of a new idea from the standpoint of exploring its possibilities; An attitude of “Yes, and” rather than the destructive “but” .
  2. Attentive listening to all the partners on the team.
  3. Temporary suspension of critical judgment.
  4. An attitude of relaxed openness to new ideas. Exploring the far reaches of “What if ___?”
  5. Reframing situations to explore creative possibilities.
  6. A willingness to take chances, to risk appearing foolish, i.e. Stop Asking Questions.
  7. An understanding that no choice is absolutely right or wrong, though each may turn out to be more or less productive in a given situation.

Thanks to the Applied Improvisational Network.

Sunday, 1 August 2004

Want Better Collaboration – Stop Asking Questions

The first step to a collaborative environment is to banish questions. Yes, banish the question mark from all conversation.

Questions reinforce heirarchial relationships rather than build the peer-to-peer relationships necessary for innovative, effective collaboration.

Step #1. Everyone is smart and everyone’s knowledge is of equal value.

A question forces someone else to make something for you.

Step #2. You can create things others find valuable.

Thursday, 29 July 2004

Only Pigs Can Talk

I’m reviewing an excellent presentation [pdf] on the agile software development landscape when two bullet points on Scrum’s daily meetings stopped me:

  • Chickens and Pigs are invited.
  • Only Pigs can talk.

It took Googling to decipher the metaphor.

Though it goes against my earlier stifling team work post, identifying who’s involved and who’s committed is an excellent way to focus energies and keep the project on task.

Take a look at your projects – are you involved or committed? Where can you be more committed and less involved?

Further in the presentation:

“The error [is] typically 100 times more expensive to correct in the maintenance phase than in the requirements phase.”- Software Engineering Economics.

Reminds me of a story in the automotive design world. Traditionally, automotive designs were modeled in clay. Clay hardens as time passes. So, the longer a decision was put off, the harder – literally – a change is. Just because software doesn’t have a physical manifestation, doesn’t mean it’s not as time-sensitive as clay.

Two final bits of insight from the Extreme Programming camp:

  • If the future is uncertain, don’t code for it today.

  • Do the simplest thing that can possibly work

In other words: Do as Little as Possible.

Thursday, 22 July 2004

A French Hour Sprint

Your new project is scary – though isolated and contained, the timeline ridiculous, the deadline immediate. The team is understandably nervous. What’s the easiest way to success?

Institute French Hours – or what we’ve (until now) called a Sprint.

Here are the 4 rules of French Hours:

  1. You can’t do it all the time.
  2. Every person must want to do it, and there must be an alternative job if anyone chooses not to.
  3. Everyone on the team has to be reminded of the uniqueness of the situation (and the team) on a regular basis.
  4. You have to stop.  All at once.

These rules are carved in stone. If you’ve been through one – you know that. If you haven’t, I’d highly recommend it – the speed, the straight-forward deadline – they’re refreshing projects. Just keep the 4 rules in mind.

Go pick up the August 2004 Fast Company and get the full story.

Monday, 12 July 2004

Usability Not Usable? – Part 2

“People are usually not receptive to a newcomer waltzing in and telling them they’ve been doing their jobs wrong.”

Usability departments exist in a number of our client organizations. Unfortunately, their organizational structural frequently instills an adversarial relationship between the project teams and usability group. The usability group is considered an outside agency – ony evaluating ‘ready for prime time’ work.

This relationship places the usability professional in the lose-lose position of telling the project team their baby is ugly.

Here are 3 tips for making this process more valuable for everyone:

  1. Invite everyone in all the project meetings from the start. This includes developers, usability professionals, project sponsors, clients, and even a customer or two. (and make the meetings working meetings)
  2. Evaluate early and often. The earlier in the project customer insight is captured, the more valuable is it to the project (and the customer). The project is less malleable as time progresses, more decisions (good & bad) have been made, more constraints exist. Everyone learns from early evaluation.
  3. Create, don’t just destroy. Usability evalutions are most valuable and insightful when participants are offered alternatives to compare. Perhaps alternatives don’t exist for the initial evaluation session, but they surely exist for each additional. To make the most of the evaluations the learnings from each session to the next participant in the form of a rough prototype.

The quote beginning this post is from from Ester Derby’s article Change that Fits. Her story describes a recently-fired software development quality engineer. Usability professionals should heed warning.

How to Stifle Teamwork

As an appetizer for an upcoming Work Better article on collaboration techniques, I’m pleased to present these team work worst practices from Ester Derby’s Software Managemet Process Improvement weblog:

A clear strategy to stifle teamwork

Establish two classes of membership on the team [WP NOTE: i.e. developers and testers, employees and contractors, or people with technical focus and people with business focus] , then follow these steps to ensure that all are aware of the distinction

3) Hold meetings to discuss project business, and exclude the 2nd class team members. If they ask to attend, tell them the meetings are to discuss topics they don’t need to know about… or say “This is meeting is only for 1st class team members.”?

4) Swap in new 2nd class staff frequently (2nd class team member are fungible, afterall, unlike more important 1st class team members). This is a double-header strategy – it slows down progress, too!

8) Blame the 2nd class when the so-called team fails to work together effectively…“They just don’t understand how to work as part of a team.”?

For all 8 helpful hints, visit A clear strategy to stifle teamwork.

As illustrated by this article, teams are about quality interpersonal relationships. If the office culture doesn’t support building collaborative relationships – failure is imminent. For the project, the team, and the organization.