How Agile is a Scrum team?

Most teams I meet today are agile. Or, so they proclaim to be. All of these teams do Scrum, and that makes them agile. Doesn't it?

If I look back at the 12 practices the Agile Manifesto is build on (short: the Agile practices) I conclude that Scrum values a subset: the planning game, on-site customer, small releases and whole team.

Yet most of the teams doing Scrum that I meet have no customer on-site, although the teams do value this practice. Furthermore I mostly see a formal separation of developers and QA, and more often than not these teams use large releases (more than a few months). On the up side, most teams use Continuous Integration and have a set of coding standards, often formal.

The average of applying 3 out of the 12 Agile practices makes me wonder. Are these teams actually agile? Or maybe they are just a "little agile". Is that a thing?

Agile Principles

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.

These may seem to be supported by the planning game with user stories, doing the most valuable story first. That way the customer gets the most value out of each sprint, right? While that's true, I believe there's more to it.

While valuable software is very important, I think the key is in the early and continuous delivery of software. We add value to software by changing and extending it. This is what the planning game and user stories won't help us with. But changing software is highly valued by the Agile Principles.

Rest of the Agile Practices

And therefore there are Agile Practices that support us in changing software, enabling us to embrace change of requirements. These practices include automation of acceptance tests, test-driven development, pair programming, simple design and refactoring (not in any specific order).

I wonder how well Scrum teams can keep up the agile principles if they don't follow any other of these practices. I've seen teams respond to new requirements by demanding a "refactor sprint" to clean up the mess they made. Because there was no way to incorporate the changes otherwise. I've been on such teams years ago.

I won't state that it's impossible for teams to continuously deliver valuable software without following most of the agile practices. But I do wonder how they at all 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 broker feature when lacking stable unit and acceptance test suites?

So without most of the agile practices, can you really get into a stable and continuous delivery of value?

Scrum

I don't think Scrum is to blame here. Don't get me wrong. I like Scrum.

Scrum mostly embodies the planning and management rules of Extreme Programming (XP). I believe it's thanks to Scrum that much of the 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 unimportant. 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 practicing different ways to write software, but every time I got back to the agile practices as I find them to work best.

You're mileage may vary, of course. If you use different practices that even better support the Agile principles I would love to hear about them and try them myself.

2 reacties:

  1. Hi,

    Your post seems to merge together the 12 principles of the Agile Manifesto with XP practices. For instance, " These practices include automation of acceptance tests, test-driven development, pair programming, simple design and refactoring" . That sounds like XP, not like "Agile."

    If you really mean the principles of the Agile Manifesto, then IMHO Scrum supports 11 out of 12 with the only one not covered being "Continuous attention to technical excellence and good design enhances agility". That's not explicitly covered as it is in XP. Thankfully, many people combine XP technical practices with Scrum.

    ReplyDelete
    Replies
    1. Hi Damon,

      Thank you for your response. I'm glad that you mentioned this because the point I kind of want to make here is that maybe it's important for Scrum teams to use these agile practices.

      I do make a distinction between the Agile Principles behind the manifesto, and the set of practices that help a team to be agile. Indeed these practices are all explicitly used in XP, and maybe even in some other less-known agile methodologies. XP was first to mention these practices.

      Scrum does not use any of these practices, although Scrum teams might. Let me stress that I'm not at all saying that teams who don't, got Scrum wrong. Just that Scrum never mentions these practices.

      While the agile principles don't directly depend on these practices I wonder how a team can be agile without using most of them. How could a team deliver working software without an extensive test suite? Wouldn't that just be a lie? How can a team accept changing requirements well without a simple design?

      Note that I don't say it's impossible to do these things without agile practices, but I really do wonder if it can be done. Let alone if it'd be the sensible thing to do.

      If the teams you meet use most of the agile practices, then I dare to say that you're one lucky guy. My experience is very different. In most teams that I meet, I see them having a hard time keep up the false pretend that they are agile. And that in my opinion is exactly because they don't value these agile practices.

      -Bart

      Delete