03rd Apr 2007
Playing the game (#1 – Communication)
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.