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 new information about how the customer is using the features that they are working on or have worked on. They usually don't want to know any more than that!
So, we should stop demanding that they give up part of their morning to attend a standup. You might think, well, it is only 15 minutes. It is more than that, though. An article in Business Matters magazine quotes John Jenson, technical director at TandemSeven: “The stops and starts introduce mental context switches for all involved. If we apply a 15 min tax for each developer for each meeting, we lose another 30 hours.”16
But actually it is a lot more than that. When someone knows that they are going to be interrupted, they don't start anything that requires them to think deeply. So if a product developer arrives at work at 9:30 a.m. (a not atypical start time for technical people) and there is a standup approaching at 11 a.m., they will check their email and respond to Slack messages and get their coffee and then be ready to dive into work by 10; but they are then going to be leery of “getting deep into anything” before the standup, because they know that they will not be able to get far before being interrupted by the standup. After the standup, which often runs over, it will be approaching 11:30 a.m., which is close to lunchtime, so again, they are not going to want to dive deep into their work; they will stay at a surface level and then break for lunch. By the way, a standup is a group meeting, which is taxing for an introvert, and so the introverts will likely need a little decompression time after the standup before they can focus again.
So, a standup is actually very costly. Is it worth it? Ask your team what collaboration formats will work best for them at this particular point in the lifecycle of their work. Listen to them.
Also remember that the standup might be a way for the team lead, if there is one, to learn what is going on; however, there might be other ways to do that,
