Common Complaint: “Scrum Doesn’t Work Here!”

Common Complaint

“Scrum is not working in today’s software engineering industry.”

My Response

That is a little like saying: there are high rates of obesity in society, so that must mean healthy foods aren’t working. But clearly there are counter-signals that are causing obesity and preventing people from eating a healthy diet.

If Scrum isn‘t “working” in today’s software engineering industry, then perhaps there are counter-signals in the industry that are preventing teams from employing Scrum effectively.

Common Pitfalls

1. Open Concept Floor Plans

Many companies in recent decades invested in “open concept floor plans” — proponents of the open office design predicted more collaboration. But those predictions were wrong — the exact opposite occurred.

An open floor plan causes distractions, auditory and visual noise. So, people respond by isolating themselves with headphones and multiple monitors that prevent effective and transparent communication among team members.

This is an industry-wide problem.

Yet, every Scrum Trainer I’ve met and spoke with about office design have advocated for “team rooms” — think of a classroom-size space for a team of 6 or 8 people where they can collaborate openly while being acoustically isolated from the rest of the company.

2. Shared Service Groups Rather than Cross-functional Teams

Many companies do not or cannot organize their staff into cross-functional team units. They instead reinforce a “shared services” model — skills-based groups of people who are required to ration their time across multiple projects.

This too is an industry-wide problem.

If a company is not willing or cannot compose cross-functional team units, then they will be unable to use Scrum as intended.

3. Financial Gates that Reinforce the Waterfall

Many companies release funds according to pre-determined gates. That isn’t a problem…until those gates define a precise sequence like:

• ➡️ plan all the things
  • ➡️ design all the things
    • ➡️ implement all the things
      • ➡️ test all the things and document all the bugs
        • ➡️ then, and only then…launch and hope for the best

The waterfall sequence, a common SDLC, is not the optimal way to produce digital systems.

Some companies learn how to release funds incrementally according to business targets, for example:

• ➡️ minimum viable product
  • ➡️ beta release
    • ➡️ first trial customer
      • ➡️ first paying customer
        • ➡️ first hundred customers
          • ➡️ and so on…

A product team can produce a system incrementally and deliver small batches of new functionality frequently into the market — and the business can mitigate risk by placing small bets on strategic experiments that enable the team to move forward, course correct when necessary, and unlock real return on investment.

When I Hear “Scrum Doesn’t Work Here!”

I often think:

Perhaps people need to stop expecting Scrum and other agile practices to “just work” in all areas of the software engineering industry. It’s not a silver bullet. Yet, there appears a sort of collective perception that Scrum can make a typical, bureaucratic, siloed, rigid, document-driven enterprise suddenly agile.

That’s not going to happen — not without a major overhaul to the counter-signals described above.

To achieve the intended results of Scrum requires tremendous disruption in a conventional enterprise. It does “work” if the company requires and is prepared for that disruption. Just like a strict diet works if the disruption is supported and the counter-signals can be addressed.

This article also appears at Scrum.org.