Possibly one of the most frustrating comments that I hear when speaking to novice software teams is, “We do Scrum — we work in sprints, we have a daily scrum, and we even have a product backlog.” In addition, although they may not explicitly say it, you can often add, “We don’t write any documentation, we release haphazardly, we plan on the fly, and we don’t care about buggy code because we’ll just fix it up with a bug iteration.” ARGH! These people give Scrum a terrible name, and worse still, when their projects inevitably fail, it is very difficult, if not impossible, to win back the senior stakeholders who have been burnt by a badly warped Scrum implementation.
It’s a Framework, Not a Method
You will often hear Scrum described as a method—this description is incorrect. Scrum is a framework of practices tied together by a small set of clearly defined rules. There are significant differences between a method and a framework. A method implies a one-size-fits-all, formulaic approach, whereas a framework offers a more flexible platform from which a variety of approaches can be derived depending on the environment.
To correctly implement Scrum, it is important to follow the few prescribed rules and to work within the framework of practices. So long as the approaches you choose to implement adhere to this premise, you are on the right track. As Ken Schwaber writes in his blog, “Scrum is like chess. You either play it as its rules state, or you don’t.” Extending this analogy, we can say that implementing the Scrum framework partially is like choosing to play chess with 20 pieces instead of the standard 32 pieces. Although there is a slim chance that the game will work in some form, the fact is that the 20-piece adaptation is an alternative and untested game that shouldn’t be called chess (see Figure 1).
Scrum does not contain redundant rules or practices. As such, for it to work as intended, it must be implemented holistically—partially adopting Scrum is tanta￼￼￼mount to not adopting it at all.
Qualifications versus Qualities
A ScrumMaster certification is certainly helpful, but depending on who is getting certified, it still might not mean all that much. I recall years ago, during my first ScrumMaster course, one attendee was a project manager from a bank who seemed to believe he was the drill sergeant from the movie Full Metal Jacket. I remember thinking to myself that even if this course went for 2 years, this guy would never get it. The bottom line is that the qualities of a ScrumMaster are significantly more meaningful than a certification.
Abusing the Agile Manifesto
Those who tend to warp Scrum may even occasionally quote the words of the Agile Manifesto to justify their complete lack of documentation and absent planning:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Anyone who abuses the Agile Manifesto in such a manner has either (a) not read the final line, (b) forgotten the final line, or (c) ignored the final line.
It is extremely important to remember that while the items on the left are valued more, the items on the right are almost always needed even if they are required in only a limited capacity (depending on the type of project).
A Few Scrum Antipatterns
What follows is a sample selection of symptoms that will immediately indicate that Scrum is being corrupted and warped. These symptoms should not be confused with “teething” issues faced by novice (yet genuine) Scrum teams. For example, a daily scrum that doesn’t always start on time is not ideal, but with the right motivation, it is a process that can improve and isn’t necessarily a signal that the team simply doesn’t get it.
Quality assurance should be treated as an integral part of the development process. A requirement should not be considered done unless it has met the quality requirements stipulated in the definition of done. However, sometimes the message gets twisted. When this happens, it tends to manifest as an initial bunch of “functionality” sprints that focus purely on banging out new code (to give the impression that progress is happening), followed by a bunch of “catch-up” sprints for identifying and fixing bugs.
The typical justification for this behaviour is that the team wants to validate their work by at least showing the general functionality to the users of the software first. When I come across this situation, I point out to the team that just because they might be working in sprints, it doesn’t mean that they aren’t waterfalling. Remember that until the functionality is fully tested and releasable, it is not complete and should be considered unreleasable (therefore useless) and very high risk.
Another implementation of this antipattern is the scenario in which the programmers and testers are working in different sprints: for example, the testers may be working one sprint behind. This situation arises primarily when automated testing practices are still immature and reliance on manual regression testing is still heavy. This staggered sprint scenario inevitably leads to the same catch-up sprints just discussed.
Never-Ending Sprint Zeros
Sprint zero isn’t really a sprint but an artificial term often used to describe the preliminary work that a team might undertake before it is ready to commence an actual sprint (with all of the required trimmings).
This preliminary work doesn’t typically have a timeframe, nor does it exhibit all of the typical structural elements found in a real sprint, such as a sprint backlog and well-formed requirements.
Although I’m not a fan of the misleading sprint zero label, I don’t actually have an issue with the concept of a preliminary stage. My main problem with sprint zero arises when inappropriate work is bundled into it that delays the starting of real sprints. Let’s take a look at what should and what shouldn’t go into any sprint zero (see Figure 2)
Just because the items in the Don’t Include list in Figure 2 might appear more nebulous than the concrete functional requirements, it doesn’t mean they can’t be estimated, planned, and broken down into tasks and therefore included in a sprint. In fact, I would argue that because of the nebulous nature of this work, it is even more important to wrap the proper sprint mechanics around it in order to offer greater visibility and tighter control.
A regular sprint duration is important for a number of reasons that are outlined in this article about sprint planning.
One of the most common excuses I hear for sprint length fluctuation is that the team wanted to sneak in a few extra days to finish some nearly complete requirements so that the sprint review is more compelling.
I believe there are only two reasons for varying the sprint length:
- When a new team is experimenting in the early days following initial formation.
- When all work is completed before the last day of the final sprint (see Figure 3).
This situation has been prevalent in every non-Scrum environment I’ve worked in. It is instigated when a senior developer is asked in isolation to estimate the duration of various pieces of work. You might well ask why this is a problem considering that someone so senior should be the most qualified to offer estimates. Well, this is exactly one of the problems. Although the senior developer might be the most experienced, in most cases he or she won’t be doing the actual work. The senior developer’s abilities will no doubt differ from the abilities of the team members who actually tackle the tasks, and so it follows that his or her estimate is going to differ from the eventual reality.
In addition, it isn’t an individual who is doing the work — it is the team — and as such the team as a collective should make the estimation. When only one person conducts the estimation, there are no checks and balances in place. ￼￼￼￼What if the individual is having an off day or perhaps misheard some vital detail and made an incorrect assumption? When a group of diverse team members is involved, such slips are much less likely to occur thanks to the multiple layers and filters processing the information.
Reliance on the Spec
If you start hearing comments such as “If it’s not in the spec, it won’t get done” or “I implemented exactly what was in the spec,” you can also be sure that your clothes are already wet courtesy of the waterfall that the team is standing in. It also demonstrates that your team members have become bureaucrats who have lost their ability to communicate with other human beings. Any so-called spec should exist only as a placeholder or reminder, and the actual requirements will manifest in both the dulcet tones coming out of the team’s collective voice box as well as in the actual working software that the team produces.
Poor ScrumMaster Selection
If your ScrumMaster doesn’t maintain the attributes detailed in this article and/or doesn’t perform the functions detailed in this article about Chief ScrumMasters and ScrumMasters, then you are more than likely being led by an imposter. How do you spot an imposter? Well, if the ScrumMaster is making unilateral product or technical decisions, micromanaging task assignments, driving the team to put in regular overtime, or generally acting like a tyrant, then there are going to be problems.
Listen to Your Folks
Heed the advice that your parents probably gave you once or twice: If you’re going to do something, do it properly. In the same way that you wouldn’t change the parameters of chess, you shouldn’t change the parameters of Scrum. Either implement Scrum within the boundaries of its framework or don’t call what you’re doing Scrum.
If you liked this article, you can:
Subscribe to this RSS feed!