Читать книгу Agile 2 - Adrian Lander - Страница 27

Communication Is a Process, Not an Event

Оглавление

We have mentioned that before the Agile Manifesto was created, Alistair Cockburn had been writing about how, in his opinion, face-to-face communication is the most effective form of communication. It is not always, though.

Communication about complex topics is a process, not an event. If you gather five people into a room for an hour to talk about something complicated, which none of them have had a chance to discuss together before, then what usually happens is that in the course of the hour the conversation will jump all over the place. Some will be unable to fully explain their thoughts. They can't because for a complex topic, it might take longer than people are willing to listen without jumping in.

The situation is different if they have all been immersed in the subject. In that case, they have a shared understanding as a baseline, and they can discuss incremental ideas relative to that. But if someone is far ahead of the others, they won't be able to lay out their thoughts and not have someone inject tangential issues that will take up the rest of the hour.

In the realm of IT, there is a common topic that is complex. It pertains to branch/merge strategy. The issue is even more complex if one is considering multiple code repositories. The various issues pertaining to this are way too complex to discuss effectively in person, unless there is a shared baseline understanding of the issues. That is why one of us has used the approach of writing up a white paper, explaining the issues and laying out options, distributing it, and then having a meeting to discuss it.

Similarly, the idea that after a challenging product launch a team can gather to talk through what happened, what went wrong, and how to do things differently next time is simplistic. One of us has the approach of spending a week inviting team members to record and share their ideas in writing anonymously, summarizing the input and sending that out, then asking the group to submit solutions or action items in writing anonymously, and only at the end of the process coming together in person to discuss and prioritize what to do next. This gives people time to think, to write, to reflect, and to share ideas asynchronously over time, before having a meeting to discuss it. Indeed, we took a similar approach to developing the ideas of Agile 2.

The point is that the idea that face-to-face communication is always best is—like so much of the Agile community's interpretation of the Agile Manifesto—an oversimplification of real-life situations. Unfortunately, it has led to a community bias against writing down one's ideas. Writing is sometimes essential. What is writing for, if we are not supposed to do it?

Jeff Bezos famously makes his staff write a “six-page, narratively structured memo” for each meeting, and he says that it was the “smartest thing we ever did” at Amazon.12 He basically wants his people to think deeply and not have shallow debates in which they go in circles. He believes that complex issues require structure, and the best way to establish structure is through writing.

Our human brains are not like computers—they are not designed to be information storage vehicles. In The Organized Mind, Daniel Levithin explains that memory is fickle, and while we're good at making snap life-or-death decisions, we're not good at storage—thus the first forms of writing were lists—humans offloading the storage to free up brain space for more complex decision-making. Rather than supplant face-to-face communication, we believe that well-written, clear documentation enhances communication. By writing down a structure, the face-to-face conversations become more focused and more effective.

Communication is a process—not an event—and face-to-face is not always the best way to start. Sometimes a combination of communication formats is most effective, and the person who is organizing the discussion needs to think about what communication methods, in what order, might work best for the issue and also consider the innate communication styles of the participants, since some people communicate differently than others, as we have already learned.

Agile 2

Подняться наверх