As a ScrumMaster, your job is to remove impediments and facilitate the Scrum process. But how do you know when an impediment exists? The truth is, the discovery of most impediments will not come from your team or Product Owner telling you about them. You will find them because you see them happening.

When you are working with novice Scrum teams, here are warning signs that your team may have impediments that require your help.

They Work Hard… Just Not on the Committed User Stories

This is a common problem for beginners. If stakeholders are still being allowed to go directly to team members and ask for work to be done, often teams end up working feverishly for a whole sprint but not delivering anything they promised the Product Owner.

The fix here is to remind team members that when anyone outside the Scrum process requests their time, the response should be: “Sure thing. Just go ok that with our Product Owner because he/she prioritizes all our work.”

And that includes when stakeholders have emergencies. Sometimes “emergency” is code for “I am going to make a big fuss so they will drop everything and do my work first.” Do not encourage such high-drama behavior. Teach stakeholders that, if they truly do have an emergency, the quickest way to get it addressed is to go talk to the Product Owner.

They Work in Silos

If your team has been used to working in silos (think dev, test, user experience, etc.) that behavior can carry over when they join a Scrum team. Remind teams that no one individual or group of people (i.e. – the testers) “own” a story. The story is owned collectively by the team.

This means, if development on the committed user stories is done but there is still lots of testing to be completed, the developers need to pitch in and help with testing. What will help to develop this kind of teamwork is to build cross-functional teams, meaning teams where there is a certain amount of overlap in skillset between team members.

Does that mean everyone can do everything? Probably not. But what you want to avoid is the other extreme, where there is zero overlap in skill set. The Harvard Business review article The New, New Product Development Game highlighted study findings showing that the “relay race” kind of team, where each member had a highly specialized skill set and they worked in a sequential manner, did not work well for new product development.

They Don’t Ask for Help When They Need It

Technical people often take a great deal of pride in being able to find solutions to complex problems. Because of this, when they are stuck, they can sometimes be reluctant to ask for help. ScrumMasters quickly learn that the statement “I’m still working on it” can mean anything from “It will be done later today” to “I am completely lost and don’t know what to do next.”

Make it easy for your team members to do the right thing and ask for help when they need it. If you’ve heard “I’m working on it, but it should be done by the end of the day” from a team member several days in a row in Daily Scrum, ask some probing questions. Chances are that person has an impediment but they reluctant or unsure how to ask for help.

Watching for behaviors such as these and nipping them in the bud will ensure your Scrum team develops good self-management skills and learn how to better support each other.

Does your Scrum team have any of these problems? How have you tried to help them? I’d love to hear your thoughts in the comments below.