As a Scrum team, the team and I have always taken pride in delivering on time. Our team (the Highway Team) has strived to make sure we complete stories correctly the first time. However, sometimes unforeseen issues arise.
I recall for one release some time ago, we were starting the second week of a two-week sprint and the clock, as always, was ticking. However, there was something different about this particular sprint. Somehow, things just weren’t flowing as usual.
A breakdown in communication
The issue with this sprint basically boiled down to communication. It seemed as if communication had somewhat dwindled. In particular, our co-workers on the Freeway Team seemed to be “stuck in traffic” due to congestion (pun intended), so to speak. You see, we had agreed to get a feed from the Freeway Team in the last sprint. Mike, from the Freeway Team, told our developers, “Yeah, don’t worry about it. Let me take care of some issues, and we’ll get right down to it.”
The problem was that the Freeway Team had encountered some last-minute issues in the previous sprint. They got held up fixing some unforeseen errors. That was all well and fine, but from the stakeholders’ point of view, we needed to deliver the app regardless. With the upcoming Summer of Sport, we needed to deliver a class “A” product as soon as possible.
I understood perfectly that the Freeway team got held up by some unexpected issues. These things unfortunately do occur. Nevertheless, the poor communication between our teams meant we found out very late. Our developers were told, “We’ve got more important things on our plate at the moment.” That was where one of the problems was. The message was delivered on the day of our final sprint. However, we were part of the issue too.
I have always coached my teams to make communication a priority regardless of any situation. External delays can most certainly interfere with progress. When we don’t communicate early and clearly about upcoming blockers, sprints and releases can get delayed.
Teams of experts are wired to get the job done. They will do whatever it takes to make the project work. However, in that razor-sharp focus, communication can slip through the cracks. Personally, I’ve seen teams miss delivering stories or leave out key features simply because they didn’t communicate.
Have you ever heard that two heads are better than one? That’s exactly what I want to illustrate. When you have teams communicating effectively, they can pick up mistakes, missing pieces, or unforeseen issues that others might have missed.
The retrospective
At the end of the sprint, we sat down as a team at our sprint retrospective to go over what we could improve. The topic of communication came up, and I asked the developers to think about what caused us problems and how we could have improved in our final sprint.
Emily, our QA tester, broke down one possible improvement and described our team process for escalating issues.
First, Emily spotted a defect. She then sent an email to the Freeway Team saying, “We’ve spotted the following issue. We’d like to go over it so you guys can make the necessary changes.” At this point, our team would usually follow up face to face so we could work together quickly to solve the issue. We didn’t, however, follow up with the face-to-face, so solving the issue took longer.
Second, the Freeway Team didn’t respond. When our developers asked Mike why they didn’t respond, he replied, “We were too busy fixing stuff. We don’t have time to go through every single email.” However, the miscommunication didn’t stop there. Emily didn’t follow up either. So, the email simply sat there for a whole day.
Third, Emily emailed the next day to tell me she hadn’t received a response. Because there had been no reply on the issue, it had now become an impediment. This led to me following up for a response from Mike and the Freeway Team. Following on impediments IS part of a scrum master’s role; however, as scrum masters, we coach teams to follow up and self-manage the situation for themselves. In this case, two whole days passed before I was then asked to step in.
Fourth, when we did get a response, it was in email form asking for more details. We could have been better at describing the exact issue with the feed providing text/log output, screenshots, and description as needed. This delayed our sister team by another half a day.
Finally, on the fourth day, Mike emailed us to let us know the issue had been solved. The situation was now “under control.”
Well, problem solved, right? Well, not quite. Sure, the issue was solved with a day to go in the sprint. However, the truth is that we could have solved it a lot quicker without cutting it so close. The issue could have been taken care of days before. Instead, it lingered and nearly risked the whole release.
Lessons learned
As a result of this situation, I took the time to summarize some valuable lessons from our retrospective.
- Agree to receive deliverables early: We planned to get a crucial feed with one sprint to go. Sometimes this is unavoidable; however, we could have planned some buffer time of two sprints or more, so we had time to deal with any issues before release.
- Communicate face to face where possible: We should have followed up with the Freeway team face to face the same day we found the issue. This would have meant they had a clear idea about what to do to fix it or could have asked for more information early.
- Follow up with teams on problems: Even if emails are sent or face-to-face discussions are had, we should always follow up to check progress, especially for important releases. Other teams and other people often get busy and can deprioritize our tasks. I could have helped with this as a scrum master, especially having a good working relationship with the Freeway team’s scrum master.
- Send detailed descriptions of problems: We could have sent logs, examples, and a better description of our problem. This would have helped the Freeway team to solve the problem faster. We can always help others to help us.
- Coach teams to solve problems themselves: In Scrum, we always aim to have self-managing teams. However, in this case, I could have coached the developers to follow up with the points above very quickly before contacting me. Then I could have liaised with my fellow scrum master to move things forward more quickly if necessary.
I believe that teams and developers, in general, want to do high-quality work as quickly as possible. When we implement a few communication tweaks, we can help our teams go from suffering communication chaos to being communication champions!
