Scrumdamentalism

“Every Scrum sprint must finish by delivering new product functionality that is integrated, fully tested, and potentially shippable.” [1]

Fundamentalism is “clinging to a stubborn, entrenched position that defies reasoned argument or contradictory evidence.” [2]

Recently, I received an email from my old friend Jake* who wrote, “I have just come across a Certified Scrum-Master who is pitching one of my very large clients that they should be doing ‘testing sprints’ after they do ‘development sprints.’ I can’t imagine a situation where this makes sense. It violates the Scrum notion of ‘done.’ I have seen this practiced by some of my clients, and it about killed them. Lee, are you guys pitching something like this, or is this just a misunderstanding?”

While we at Software Quality Engineering haven’t advocated this, several speakers at Software Quality Engineering conferences have proposed separating testing from development in some Scrum sprints under certain special conditions.

One speaker, Jared*, has written, “In some Scrum projects, an iteration will be dedicated to hardening the codebase. A hardening iteration focuses on bug fixing. Hardening iterations can be used to explore how applications work on different platforms, in different development contexts, or when different co-resident third-party applications are running at the same time.”

Alex*, another speaker, has written, “The agile intent is to perform all testing within the iteration—usually via automation. Unit, functional, and acceptance [testing] are the usual focus, but what about the other forms of testing? For example: full legacy regression, interoperability across sprints, performance, usability, etc. Thus the rub!” Alex suggests two strategies—“Extending the iterative model to accommodate testing via stabilization (hardening) sprints” or “skewed testing sprints.” Alex continues, “Both strategies are typically used for domains with an existing large-scale legacy [manual] testing burden (or requiring broader-scale testing practices). In the latter strategy, the skew allows some development activity to progress while broader testing is performed.”

I shared Alex’s ideas with Jake who replied, “I think that this is enough to get him [Alex] de-certified. As a Certified Scrum Trainer, I have certain responsibilities regarding issues such as this.”

So, I wondered—do Certified Scrum Trainers have both a right and responsibility to seek out heretics and silence them, demanding that they change their views and their presentation materials? Or can Scrum accommodate different views on the proper goal and structure of sprints? Not being an expert on all things Scrum, I asked my friend Milo*.

“This is nuts. Many people new to Scrum think we should have testing sprints. No Scrum trainer teaches that we should, and there are more than one hundred Scrum trainers, so this is one of the few things on which we all agree. Scrum gets its name from the idea of a cross-functional team, and this blows the cross-functional team apart. Also, [Alex] is wrong in what he says agile teams don’t do. Many do quite a bit of integration testing, and all focus heavily on regression testing—if the teams are any good at all. He really is quite wrong.”

That sounds definitive, but I asked my friend Johnny* to comment. “I recommend the same sorts of things [as testing sprint advocates Jared and Alex]. For testing or stabilization sprints, everyone on the team tests. In fact, they found testing to be one of the most fun things after I taught them some basic exploratory testing skills. The project manager, product owner, business analyst, developers, testers—everyone tested. The programmers would take turns taking time off to bug fix while the rest of us tried to find failures in their fixes. I also have done this to satisfy regulatory requirements. You