Three Reasons Scrum May Not Be Working Out For You

Almost everywhere does something like Scrum these days or at least is familiar with it. Having said that, if you survey folks—and I have, you’ll find that most regard Scrum with ambivalence or animosity.

Aside from consultants and trainers, of course.

So, in this article, I want to go over three reasons Scrum didn’t work for you in the past so that when you reencounter it, you can hopefully make a better run of it.

Hurried Into Development

One classic problem I see is that groups adopt Scrum either because everyone is familiar with it or people go through a single day of training.

This isn’t enough.

Scrum is built around the idea of a team—a real team. Not a bunch of people assigned to a project.

So, when groups hurry into development without attending to if the team has formed up yet, there is slow but constant friction in how things work. The team hasn’t formed enough to take the responsibility required to succeed.

One easy way to tell is that everyone is looking out only for themselves and suggesting other people didn’t do what they were supposed to in time.

Those are classic marks to me that there isn’t a team. Without a team, there cannot be effective Scrum.

So, to fix this, spend time with everyone designing your team. Ask questions like:

• When we look back on our time as a team, what do we want to say about it?
• What are things we see that put us in a bad mood, or are our pet peeves?
• What precisely can we agree to do that will help us be better together?

There’s a whole lot more to this, but the bottom line is that spending a few days forming a team makes up for months of hurried development.

Certified Project Manager

Sometime after the great conjunction of agile, project managers everywhere started collecting various certifications as Scrum Masters. Unfortunately for most of us, that means we have a project manager parading around as a Scrum Master.

The issue here is that most of these project managers haven’t internalized how Scrum works with feedback loops centered around a team, and so they default to their typical methods of task assignments, estimates, and plans to try and keep things on track.

Yet, if anyone were to look at what the Scrum Guide contains, they’d find no evidence that these are behaviors of a Scrum Master at all.

So, as they make their demands of a team, the team never develops its internal responsibility, and the required status updates eliminate the feedback.

This isn’t easy to address because organizations reward these behaviors. My suggestion is to keep finding ways to move the team to the spotlight in every meeting. Have them be in the review and do most of the work.

Lame Sprint Reviews

The last major reason I see Scrum suck is the Sprint Review. This often neglected event is one of the most powerful feedback mechanisms in Scrum, and unsurprisingly it’s the one groups avoid the most.

Sprint Reviews are about the team, Product Owner, and customers seeing working software and hearing feedback about it.

Why do groups avoid this fantastic opportunity? Two reasons get used quite a lot:

• The team didn’t produce working software
• The Product Owner doesn’t want to show the product to customers

Both of these reasons, and all others I’ve heard, all fit under the same umbrella of, “We don’t want to hear the feedback.”

This is killing the group’s ability to learn and grow.

Going into a Sprint Review and hearing that the customers hate your software is incredible medicine. A team walking into a review and having to say, “We don’t have anything to show you,” is a powerful moment.

You can bet that after a terrible review, everyone will be ablaze with ideas of how to deliver better and differently.

So focus on your Sprint Reviews!