Scrum Isn’t Working — Now What?

Scrum requires a lot of commitment from the team. Besides learning a new framework and embodying a new way of working, the team suddenly has a plethora of new meetings to attend. The Daily Standup, Sprint Planning, Retro, Sprint Review, and backlog grooming can total over 8 hours of meeting time per 2-week sprint. When run effectively in the right environment, these meetings are instrumental for establishing direction and enabling the team’s continuous improvement. When run poorly or smashed into the wrong environment, these meetings become a massive time sink, quickly causing the team to resent product owners, management, and Scrum itself.

What’s worse is when sprint commitments are consistently impossible. Most Scrum Masters recommend sprint tasks that take ~4–16 hours. Though most teams improve at breaking down stories with practice & coaching, in some environments 4–16 hour tasks are impossible to elicit from large-scale requirements.

• Teams with heaps of external dependencies
• Highly experimental/discovery focused teams

Such teams will struggle to break down requirements into small-enough pieces of deliverable functionality. As a result, the team gets frustrated over their demo-less Sprint Reviews and constant ticket carry-over. They’ll either internalize the failures, infusing a culture of blame and perceived incompetency into their daily rituals, or they’ll begin resenting Scrum.

So what do you do when Scrum isn’t helping the team?

First — Look at Your Environment

Scrum should be applied at the grassroots level by the team, in an environment that supports the process. If you find a scenario that perfectly fits both requirements, call me.

Instead Scrum is often an edict declared by upper management, in an attempt to immediately speedup development times and become more like Google, even if the product and operating environment are decidedly un-Google-like.

If full-Scrum isn’t working, the team should ask themselves:

1. Does this project support Scrum? — Scrum thrives in a Goldilocks zone of requirement instability. Requirements should be stable enough for 2–3 sprints worth of functionality to be defined, but flexible enough to handle changing business needs. If the entire project is well-known to a T, estimation is either easy or unimportant, and stakeholders really won’t change their mind (an incredibly rare occurrence if there ever was one), then Waterfall may be the way to go. Conversely, if at least one month’s worth of requirements can’t be defined, or the team can’t establish a predictable velocity (due to constant external dependencies, highly discovery-based work, etc.) then a Kanban or Scrumban approach may be preferred, and project schedules will have to be kept very rough.

2. Does the Environment Support Scrum? — Scrum not only gives power to team, but also challenges them. Releasing genuine value up to every two weeks is hard, and even the smallest impediments can put that goal in doubt. Therefore the surrounding organization must be invested enough to care about the team’s impediments, and agile enough to quickly remediate them. Beyond impediments, the team will consistently discover ways to work more effectively, and may require outside changes to execute them. An organization that’s Agile enough to adapt for the team, while keeping everyone else’s best interests in mind, will see their Scrum teams blossom. An organization that refuses to adapt it’s processes & structure will fail to produce, fail to innovate, and quickly become the next Kodak.

3. Does the Team Support Scrum? — The personal qualities needed to excel in Scrum are very different from those needed to survive the stereotypical corporate landscape. Courage, boldness, passion, and a desire to continuously improve are required from each member of the team. For some decades-long survivors of corporate, these traits have been stamped out and replaced by quietness and complacency. Although the newfound freedoms of Scrum may break some team members out of their shells, for others the responsibility of constantly delivering is daunting, compared to keeping their heads down and collecting paychecks. Consider whether your team members are able to make this shift, and whether Scrum can deliver enough quick-wins to bring even the most curmudgeonly of old-school people on board.

If you’ve answered “no” to any of the above questions, then take a note of why. Is this something that can be changed with enough time & elbow-greese, or are factors of your situation fundamentally incompatible with full Scrum?

Second — Look at Your Scrum

If the environment is right, you’ve given it a few months, and the team’s still struggling to deliver value, you may be doing Scrum wrong. Zombie Scrum is a great term for when Scrum’s practices are used to check management-required boxes, instead of promoting Scrum’s values.

Establishing modern development practices is easy. A pinch of Scrum, a dash of DevOps, and a few hackathons can make any company look up-to-date. But if these practices are forced upon developers with no corresponding cultural change, then the IT department will seem less like a Gucci handbag, and more like a cheap knockoff you buy out of a van in New York City. The right mindset from everyone in IT is required for Scrum teams to succeed.

Scrummerfall and Running Shoes

If you’re in management, you may be saying: “It sure looks like my teams are using Scrum. I mean, they’re standing up daily!” But are they really using Scrum, or are they just drawing burndown charts and holding new meetings, while keeping their waterfall-based approach to development? Are they practicing Scrum, or Scrummerfall? Symptoms of Scrummerfall are:

· Testers are bored out of their minds for 80% of the sprint, then have to work late the last few days to test every expected feature at once

· Sprints 0-* (0 to many) are used as design sprints

These indicate a Waterfall mindset re-packaged as Scrum. What happens when a tester rejects a story 4 hours before the sprint ends? What happens when requirements drastically change, and those four design sprints are nullified? Scrummerfall exists because Waterfall is comforting, familiar, and easy to follow. Changing that mindset requires effort.

Consider what happens when you start running. Your first non-stop mile seems impossible. Your efforts leave you gasping for air, with a rather dismal time. Your old life of a couch and bag of Lays beckons. But you keep putting those running shoes on every day, and over time that mile seems easier. Before long you’re doing 2 miles, then 3 miles, then 10 miles… You’ve challenged your body through frequent running, and your body has adapted to these new demands, becoming stronger and leaner in the process.

Transitioning to Scrum is like establishing a running routine. At first the idea of fully finishing functionality in two weeks seems nearly impossible. Team members balk at these new demands and frequent meetings, lamenting the easy days of Waterfall (while conveniently ignoring the months-late deliveries and misunderstood requirements). The first sprint ends with an underwhelming velocity and disheartened team. But the retro contains plenty of lessons-learned, and the team starts Sprint 2 with smaller user stories and a more accurate target velocity. Over time fewer stories are carried between sprints, and more user-ready functionality is demoed in sprint reviews. The team has been challenged to quickly deliver value, and with the help of a good Scrum Master they’ve adapted their mindsets to meet these new demands. They’re more cohesive, more communicative, and more motivated as a result.

So before you make drastic changes, consider whether you’re actually practicing Scrum, or Scrummerfall. Scrummerfall is like riding a Segway for a mile. Although you technically covered the distance, you didn’t put in the work, therefore you won’t experience the benefits.

Third — Look at your Options

If your environment is right, you’ve given it a few months, the team follows the Scrum Guide perfectly, and you’re still struggling to deliver value, then it’s time to break some rules.

As a believer in Scrum, I frequently have to check myself for fanboy-itis. Us humans are suckers for accepting for a supposedly easy solution to a complex problem. Unfortunately Scrum is not a golden hammer, and it can be inapplicable at times. Every team’s different, every environment’s different, and every product’s different. As a practicing community we must value flexibility over purity, and great software over perfect process.

Scrum not only encourages experimentation, it provides a perfect sandbox for experimentation. Timeboxing process experiments in sprints allows you to try changes without overcommitting to them. Scrum’s empiricism is it’s most powerful feature, as teams are encouraged to continuously inspect and adapt their practices.

Finally, there are times where Scrum simply doesn’t work. Scrum’s values can be applied to any project, but it’s practices can’t be. As a team, make a rational decision for how to best deliver value, based on what you’ve experienced.