Communication
What is the best way to foster an environment where development teams feel like they can talk about issues openly and developers feel like they are being kept in the loop? Furthermore, how do you ensure that the cross-functional team members on an Agile team are collaborating in a way that is productive? Finally, how do you make sure that “communication overload” does not happen (too many e-mails, etc.)? This is not always easy to achieve; it may be easy to talk about in concept, but making it work is a different story.
Real-Life Stories
I was on an Agile project that was using Kanban, and from a development point of view the project was very successful. However, in terms of communication from managers, it was not so successful. It was a multiphase project. As we approached the end of phase 1, we received very little communication about whether phase 2 would happen. Most of the developers on this project were “borrowed” from other teams, and it was uncertain where they would go back to or even if there was a team to go back to. Of course, this led to uncertainty and was not good for productivity.
Thoughts
One of the things I like most about Agile is the idea of transparency. Usually we think of transparency between the development team and the Product Owner, but I think transparency at every level is always a good thing. It’s understandable that management does not want to communicate plans when they are not 100% solidified. But I feel that management should at least communicate something, even if that something is “we are still working out the details on XYZ.” This shuts down any rumors and makes people feel they are being kept in the loop. This is definitely not an Agile-specific concern or unique to any one company. But I do think that for organizations adopting Agile, being more transparent provides an opportunity to improve overall communication.
Story 2: Leadership Frustration
Conversely, I was on a project where the manager shared too much. In the Daily Stand-up meeting, he would let us know that things were still being decided, which was good to hear, but the problem was that he showed his own frustration with the leadership above him and admitted to having very little confidence in those leaders.
Thoughts
I think this story shows the opposite end of the spectrum: that there needs to be a balance. It is good for managers to share what they know, but perhaps they shouldn’t share every detail and perhaps they should wait until things are semisolidified. That way, team members feel they are being kept in the loop, but they don’t have to deal with the yo-yo effect of things that change on a day-to-day basis.
Story 3: Bridging a Communication Gap
On one Scrum team we were having problems with writing clear acceptance criteria for User Stories. There was a disconnect between what the Product Owner, Quality Assurance (QA) engineer, and developer thought the User Story was about. I had just read the book Specification by Example by Gojko Adzic (Manning Books, 2011) and suggested we try the “three amigos” concept. This approach seemed to be a good fit because we had a lot of access to our Product Owner. So we had the developer, QA, and Business Analyst (BA) (a proxy for the Product Owner on this team) meet to talk through the User Story. This process worked incredibly well for this team. By the time the meeting was over, all three were on the same page and for the most part the acceptance criteria were fleshed out. After the meeting, the developer usually had enough information to implement the User Story and the QA engineer had enough information to finish writing the acceptance criteria.
Thoughts
The changes discussed in Story 3 improved communication between team members. In addition, because everyone was on the same page coming out of the meeting, it led to the team building the right software. Finally, the better the communication between members of a cross-functional team, the better the quality of the software will be and the more the team members will feel like a team working toward the same goal.
The changes in the team were incredibly noticeable. The changes led to a better velocity, and because we used the “three amigos” approach (i.e., we had the entire team in a single Story Time meeting), we wasted less time. I cannot overstate the importance of maximizing developers’ time and having better communication between team members on an Agile team.
Story 4: Communication Breakdown
I was on yet another Scrum team where communication between team members was not very good. The Daily Stand-up meeting lacked focus. The team did the normal “around the room” process, but beyond that there was little control. It was very common to have side conversations going on, for people to go off on tangents, and even to have people skip the meeting. Sometimes the meetings were even cancelled because several team members could not attend. One consequence of this lack of structure was that some team members often didn’t know what the other team members were working on.
Thoughts
One of the reasons for the Daily Stand-up meeting is to increase communication on a team. Having some amount of structure and asking the three questions (What did you do yesterday? What are you doing today? Are you blocked by anything?) are just guidelines, but for most teams they serve as a good starting point. The meeting should only take about 15 minutes. I’ve typically scheduled the Daily Stand-up for 30 minutes with the first 15 being what I just described and the last 15 being for post-Scrum items (things that the whole team cares about, or at least things that could benefit the team members if they heard the conversation). Anything that the whole team would not benefit from hearing should be taken offline.
The main goal is that people on the team should know what other team members are doing; thus they can swarm on things that are blocking someone. Skipping a meeting is a bad idea for a couple of reasons. First, just because some people cannot attend doesn’t mean that the meeting won’t have value for the rest of the team. Second, it breaks the cadence of the team, which can be detrimental.
Story 5: Lack of Productivity
While on a small e-commerce team (nine developers), I had to attend a daily 9 a.m. meeting. All developers had to attend this meeting. The problem was that usually the developers were working on completely different projects. After about a week of attending these meetings, I asked some other team members, “Do you find this useful?” The answer I received from all of them was a quick “no.” Every day I noticed that most of the developers would bring their laptop into the meeting and would hardly pay attention to what was going on in the meeting, which lasted for about 30 minutes. I would like to say that there was some value to these meetings, but that was usually just not the case. However, the manager was insistent that everyone be there at 9 a.m. sharp. In one meeting I recall we spent almost the entire time watching the manager try to test a defect that had been discovered. Unfortunately, this manager didn’t realize that the value of the meeting was basically nonexistent. I should mention that this team was moving toward Scrum but did not claim to be an Agile team.
Thoughts
I thought that Story 5 provided a good example of a missed opportunity for productive communication . One solution would have been to have that meeting once a week or even every other week and have a Daily Stand-up meeting for developers who were working on the same project. A Daily Stand-up meeting would have provided much more value to the developers and would have been shorter, and people would have paid more attention because the topics would directly relate to what they were working on.
Story 6: Inability to Share Knowledge
While on a small project with three Scrum teams, I saw first-hand how poor communication leads to a lot of wasted time. I was on one of the teams for only a few weeks when it became clear that all the teams had major communication issues. For example, one team had problems with the management of issues in its defect tracking system. One of the team leads held most of the information in his head, and the User Stories contained very few details. I was assigned one such User Story. When I wanted more details about the User Story I asked other team members. Everyone I asked said that only the team lead had knowledge about how a certain part of the application worked. This is an obvious case of “single point of failure,” but even with that being the case the User Story could have contained comments that would have helped me work on it. Another situation that occurred often was being assigned a User Story for the current Sprint, where the User Story was marked as “not started.” After working on one of these User Stories for several hours I was told that someone else was already looking into it. Again, time was wasted because something as simple as updating the status of the User Story hadn’t been done. Poor communication comes in many forms, and since these teams relied so heavily (like most teams do) on an issue tracking system, it was one source of miscommunication.
Thoughts
Story 6 demonstrates how a few minutes of someone’s time to add comments or update the status of a User Story could have saved hours and duplicated work and allowed the work to be started sooner. This may not sound like a big deal, but multiplied by several developers over months, it adds up.
The bottom line is that our tools are just one of the communication channels we use on teams, and that communication needs to be good. So take the time to make sure you are not a point of failure on your team: create documentation (the “teach others how to fish” metaphor), and make sure that you keep User Stories updated in whatever defect tracking tool you are using. It is a matter of discipline, but updating will improve communication on your team
Story 7: Simply Too Much Noise
On a large project there is always a chance for communication overload, which just creates noise. What I mean by “noise” is simply a lot of things that distract developers throughout the day and ultimately result in a lot of wasted time. I am not talking about the normal amount of company communication, e-mails, and chat rooms that we have all become accustomed to in software development; those just come with the territory.
On one large project, though, I saw an extreme misuse of communication channels and the amount of “noise” was ridiculous. For example, there were several e-mail distribution lists (developers only, architects, team leads, etc.). At first this worked, but over time people started sending things to the “everyone under the sun distribution” list. Literally hundreds of e-mails a day went out. Probably somewhere around 90% of these e-mails only pertained to 10–15% of the recipients. We also had many IRC channels and Skype rooms. But again, people started to use them in unintended ways that just created noise. People would tell jokes, and that would snowball into an hour-long comedy hour. That is great, but it is very frustrating when someone is trying to ask a legitimate question. It was not unusual to be away for ten minutes and come back to a Skype window and see hundreds of unread messages. In the end, most people just stopped watching the Skype rooms and IRC channels and filtered most e-mails.
Thoughts
There have been a lot of studies showing the cost of constantly being distracted throughout the workday and switching contexts. It all adds up to a lot of wasted time. I definitely experienced that, as I mentioned in Story 7. It was simply overwhelming. I think there are things that could have been done better. Following are some ideas of how things could have been done differently:
It would be better to educate people on using the right communication channel, not just what is easiest—the use of the right e-mail distribution lists, the use of the right IRC channels, and so on. Make this part of the onboard process for new hires on the project. Kindly remind people about using the correct communication channels when you spot misuse.
Something else that can help is to write succinct e-mails. There have been several articles written on this topic. One of my favorite suggestions is using just the subject line for short e-mails and putting “EOM” at the end of the subject line. EOM stands for “end of message.” When people see EOM at the end of the subject line they know they don’t need to open the e-mail and read it; they can just read the subject and then delete the e-mail. This probably saves three or four button clicks per e-mail. This is just one tip for using e-mail more efficiently, and there are a lot of great articles on this topic which are worth reading. One such article, by Brad Isaac, can be found at http://lifehacker.com/5028808/how-eom-makes-your-email-more-efficient.
When you are using Skype and are part of several groups, change the notification settings so that you only get an alert when certain words are entered into the conversation. Then, you can look at conversations that did not trigger a notification when you have time.
If a conversation in a Skype group or IRC channel really only pertains to a few individuals, take it offline into a new group or channel. This will help cut down on the amount of noise for all the others in the channel.
If you are fortunate to be co-located, have face-to-face meetings—which are much more valuable from my experience. Also, just get out of your seat and go talk to someone if he is close by. You get the added benefit of stretching your legs, too.
Over the last 17 years or so I’ve worked with people from all over the world while at various companies. With these companies being located in the United States, knowing English was typically a requirement. At one of these companies, all the teams that worked on similar parts of the application sat in the same area. Co-location is one of the smartest things I think a company can do for Agile teams. It promotes conversations and you overhear things that you might not ever find out about had the team(s) not been co-located. It is a great way to increase productivity—at least that has been my experience. So, when I noticed that many conversations in this area where my team was located were taking place in Spanish, it made me wonder if this could have a negative effect. About a third of the team spoke English and Spanish and the rest of the team spoke English and perhaps one other language other than Spanish. When I heard these conversations, I wondered if what the developers were talking about would benefit the rest of the team. Would someone on the team be able to offer valuable information if he or she could understand the topic being discussed? Basically, I always wondered, “Is this harming the team in anyway?”
Thoughts
I think this is a sensitive area. No one wants to be the person to say, “Can you please use English.” It might not come off as being a constructive suggestion. But I do think something is lost in a co-located team if people are not speaking a common language. For example, I was in Argentina for one company and I remember seeing the curious look on other developers’ faces when some of us had work-related conversations in English. They wanted to be in on the conversation, as well they should be.
So, I think there is a polite way to simply ask team members to speak in a language that everyone can understand in that particular environment. It is nothing personal but is meant to help the team better communicate and get the most out of being co-located.
Story 9: Scrum Master Should Not Be a Part-Time Role
On many teams, a developer on the team or even the manager sometimes plays the role of Scrum Master. While I’ve seen this work in some instances, it can also hurt the Scrum team. For example, I was a member of a Scrum team where the manager played the Scrum Master role. The problem was that the manager had several teams and had a lot on her plate. Because of this, she would miss many of the Daily Stand-up meetings, at least for my team. This led to several instances where the manager was completely blindsided. I recall that during one Daily Stand-up meeting I mentioned that my User Story had some changes to its scope. I had mentioned this in several previous Daily Stand-up meetings, but the manager had not attended those meetings, so on this day when I mentioned it again, the manager was completely caught by surprise and not too happy.
Thoughts
The point of the Daily Stand-up meeting is to share information, understand what each member of the team is doing, and work together to remove any barriers. It is a time for the team to decide what is the best way to tackle the day’s work. It is also for the Scrum Master to make sure the team is not blocked, to make sure everyone on the team is getting what he needs. It is critical that whoever is playing the Scrum Master role attend all the Daily Stand-up meetings. In Story 9there were really two issues. The first issue was that the manager could not dedicate enough time required to the role of Scrum Master. The second issue was that the manager was not aware of what the team was doing and therefore did not know whether the team was having blocking issues.
Fortunately, the Scrum team I was on was pretty seasoned, so the surprises to the manager were not frequent. But I can imagine a situation where this type of disconnect could be a much larger issue for less seasoned teams. The bottom line is that the Scrum Master role is a full-time role and is critical to the success of Agile teams.