It seems in every Scrum, Agile, or Lean discussion these days, there’s always mention of the mythical “Scrum Purist”, or “Scrum Zealot”.

There are even articles dedicated almost entirely to the topic, such as: Purist is a dirty word, You don’t have to be a Scrum purist, and ScrumButs Are the Best Part of Scrum.

It has almost become the Godwin’s law of Agile. Past a certain point in the discussion someone will inevitably be called a “Purist” or a “Zealot”. Once this has occurred, there can be no more rational discussion.

It’s gotten to the point that people defending Scrum have to prefix everything they say with “I’m not a purist, but…”.

Who are these “Purists” or “Zealots”? Do they actually exist? Are they really as irrational as they seem? Or are they straw men created to support an argument? Perhaps they are simply reflections of anecdotal disagreements where we only get to hear one side of the story?

In my experience, I’ve never met any of these “Purists”. I suspect it’s mostly because these “Purists” are just people. People with their own motivations and points of view. Sometimes these points of view differ from my own. These points of view are often perfectly valid given their context, while seeming completely irrational from my own. And if that is true, two dimensional caricatures such as these “Purists”, simply can’t exist.

So what is a “Purist”? One who adheres to the rules of Scrum. Is that really all these “Purists” are? Is that so awful? Are there really so many rules to Scrum?

Well, as a Scrum Master, I’ve certainly been that guy. It’s in the job description after all, enforce the rules of Scrum. Does that make me a bad person? Should my opinion be discounted from any and all discussions? What about the fact that I’ve been lenient on occasions as well? Does that make me a pragmatist and no longer a zealot banished from conversation? Does that make me more or less effective as a Scrum Master?

Whether I choose to strictly enforce a rule, or show leniency is almost always determined by context. For example, in Scrum, planning meetings are time boxed. In a planning meeting, with a team which was new to Scrum, certain team members showed up late and unprepared. The team often failed to focus on the task at hand and people stepped out and back in from the meeting because of other commitments. When the time ran out, not much was done. They insisted that the meeting continue. I refused. I was being a purist. The meeting is time boxed and the time had expired. I could have let them continue, but I chose not to.

So what happened?

The next sprint meeting, the team showed up on time, prepared, and members reined each other in when they started to lose focus.

They were only able to recognize how their normal organizational behaviour was wasting each others time when the time was strictly limited.

This same team, later had a very productive meeting with everyone engaged and focused and asked for a few more minutes to estimate a few more items at the request of the Product Owner. I had no issue agreeing to their request.

Scrum is a mind set. A set of core values that each team must learn. The rules are there to help those who have not yet grasped the agile mindset make the transition. The rules are there to instill the values.

Each transition goes through phases of what is known as Shu Ha Ri. With Shu being beginners and Ri being experts. Beginners require strict rules that are explicitly spelled out to them. They don’t understand why they do what they do or why it works, they just do it because those are the rules. Unfortunately, in Scrum transitions, these are often the people who want to change Scrum the most and are the least qualified to change it.

This is where “Scrum but…” is the biggest problem. The issue with “Scrum but…” is that you’re often removing some of the values of Scrum before they’ve stuck. Notice, no one ever complains about people doing “Scrum and…”. In fact, most Scrum practitioners add elements of Lean/Kanban, XP, and other agile practices to Scrum. These practices are encouraged. The question of whether you should remove some of the practices of Scrum comes down to answering a few questions,

Why are you removing this practice? Is there an organizational impediment that could be addressed that would allow you to keep this practice? Have you thought about what Scrum value you might be losing by removing this practice? Do you have an alternate way of achieving that value? How mature is your Agile adoption? Are you Shu, Ha, or Ri?

If you can make the change in your process, keep to the values of Scrum, show a measured increase in the amount of business value delivered, and are in the Ha or Ri area, then perhaps it’s time for you to move beyond Scrum into your own custom process (which you shouldn’t call Scrum). There’s nothing wrong with that. However, if you haven’t reached that level of maturity yet or have not looked at what you are losing by removing the practice, perhaps you’re just avoiding dealing with the root cause.

Scrum surfaces problems in organizations. It’s up to you to deal with the problems in your organization. If that’s why you want to change Scrum, you’re doing it for the wrong reasons.

And if you’re a mature Agile team that has moved beyond Scrum, great! Just be careful when addressing a Shu audience. They may try to copy your current state without adopting the values your organization has already internalized.

Today’s image by dospaz http://www.flickr.com/photos/59195512@N00/4423741286/