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

According to an article in Inc, groups that collaborate less often may be better at problem solving.¹³ 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.¹⁴ 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.”¹⁵

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.”¹⁶

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, such as by checking in briefly with each person individually. That makes richer discussion possible if it is actually needed. Some teams use a tool that enables them to broadcast a concise summary to their team of what they are doing and if they have any issues. In the words of one Agile coach,

“A tool I recently starting using is called Status Hero. I highly recommend it. My favorite feature — it prompts your team to include an emoji about how they are feeling. You can bet I am interested in the feelings of my team.” ¹⁷

Remember that focus is just as important as collaboration: if you destroy focus, your product will be terrible.