When face-to-face communication goes social
Article originally published at www.scrumalliance.org.
You can find the original article here.
Since I’m writing here, it’s no surprise that I believe in communication and sharing of experiences. This is evident in the first place because I’m writing, and even more because I’m submitting here.
When we talk about being Agile or about working in a Scrum environment, we know that communication plays an important role. It is a main value and an indispensable practice in the road toward the planned goals.
Obviously, communication is much more than a Scrum value.
The evolution of human beings has been possible thanks to the relationships between individuals who communicated and then formed groups. As the groups grew, we learned how to better communicate. We invented languages and words, named things and concepts, and started narrating and eventually writing.
Nowadays our daily life involves talking with many persons and reading what others have written. For many of us, this is especially true at the workplace. In fact, when we appear at the office in the morning and say hello to friends and colleagues, we are communicating words and emotions. When we sit and look for written information in our email inbox, we know what is expected from us from “listening” to these communications. Eventually we talk with colleagues and customers in order to understand how to do what we are expected to. And this is the most advanced step in communication: sending and receiving messages at the same time in short feedback loops in order to reason together on things.
Given these facts, it could sound strange that, when writing the Agile Manifesto, those guys decided to underline the need for communication. Such an obvious concept, and still we need to point it out.
Actually — it is not strange, given how difficult is for us to do it effectively.
I’d like to add my piece to this topic by talking about what I have seen in the last few years.
Communication: Do we really need it?
I worked for two years on an ever-changing team. People left. People joined. The team size changed, and the goals changed too.
The team was mandated to maintain several applications, some of which were legacy ones. Only single specialized teammates mastered specific applications. Due to market and regulatory deadlines and to technical debt, the team had to work under pressure for a long period of time.
Observing our situation, I noticed the following issues emerge, related to the lack of appropriate communication patterns:
- Sub-teams formed around applications. Communication occurred only inside the sub-teams.
- A teammate illness meant noone had enough information to keep working on his or her items; there were competencies silos.
- Analysis was not done by the whole team, nor were individual analyses shared with the rest of the team.
- The Daily Scrum felt inadequately short and more like a reporting meeting.
- Different technical choices were adopted inside the sub-teams.
We put in place many practices to foster collaboration and communication. A few of them were as follows:
- We tried to reduce the number of diverse topics or applications selected for each sprint.
- We gave ourselves a rule of never working alone on a feature.
- We increased the number of backlog items aimed to reduce technical debt in order to mitigate pressure in future iterations.
These have been effective actions, but it takes time to see measurable effects — and other factors influence the outcome as well.
This was when I proposed to add Slack to our toolbox.
The rise and fall of Slack
A little bit of context
I firmly believe that face-to-face communication is the preferable way to communicate. That is not always a straight road, though.
- Different kinds of people have different needs concerning their comfort zones, and different attitudes about opening up and talking to others.
- Introvert teammates needed more time before they started actively communicating ideas and thoughts.
- Peer reviews tended to be undesired if proposed at the wrong moment in time.
- We still perceived our Daily Scrum as a reporting duty.
The team listened to my proposal and decided, rather doubtfully, to try the Slack app. The idea was to use it as a tool to fix ideas in a shared area. This was inspired by two different influences:
- The use of Slack in distributed teams with automated bots organizing the Daily Scrum.
- The practice of keeping a daily journal at the end of each day (see this video).
Tentative adoption
Commitment to participate in the Daily Scrum was so slow that many of us were often late for the event. So at first we tried answering the three questions on Slack, almost as if we were a distributed team. The difference was that we did keep meeting face-to-face at the Daily Scrum; it was just that everyone had already written and read updates by the time they appeared in the meeting room.
I noticed some benefits:
Some teammates enthusiastically adopted the app. Others perceived it as just another duty. Someone was scared about writing about real impediments. However, overall, things were slowly getting better. The enthusiasts started using it almost like a daily journal. When they were at home, they started dumping their thoughts on Slack for reflecting, fixing, and sharing ideas. I personally valued more this daily journal approach and noticed some benefits in our teamwork.
The fallback to command and control
However, a department reorganization changed things a little bit. New goals were set and the organization made important choices. It became clear that a self-organizing team was not a major goal. A team leader with a managerial approach started directing the team. This team leader worked strictly with the product owner to plan sprint and goals. He assigned backlog items and features to team members. No more volunteering was necessary. He was in charge of decision making and removed such duties from the team in order to let them develop their assigned tasks. The team leader assumed a pivotal role in every aspect of the life of the team.
This approach brought benefits in the short turn, but it greatly reduced the initiative of the team. Suddenly the only important communication channel was the one with the team leader. As a direct consequence, Slack was immediately forgotten by everyone. The ones still not convinced about the need for communication were the first to abandon it. After awhile, even the colleagues who had been using it as a daily journal for their own need and satisfaction stopped writing. The team leader interpreted this as a clear sign of the uselessness of the tool.
Final considerations
In my opinion, Slack is a powerful tool to add to a team toolbox on a voluntary basis. It adds a channel to update communications in ways that, in my experience, many people find useful.
We must remember that, after all, a colocated team is a “distributed” group of people at the end of the working day, and often they use a WhatsApp group. If we build relationships, we will chat together even after work, via means such as this. Slack focuses on the social network aspect of communication: being with you everywhere and notifying everyone immediately about updates. Allowing you to read immediately but, if necessary, defer conversation.
What I think my team experienced was a two-phase process:
- A first phase in which the team was slowly learning the importance of increasing communication in order to foster collaboration and self-organization.
- A second phase in which the team reverted back to a team leader-driven approach in which only the communication with the pivot (or with the persons working on the same piece of code in a particular moment in time) was the one needed.
The team’s attitude toward Slack was a powerful reflection of what was happening to the team as a working group.
