Agile 2. Adrian Lander
Читать онлайн книгу.
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.
The Importance of Focus
According to an article in Inc, groups that collaborate less often may be better at problem solving.13 The article argues that the always-on environment created by tools like Slack, desktop pop-up notifications, and sitting within earshot of others actually disrupts one's ability to focus. The article cites research that shows that intermittent collaboration—that is, collaboration that follows periods in which one has no interruptions—leads to the best outcomes.
The noise of an open office also has been shown to reduce cognitive performance.14 The New Yorker examined the impact of its new open plan workplace and determined that “the environment ultimately damages workers' attention spans, productivity, creative thinking, and satisfaction. Furthermore, a sense of privacy boosts job performance, while the opposite can cause feelings of helplessness.”15
In other words, the Agile team room is dumbing us down.
The article differentiates between several situations in which collaboration is needed.
Planning
Ongoing improvements
Consensus or decision about an issue
A crisis
In each of these situations, a group needs to synthesize its ideas and ultimately act as one. However, note that communication is not mentioned. Communication about what someone is doing, or challenges they are having, does not necessarily need immediate discussion, so why bring a whole group together for it? It might be better to provide the information in a real-time dashboard or a group message. And if the message does not interrupt but can be ready when each person is ready—when they need a break from their work—then it does not interfere with their focus.
One of the standard Agile communication practices is the daily standup. A standup meeting is supposed to be a short meeting—usually “time-boxed” to 15 minutes. In a standup, the team members all stand, and a facilitator goes around the room, asking each person what they have accomplished, what they plan to work on today, and what their “impediments” are.
Many people in the Agile community say that a standup is not a status meeting, but it is hard to imagine a meeting that more accurately defines a status meeting than “what did you do, what will you do, and what is in your way?”—that set of questions epitomizes a status meeting.
The problem is, it wastes everyone's time. Not everyone wants—or needs—to know what everyone is working on.
In Agile 2 there is a principle that goes, “The whole team solves the whole problem.” This means everyone on a team needs to understand how things will fit together. They all participated in sketching out the solution, but from that point on, they don't need to know the details of each other's progress. They only need to know about issues that arise that might affect them, and they definitely need to know if there are any changes in how the overall solution will work.
We hear so many programmers say things like, “When I hear people in a standup say what they are working on, I don't understand most of it, and I don't really care what they are working on. I only want to know about what affects me.”
We need to listen to that, because it's the people who are doing the work telling us, and a core Agile principle has always been to let people decide how they want to work.
Some Agilists will immediately respond that if team members are not interested in what others are working on, that is a sign of other problems. It might be, but it might not be. Once a team has decided how it is going to implement a set of features, most of the team members might not need to communicate very much.
What product teams do want to know about is anything that changes pertaining to how all the different parts of the solution fit together. And they want to know if something changes that directly affects what they are working on, including