Kudos

“..real-time, multi-modal, 3dimensional, face-to-face communication with question and answer is the most effective way to transfer information and see that it was received. Two people standing at the white board, talking, questioning, drawing, maybe typing on the computer if that is the issue..”

Building on my last post, as I continue to explore Alistair Cockburn’s article on software development as a cooperative game, I want to address idea #2 – White boards:

As discussed in my previous post, for communication to be effective we must ensure that proper context is shared between participants of a communication process.

This assertion requires us to decide which communications medium is the most effective in transferring context. Alistair provides this list:

(Form of communication vs. effectiveness; (1) being the most effective) 

1. Two people at the white-board
2. Two people on the phone
3. Two people using Email
4. Videotape
5. Audiotape
6. Paper

[ I'd humbly add to this list: 2.5 instant messaging applications].

I’m assuming that some research went into the compilation of this list, but even without academic verification most of us will probably attest from personal experience that the ordering seems to be right. But, while it is easiest to convey meaning face to face, it’s the most difficult form of communication to archive for future use. 

Also, we need to make a distinction between ongoing communication during project development vs. planning and specification during project start-up.

During project planning  we want to make sure that all team members are up to date on the software specification, how implementation is going to be achieved and what key points have been included in decision making. The important point here is to make sure all members are up to date on the game plan. All too often, misconceptions are discovered when it’s too late, and entire sections of code need to be re-written.

To achieve this, Alistair proposes that, once design is finalized, the architect/analyst will hold a group session in order to discuss the plan and answer questions, using a white board. The session should be videotaped. Once it ends we can add markers to index interesting points on the video tape for future use. The tape will be attached to the design documents as a contextual reference, to be used by anyone who missed the session (like a new team member).

Using such a solution, we can retain the most from our face-to-face session (body language, tone inflection, Q&A, white-board) while maintaining archival capabilities. I might add that one could try to use tools like Microsoft’s OneNote which records the entire session while associating whatever you scribble on your tablet’s touch screen with the relevant audio, thus including one’s own thoughts while eliminating the hassle of manual indexing.

As to ongoing communications, there is absolutely no replacement for meetings. It is my experience that a single phone call can solve a problem that has been discussed over Email for a week, and a face-to-face meeting can clear obstacles that seem to be unsurpassable. I always keep telling people, talk to your customer. It’s interesting, but when a development project hits obstacles, people usually talk less to their customers (possibly because they don’t want to get criticized). So, here it is again – Talk to your customer, especially when you hit obstacles!

The other methods for communication are more orthodox, each having obvious pros and cons (Email lacks tonal inflection, which has gotten me into trouble in the past. Phone calls are hard to archive. Extensive written specifications are expensive to produce. Audio tapes lack visual cues). Each is easier to use in certain scenarios, and should be employed accordingly. The important note here is to remember that documentation is important. It is used for reference while communicating via “live” means with your team members or customers.

In the last two posts we covered context as a prerequisite for effective communication, and possible means for maintaining maximum levels of context when transferring knowledge. On my next post I will discuss Alistair’s next idea – #3 People are active devices.

I wrote a couple of days ago about Alistair Cockburn (pronounced Co-Burn, as Guy commented) and his theory of software development as a cooperative game.

The first idea Alistair explores is - #1 Communication.

Ok, sounds pretty obvious. When working as part of a team people need to share information and ideas. A developer might need to consult with his team lead for clarifications regarding a design document, a QA engineer will need to demonstrate a bug he discovered, a customer will want to convey feedback and so on (the list really is endless).

Here is a common scenario that most of you will relate to (feel free to modify in order to fit your business) -

Customer (complaining to project manager): We have a very serious problem. On screen umptz the system behaves lumptz and is green instead of blue. The system can’t go-live like this.

Team Lead/Project manager: Let me check with my people and I’ll get back to you.

At this stage the project manager pulls out the design documents and finds out that either:

(A) There was no reference to how the system should behave in scenario umptz

- or -

(B) There was a reference but it was interpreted in a different way than is currently intended by the customer (who might have changed her mind without realizing it. Seriously, happens all the time).

- or -

(C) There was a reference, and it was written accurately, but the developer didn’t get it.

At this point everyone get’s really annoyed, extra money is spent and customer opinion is adversely affected.  The project manager talks to the customer, trying to relate that during design she didn’t convey her assumptions and that, sorry, but he really needs to bill her for the extra work:

Customer: But it’s obvious. Screen umptz can’t be green. How could it possibly be green? It’s common-sense!

The project manager goes to his group manager and explains he needs extra budget to finish the job.

Group manager: PM, we have got to pull ourselves together! Why are our design docs incomplete? How could the developer miss the reference? How come we didn’t write the specs accurately? Now our customer could interpret it any which way she likes! That’s unacceptable! 

The examples above reveal a hidden assumption that usually escapes managers: effective communication relies on context.

You can’t write “complete” specs. You can’t write a document that will be clear enough so that a developer will always know what your intention is.

Alistair put it very nicely: “All communication is touching into shared experience“ 

In order to achieve perfect communication, you need perfect context. You need to have the professional and persoanl life experience of whomever it is you are communicating with. Which is why you’ll never achieve it.

What you can do is this: “manage the incompleteness of our communications”

Find out how to build a common base with your customer / developer / QA etc. Make sure you understand the context of the operation you’re managing. Make sure everyone on the team understands this context. When you achieve a common base, you will see why screen umptz simply can’t be green.

Effective management will create a composite of tools and policies to make sure that:

(A) Context is shared on an ongoing basis.

(B) Knowledge is stored in such a way as to be accesible to whomever needs it.

Most of us concentrate on (B), not realizing that stored knowledge is useless without the context that was present while creating it.

Of course, sharing context is a challenge in itself, and I will address it in my next post, which is also built on Alistair’s article and his second idea – #2 Using whiteboards. 

Euan referenced this post by Andy in his blog. I’m just copy pasting here:

“Imagine a machine that you can put into any country and when you turn the handle, generate jobs. Not regular jobs, but microjobs: short jobs that you can do at home are done and when you are paid you go on a short holiday and you have the certainty when there is another microjob waiting for you. That is living a la carte.”

Andy is referncing Pajamaproject as his example for a microjobs marketplace. I think Amazon’s Mechanical Turk is very similar, and could be expanded to include human generated jobs.

But comparisons aside, what I really like about the microjobs concept is that it makes me think of Grid Computing.

Grid computing relies on a master machine that delegates jobs to worker machines. The program is built in a highly multi-threaded design so that each thread could be run under a process on one of the workers. The master is in charge of delegating the jobs and collecting results. 

Sounds to me that’s how your normal workplace would function. You have a boss that delegates tasks to his employees. The employees work really hard and the boss takes all the credit. Maybe we’ve finally found a way to realize the work-from-home methodology that was so hot during the late 90′s.

What would it take to make a Human Grid? Could a Human Grid make the workplace obsolete? Will we all work occasionally from home, and spend our lives hopping from vacation to vacation, as Andy suggests?

I really hope so, but don’t hold your breath.

The reason workplaces have not fragmented into home based employement is because many corporate tasks require that employees know about the corporate’s:

• Cluture, ethics, brand and ethos.
• Infrastructure, regulations and policies
• Partners, other employees, competitors and customers

Also, there are many practical reasons, starting with Information Security and ending with access to hardware, applications and tools.

For example, I dont see any corporate delegating creation of graphics for it’s website to a transient home worker if that means the whole world can know what tomorrow’s marketing strategy is going to be.

Microjobs are cool, but if you’re looking for a career with the bigger companies don’t count on it happening just yet.

Unlike other expressions of the human capacity for tool making, computers are, perhaps uniquely, totally versatile in the sense that they can be programmed.

Computer programming is set on simple principles; 0′s and 1′s, on or off. From those humble foundations, springs complexity as layer after layer of abstraction are added, each designed to enhance our ability to utilize the one underneath.

When a programmer works on writing software, she usually does not dwell on the complexity she is creating with each line of code but , like art, no two pieces of software will ever be alike.

Software development is difficult to implement and a managerial challenge if ever there was one. It is a practical tautology that software projects neither finish on time nor on budget, while users are usually dissatisfied with the end product for some reason or other.

This behavior extends to IT. Generally speaking, the more versatile an appliance is (and thus more reliant on software), the more complex and uncertain to implement and maintain it will become.

This is very interesting because there are engineering tasks out there that are no less complex nor less monumental than writing software, yet are easier to manage in terms of risk; building sky scrapers could be one example. That’s because sky scrapers exhibit no emergent behavior.

Many smart people are addressing this challenge by thinking up new ways and creating new tools, to help managers tackle software projects. Probably one of the most interesting of those is Alistair Cockburn, who maintains that software development is most similar to a cooperative game.

I stumbled upon Alistair’s article about software development as a cooperative game (via coding horror), and it was absolutely fascinating. Only rarely do I read an article that leaves me saying “that’s right!” and “I can relate to this” and “damn, so true” so many times in one sitting. So before I go on – Kudos! to Alistair.

Mr. Cockburn’s article is a bit longish, yet packed with good material and is worth some serious discussion.

In future posts I will separately address, and add my own thoughts, on the points that are made in the article – starting with #1, Communication (here is a short excerpt):

“…The first thing to get is that no communication is ever perfect and complete. It just can’t be done. It is not even in the realm of possibility. Your listener, or the receiver of the communication, has to jump across a gap, at some point, and has to do that all on their own. You can’t do it for them. If they are very different from you, then they can’t jump a big gap. You have to explain some basic concepts to them, and then build forward until they build their own bridge of experience so they can finally get what you are saying…”

“The point is, we write these specification and design documents as though we could actually ever explain what we mean. And we can’t. We can never hope to completely specify the requirements or the design. Not even the faintest chance. When we write, we assume that the reader has a certain level of experience. If we can assume more experience, then we can write less. If we have to assume less experience, then we have to write more.“

“All communication is touching into shared experience.”

More on this to come.