Agile web developer and interaction designer Roger Saner recalls how he was once “forced to do dark scrum.”
Working with a scrum team tasked with integrating with a new internal API, he soon discovered how good agile could be overcome by bad. He saw firsthand how the enhanced teamwork, superior focus, flexibility and results-driven methodology of scrum could be overcome by “dark scrum,” destroying motivation with unreasonable expectations, creating dissension among team members and stakeholders, and turning quick, agile moves into awkward stumbles.
Saner’s scrum team worked with a new agile coach, who asked them to come up with a rough estimate of how long it would take to complete the project, calculating story sizes according to the existing backlog. Even though the information was provided for a rough estimate, these story points were given monetary values and used to determine the success or failure of each sprint as the development project proceeded.
Recalls Saner: “This put massive (and unnecessary) pressure on sprint planning and each sprint, because if we didn’t deliver the ‘committed to’ story points, it put the entire contract at risk, so the team had to work overtime.”
And the result was predictable with the unrealistic expectations, turning the sprint planning into a “high-stakes stressful game, taking longer and longer and [resulting] in open (and unnecessary) conflict between team members.” The situation deteriorated, the project bogged down, Saner burnt out and resigned his position before the work was complete.
Try staging-mondaycomblog.kinsta.cloud
How Scrum Goes Dark
Scrum is heralded for its efficacy as an agile methodology for managing development projects — mostly software projects but increasingly used in other fields needing flexible and innovative project management solutions.
Working in small increments of time (sprints), the scrum teams deliver in predetermined increments, with measurable goals and the flexibility to learn and pivot on the fly.
“Scrum, in simplest terms, says to take a team, including all the skills to build the product, and on a short cycle or one or two weeks, select the most important things you can do in one cycle, do them, delivering a working tested software increment containing all the work done so far,” says Ron Jeffries, one of the creators of Extreme Programming (XP), one of the authors of the influential Agile Manifesto and the expert who coined the term “dark scrum.”
“You inspect the product increment together with stakeholders, to agree on future direction. You inspect the process to improve it. Every week or two. It’s hard to see how that could go wrong.” But it does go wrong. How it’s hard to tell how often since statistics don’t exist, compared to the ones that extol scrum’s benefits, such as the high numbers of scrum and agile practitioners who believe that scrum improves the quality of work life and are committed to using it in the future.
But also some scrum masters and others in the business seem to believe that dark scrum sits beside the good scrum, threatening projects more often that people would like to admit, destroying morale and delaying project deliveries
More Scrum Education Needed
For his part, Jeffries argues: “Scrum, done even fairly well, is a good framework. I’m quite sincere about that. It’s good to have a strong connection to the business deciding what needs to be done, and what needs to be deferred.”
He points out, in his interview with staging-mondaycomblog.kinsta.cloud, that the problem may be a lack of education, in areas such as refactoring and test-driven development: “We do know is that there are upwards of a million trained scrum masters, which should mean there are three to 10 million developers working under scrum, and there are not even a hundred thousand who have had the developer training courses that are out there.”
As a result, “we surely have very much lower effectiveness in scrum than we could have” and “some fraction of low-production scrum sites turn dark. At this point, we don’t know how many.”
Signs of Dark Scrum
Some of the causes of dark scrum include:
- Teams that don’t have all the skills needed, resulting in delays and handoffs
- Management imposing work on teams rather than teams selecting amount of the work they can do
- More than one person demanding work from the team
“Well, to me, dark scrum is a dysfunction that is readily identified by looking at morale,” says Jeffries. “It’s caused, primarily, by pressure from management or the ‘product owner’ (or any powerful person) to deliver more, faster.”
It’s unlikely that teams would fail to deliver in they were in charge of setting their own (realistic) goals. A business side product owner, not familiar with scrum methodologies or the technical demands of the project (often programming), might cause problems in communicating in what’s needed each sprint, piling on more work than can be handled, demoralizing the team and causing missed deadlines.
When reviewing the preceding sprint and sprint history, “dark scrum leaders” might further damage the process by assigning blame and ignoring suggestions, rather than giving constructive feedback and being open to a dialog.
How to Respond to Dark Scrum
The trouble with a complex problem like this, there is no simple solution.
“In general, I’m a bit afraid that if the situation goes dark, there’s little chance of recovery without some major upheaval, because what’s going on is that management doesn’t understand what agile ideas are about and the team doesn’t have the power to turn things around on their own,” says Jeffries.
That said, scrum masters need to summon the courage to advocate for an incremental approach to projects, with measurable goals, rather than panicked, go-fast ones. Working in increments means setting realistic goals for each sprint, delivering “a tested, integrated, working, shippable increment of the product” each couple of weeks. As a result, stakeholders in the process might give up impossible goals for these concrete results.
Jeffries advises scrum masters: “First, remember that your job is to see to it that scrum is done as it should be, and to educate your team, your product owner, and your management so that that can happen.” This means insisting on doing work that can be done and not what someone wishes was done, with no basis for the demand. The bottom line is, “The scrum master may need to stand up to the product owner and management, to keep the pressure off to do more, more, more. But it needs to be done.”
Get started