We’ve all been there: Someone says something one way, you hear it a different way than it was meant, and something unintended happens. In software development, if something can be misunderstood, it likely will be. What can we do as Scrum Masters to help prevent miscommunication on our teams?
1) Be clear. Write it down.
Whether you write it on a notecard and post it to the cork board, or type it into Jira/Greenhopper (or OnTime, or VersionOne, or Agilifant, or Excel, or whatever), you’ve got to make sure the objectives are documented. If you write out a story along with its component tasks, and John says he’s going to work on it, make sure John initials that it’s his story. Implicit verbal contracts usually work, but “usually” isn’t good enough when you’re on a tight two-week sprint. You need to KNOW that the team understands their individual roles within that sprint, and that they’ve taken responsibility for those roles by signing off on them.
2) Be precise in what you say, especially with stakeholders.
When stakeholders ask you for a progress report (assuming the Product Owner isn’t around), they tend to interpret anything you say with an amplified reality distortion field around it. “We’ve had a couple of impediments crop up, but it’s coming along nicely”, will usually be heard as, “We’ve slipped, and now everything’s behind.” In brief summary form, quickly explain what the impediments are, how you’ve dealt with them, and tell them the exact effect it had on the overall sprint (or release, if applicable.)
3) Actively listen to your team, and don’t make assumptions about what they say.
If John tells you a detail, be careful not to assume he meant anything beyond what he actually said. For instance, you’ve got a 10 point story with eight tasks attached to it. John tells you he’s going to work on the first four, then signs off on them. Typically, the implication here is that when those are completed, John is going to work on the next four. That’s a normal logical assumption. This is where specificity is important, and we need to make sure John is going to work on those next four tasks. Luckily it’s easy to ensure this via a quick question to John, and some quick initials on his part. If that short five second conversation doesn’t take place, and John has no intention to do those next four tasks, it can lead to problems later when something falls behind and that 10 point story isn’t done on time.
Assumptions happen. It’s a part of life. Taking a quick moment to clear up tiny working points can go a long way toward preventing headaches down the road, and get you on the right track to continuous delivery.