--- title: "Common Complaint: “Scrum Doesn’t Work Here!”" description: "When Scrum fails in a company, the cause is often the office, the org chart, or the funding gates. Those habits keep teams from using Scrum as intended." canonical_url: "https://davesabine.com/articles/2023/10/common-complaint-scrum-doesnt-work-here" --- > Index of every page on this site: [llms.txt](https://davesabine.com/llms.txt) ## 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.** ## Sitemap See the full [sitemap](https://davesabine.com/sitemap.md) for all pages.