It's been said that, over time, charismatic movements often evolve to become "bureaucratic"—focused on a set of standardized procedures that dictate the execution of the processes within the movement. Has Scrum evolved to this point or is there still a place for agility in our processes?
“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 do your regular testing during development; then, you have a regulatory compliant, testing sprint where results are tracked for the regulator.”
| Attachment | Size |
|---|---|
 XDD15395filelistfilename1_0.pdf | 118.25 KB |
About the author
Lee Copeland has more than thirty years of experience in the field of software development and testing. He has worked as a programmer, development director, process improvement leader, and consultant. Based on his experience, Lee has developed and taught a number of training courses focusing on software testing and development issues. Lee is the managing technical editor for Better Software magazine, a regular columnist for StickyMinds.com, and the author of A Practitioner's Guide to Software Test Design. Contact Lee at lcopeland@sqe.com.
User Comments
Lee, in my travels (or is that travails) I have also seen charismatic movements become bureaucratic when those more motivated by politics than creating value become involved; much to my chagrin. I have also listened in on webinars where some supposed Agile 'expert' has told the audience things that make me want to scream and bang my head on the desk until the pain goes away. That said, as a committed Agilist, I have also seen bureaucratic environments become charismatic about Agile. I consider this 1) a learning curve typical all human nature and learning, and 2) par for the course for people transitioning to Agile. Quite frankly, environments weighted with people who think they can leave the office one day as pure traditionalists and come in the next morning religious Scrum-ophiles scare the hell out of me. It's rooted more in fantasy than reality. Worse, those same people in my experience think they're experts once they leave a 2 or 3 day course and they stop all learning. That as much as anything is about as anti-scrum (or Agile) as one can get.
Now, with that bit of context, I would challenge you based on what I read in this article that it's not Scrum that is getting less agile (more rigid). It's an expectation that those (e.g. CSTs) who should know better should also show some strength of character. It's one thing to accept that an organization may need to have dev and test sprints as some intermediate plateau(s) as they transition to full adoption of scrum and Agile practices; and the benfits they produce. It's quite another for those 'experts' (e.g. CSTs) to cave in to political or economic pressures, and stroke the egos of obtuse, uneducated individuals by suggesting scrummerfall practices are actually equivalent to achieving scrum and all the benfits its capable of producing.