Many software development teams use Scrum. Indeed Scrum is a highly popular process. In this post I talk about some of the problems I’ve noticed in some Scrum teams. I don’t believe these problems are related to Scrum, but are a direct consequence of the mindset of these teams.

To stop this from becoming a No True Scotsman story, I’ll talk about the way I’ve seen how some teams have adopted Scrum.

Of the 12 practices the Agile Manifesto is built on, Scrum is mainly about the planning activities. This doesn’t mean the other practices aren’t valuable in Scrum teams, but it’s not the main focus. Most Scrum teams use the planning game for each sprint, do daily stand-ups, use small releases, and have a customer on-site. That should make them agile, right?

Agile Manifesto

Let’s take a look at the Principles behind the Agile Manifesto. The number one priority is “to satisfy the customer through early and continuous delivery of valuable software”. Closely followed by the importance to (even late in development) embrace changing requirements and the notion that working software is the primary measure of progress.

While valuable software obviously is highly important, I think the key is in the early and continuous delivery of software. We add value to software by changing it and extending it. The planning game will help you towards that road. But then what?

This is where the rest of the agile practices pop in. Practices like automation of acceptance tests, TDD, pair programming, simple design and refactoring (not in any specific order). These are practices that actively guide you to more continuous delivery.

Keeping up

That Scrum itself focuses on planning aspects doesn’t mean that these other practices aren’t valuable in Scrum teams. It’s just not the main focus of Scrum. In fact, I wonder how well teams can ever keep up the agile principles when they only use planning. I’ve seen teams that respond to new requirements by demanding some refactor sprint to “prepare” for what’s coming.

I’ve been at such a team. One sprint turned into two sprints. Our biggest problem to me was that we’d only knew if we screwed up when QA told us so. It was seen as the job of QA to tell whether the developers made a mistake. Oh yes, we were a whole team. We had an on-site customer. We had QA inside the team. We did daily stand-ups. We did planning sessions for each sprint. But we didn’t use the other agile practices.

Now I won’t say that it’s impossible for teams to keep up their delivery of valuable software without following these practices. But I’ve never seen it work well. I wonder how it could. I mean, without simple design and constantly keeping the code clean, how well can code be changed, even in a few months from creating it? What raises a flag for a broken feature when lacking stable unit and acceptance test suites?

Scrum

It’s not fair to blame any of this this on Scrum. Scrum works well in a wide variety of teams and organizations.

Scrum mostly embodies the planning and management rules of Extreme Programming (XP). I believe it’s thanks to Scrum that much of the agile planning and management practices have made their way into mainstream today.

It’s just because Scrum doesn’t include the other Agile practices many folks doing Scrum think that those are somehow not valuable. The most successful teams I’ve seen are all doing most, if not all, of the other Agile practices as well. This is also totally possible for a Scrum team.

You’re mileage may vary

Over the past years I’ve been experimenting with other ways to write software. This is especially hard without TDD and simple design. While it’s good to experiment, every time I got back to the agile practices as they work best for me.

You’re mileage may vary, obviously. If you use different practices that even better support the continuous delivery of valuable software I would love to hear about them and give them a try myself.