Easy but effective tips for a better Sprint Planning, part 2a: avoiding impediments

Ever find yourself faced with unique impediments for which nobody seems to know the solution? The only course of action seems to be to accept that the impediment is there, escalate it to management, inform stakeholders of delays, then attend the daily scrum regularly to give an update to the team, and when they get frustrated escalate it again, this time more angrily.

This post will look at how to strengthen your sprint plan allowing your team to avoid impediments rather than manage them.

I have split it into 2 parts, with real world examples in each:

• Part 1: examining the team’s informal connections to help them avoid impediments
• Part 2: adding resilience and capacity to for the team to deal with damaging future scenarios.

Part 1

Warning, this can be postit heavy. As a scrum master you will need multiple sets of postits in different colours.

After defining the sprint backlog, hand everyone in the team a pen and some postits. Ask the team to spend 5 minutes thinking and creating a legend for all the key groups that are active in the sprint goal (for example red = db admin, green = administrator, yellow = users, pink = operations etc). When the 5 minutes, place the legend on the whiteboard.

Now ask everyone to write their own names on postits placing them in a centre location on the whiteboard. This will be the Core group.

Then ask the following question: “What people do you know that are active in our work this sprint?”. Give them 10 minutes to explain to each other and when they are finished have the postits stuck around the core group. Use degrees of separation to add extra meaning to the postits. For example, there are two database admins active in the work, one of them, Tony, meets and chats with the team. The other, Bob, is known by name only. Tony is 1 degree separated from the team. Bob is 2 degrees separated from the team through Tony.

Then ask all the members: “Is there anyone else we would like to make active in our work?” Give them 10 minutes to figure this out and discuss why, then add the postits around the core as before.

Now, ask the group “Who knows whom? Who has influence and expertise? Who can block progress? Who can boost progress?” Ask them to illustrate the answers by connecting lines. 15 minutes.

Ask the group to devise for 10 minutes some strategies which

• invite and attract people into their work
• work around blockages
• boost progress

With that we are finished.  I like this technique because it illuminates for the whole group what resources are hidden within their existing network and what steps to take to tap those resources.

With a previous client, they used a helpdesk request system to initiate production releases.  When that system was changed an oversight was made preventing all of IT from creating their release tickets. One of the members in the team knew a guy, lets call him A, who was responsible for the environments that would be terribly upset about his service levels. Another developer knew a manager, B, that was responsible for the helpdesk that was desperate to get this fixed. From the web the site manager was directly connected to almost everyone else including A in operations. A team member walked to site manager B, who then walked the operations guy A, and their releases were performed even faster than before.

At the scrum masters scrum of scrums this came up as corporate wide issue, nobody could help so the RTE asked that everyone send all notifications to him and he would escalate the crap out of it until fixed.

I was actually standing there wondering what my own team did to resolve it themselves…

Part 2; Adding Resilience can be found here.