Sharing documentation vs. documenting shared understanding

We do not share documentation to create outcome. We create shared understanding and then we document it.

This short statement pretty well summarizes how we work. And why do we do this?

Imagine a traditional "digital" workplace based on email. The originator of document creates initial version and sends it around. Somebody comments and sends the update via "reply to all." Then someone else comments and sends around in the same way. And so on, and so on. It becomes even more fruitful, when we come to version conflicts.

Many companies worked this way for many years. It appeared as "modern" and "digital." The truth is, this can be done much better.

Just have a look on a following picture.

Agile way of working is different. The picture above already gives a hint.

"There is surely a need for information exchange. Different people interpret same infomation in a different way. There is lots of space for ambiguity - and the only way how to reduce it is via multiple "pings" there and back.

Let's imagine a fictious dialogue:

A) I want you to build me a square shape.

This is, what A says. In fact he wanted to say "angular" (and his desired outcome is a rectangle).

B) OK, so I will build a square for you. What is a length of a side?

A square is a square, right? The fact "A" is speaking about in "square shape," which is a generic form - was somehow lost.

A) Why are you asking me only for one side? You need more info indeed!

Of course, for rectangle we need to know 2 dimensions. But "B" has in brain fixed a "square" - and this has only one!

B) For a square?

For "B" this is still a square.

A) What square? I wanted you to build a rectangle! How did you come up with a square? It is obvious I do not need any! What do you know about my needs?

Over here "A" gets a bit frustrated. Such a simple and obvious thing - and "B" can twist it round so much!

.... and we could continue this story further. "B" will be pointing out he was requested to build a square, while "A" will be insisting on a rectangle. After a couple of more sentences they will come to root cause of misunderstanding - which was misinterpretation of a term "a square shape." After that they will clarify more carefully "what is desired" and then together define dimensions of the rectangle. Both leave the conversation somehow satisfied. And even more important - they have the SHARED UNDERSTANDING of what is needed. They can draw a quick schema on a whiteboard, take a picture of it and ONLY AFTER THAT send it via email - as a documentation of that shared understanding.

Now imagine this happening in the traditional way. How many emails / chats / asynchronous messages would need to flow between "A" and "B". If they were lucky - they would come to same outcome as in our fictious dialogue. But even more likely they would interrupt the conversation at some point - and the final product would not meet expectations of the requestor.

And - this fiction was happening only between 2 people. Imagine they were 8. (Remember? - 28 possible communication channels between 8 people).

This is WHY. This is the reason why we encourage people to run a workshop together. To make all such clarification discussions happen NOW. It will reduce ambiguity and create as close shared understanding as possible.

It makes a huge difference. Lots of saved time and far better quality.