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.
| Reference: | How Agile is a Scrum team? from our JCG partner Bart Bakker at the Software Craft blog. |
