We all agree feedback is essential for communication to become fluid. That’s why we do daily stand ups, communicate impediments, and become available for backlog refinements or log retrospectives. But what happens when that feedback becomes too noisy, repetitive and annoying?
During the last week I’ve been cleaning up my inbox of annoying promotional emails, bulletins and, especially, requests from retail websites asking me to provide a star rating or provide a very quick feedback about something I bought or a place I stayed in. As a user experience lead and web developer I very well understand the need to get that kind of feedback, but there’s a trend lately for every app or website to gather information in the same fashion, and we become somehow slaves of polls and ratings of the virtual world like the character of Bryce Dallas Howard in the Black Mirror TV series. At least for now we have the option to not do it.
Applying the same logic to a Scrum team that is more or less comfortable with the level of communication they use with each other (not enough, in case you’re wondering), and facing this same problem in the past, the question is: when does the communication of scrum practices become a bla bla bla for the team members, and that email you send with the good purpose of raising a problem or a good practice they should be applying ends up in the bin of their minds right away? Just like the feedback emails I receive and can’t cope with anymore.
This doesn’t just apply to the email overload effect, but even to direct conversations. A few examples:
- Rely on a message sent by email to be read, understood and settled right away: Email is great for certain generic information to be shared, or to communicate something specific. Email threads are just wrong and ineffective, and although sometimes a necessary evil, they should be a last resort rather than a common practice. I use emails just to communicate something as a complement to other ways to achieve my objective, such a direct interaction with the individuals.
- Micromanaging: Communicating good practices or better ways of working should not be an imposition. The team members should learn naturally to do the right thing with the adequate level of direct communication. Patience and resilience is required from the manager, but also open to constructive criticism. Nurturing and having two-street conversations is essential for this to happen. A message that’s told daily as an imposition may work in the short term but will destroy the trust or willingness to keep healthy conversations. A manager needs to be humble enough to see when he or she is becoming a bully.
- Meetings for the sake of having meetings: The whole idea of having specific, timeboxed meetings within the Scrum framework is exactly that: understand how long those meetings will take in order to minimize inefficiency. Each one of the Scrum ceremonies have a clear purpose and output, but there is a tendency to stretch out those meetings, being the obvious one the “need to have more backlog refinement meetings” or rushing important ones, normally being the Retrospective. This is something that needs to be cut out as soon as possible. Not only promotes disengagement (especially in big teams), but also distracts people and focus in delivery. The logical thing to do is keep the timeboxing, but demand the correct outputs in each of the meetings of the framework. That’s the team’s responsibility to understand the added value of doing this.
- Teams stuck in their old ways: certain feedback isn’t something the team will be willing to accept right away, just like that. There’s a component of imposition that’s necessary in order to push and promote change, but it is even more important to demonstrate with facts and real-life scenarios why communication of issues is important. Giving enough room. Letting the individuals breathe. Again, with patience and a Kaizen approach. The team will go through stages of development, but it is naive to think change will happen overnight. Although old-fashioned and not related specifically to IT, I’ve always found the Drexler-Sibett team performance model quite enlightening.
As a Scrum master, I find extremely difficult to find a balance between communicating and spamming. Only in the last week, I’ve sent long emails to the team to communicate the progress of the Sprint (three times per sprint) with very high-level metrics, ask them to update JIRA, communicate consistent ways to write user stories, make them aware of the team capacity, an assessment on what I think went well or wrong with the retrospective and demo format, plus a few more.
As expected, I did not get any feedback from the developers, but only from managers or Agile coaches. I did expect this to happen. I followed up on my comments directly during stand ups or during informal moments such as lunch time. It’s a way to reinforce my comments, but also to remove the strictness of the written words and allow the conversation to go anywhere, expand the universe of the topic we’re discussing in a completely relaxed format. But even with that, finding that balance is tricky.
What do you do in your teams in order to make communication and feedback more effective?