10 Questions to Determine Whether You’re Transitioning Toward or Away from Scrum - dummies

10 Questions to Determine Whether You’re Transitioning Toward or Away from Scrum

By Mark C. Layton

Are you unsure of whether you’re executing scrum properly? The following questions can raise warning signs that you’re compromising your execution of scrum or falling into common pitfalls that could derail your transition to scrum.

Do you find yourself saying, or hear others saying, “Yes, we do scrum, but . . .”?

“Scrum-but” is a known condition when organizations partially adopt scrum.

Remember, scrum is a simple framework: only three roles, three artifacts, and five activities. If you feel that you have to tweak scrum, that should indicate that you’re avoiding an issue that scrum has exposed. Common agile practices enhance scrum rather than dilute it.

Are you still documenting and reporting in the old way?

If you’re still burning hours on hefty documentation and reporting, it’s a sign that the organization has not accepted scrum and other agile approaches for conveying project status. Help managers understand how to use existing scrum reporting artifacts and quit doing double work!

When will the stakeholders sign off on all the specifications?

If you’re waiting for sign-offs on comprehensive requirements to start developing, you’re not following scrum. You can start development as soon as you have enough requirements for the first sprint.

Are development team members asking for more time in a sprint to finish tasks?

The development team may not be working cross-functionally or swarming on priority requirements. Development team members can help one another finish tasks, even if those tasks are outside of a person’s core expertise.

This question can also indicate outside pressures to underestimate tasks and fit more work into a sprint than the development team can handle.

Are development team members asking what they should do next?

If the developers are waiting for direction from the product owner, or worse, the scrum master, they aren’t self-organizing. The development team should be updating the sprint backlog each day and talking about what they’ve accomplished and what they’re working on, including impediments in their way, at each daily scrum. The sprint backlog and development team itself drive each day’s work, not the product owner or scrum master.

Are team members waiting until the end of the sprint to do testing?

Scrum development teams should be testing every in-progress requirement every day in a sprint. All development team members are testers.

Are the stakeholders showing up for sprint reviews?

If the only people at sprint reviews are the scrum team members, it’s time to remind stakeholders how scrum works. Let stakeholders know that they’re missing their chance to review working product functionality, to provide immediate feedback to minimize course correction costs and delays, and to see firsthand how the project is progressing.

Is the scrum team complaining about being bossed around by the scrum master?

Command and control techniques are the antithesis of self-management and are in direct conflict with agile values and principles. Scrum teams are teams of peers — the only boss of how to do the work is the team itself. Have a discussion with your scrum mentor and act quickly to reset the scrum master’s expectations of his or her role.

Is the scrum team putting in a lot of overtime?

If the end of each sprint becomes a rush to complete tasks, you aren’t practicing sustainable development. Look for root causes, such as pressure to underestimate. The scrum master may need to coach the development team and shield them from product owner pressure if this is the case. Reduce the story points for each sprint until the development team can get a handle on the work.

What retrospective?

If scrum team members start avoiding or canceling sprint retrospectives, you’re on the slide back to waterfall. Remember the importance of inspecting and adapting, and be sure to look at why people are missing the retrospective in the first place. Even if the scrum team has great velocity, development speed can always be better, so keep the retrospective and keep improving.