Softwarecraft

How many of you have actually read the SCRUM Guide? If not, I encourage you to take a look—it’s available on scrum.org and contains the foundational principles behind one of the most widely adopted agile frameworks.

But before we dive deeper, let’s ask a more fundamental question: Why be agile? Why do we want to be agile in the first place?

Agility is not just a methodology or a set of prescribed rituals. It’s a quality—a state of being shared between the developers and the customer. To be agile is not something you do; it’s something you are. Agility means having the ability to swiftly adapt and meet the evolving needs of your customer. The daily actions you take either demonstrate your agility or reveal its absence.

Agility is a mindset. If you are agile, you can move fast and change direction on a whim. It just so happens that many teams choose SCRUM to help themselves be agile. But it might be that SCRUM is not the way for you (and your customer) to be agile.

To truly use or challenge any framework, you have to understand it deeply. Don’t confuse the tools with the solution. Having a chisel does not make you a carpenter. Holding a scalpel does not make you a surgeon. Doing SCRUM does not automatically make you agile.

Start every conversation with why. Why do we do what we do? Why have we adopted the processes we have? Are we agile because we practice SCRUM? No. We practice SCRUM because we believe it helps us be agile.

SCRUM is a framework. That is its strong point, but also its weakness. The good part is that it provides structure. The bad part is that frameworks can be rigid by definition—yet being agile means being flexible and fast.

Your customer’s needs are your only goal. You must be ready to pivot quickly and let go of what slows you down. But remember, what makes you fast today may become a bottleneck tomorrow.

Every team and customer relationship—every “couple”—is different. Not everything that works for one will work for another. SCRUM’s pillars of transparency, inspection, and adaptation are key: keep asking why and be ready to adapt. Start somewhere—and if it doesn’t work, try something else.

Change is hard because people are, frankly, lazy. If it ain’t broke, don’t fix it, right? But usually things don’t break suddenly—they break slowly, over time. How do you boil a frog? Slowly.

Another insight: You can’t change what you don’t own. Teams must be empowered to make decisions about how they work. SCRUM values courage; and no, it’s not about fighting lions. It’s about having the courage to admit when something isn’t working and to say, “Let’s find a better way.” Even if that means changing SCRUM with something else.

I’m not here to give you answers like “use this framework, not that one.” You can Google those yourself. My goal is to make you ask questions—real questions like Why this? Why not something else?

Take a moment to reflect: If you were to start over from scratch, knowing what you know now, would you still choose the same process? If the answer is no, then it’s time to explore alternatives—or at least fix what’s broken in your current approach or understanding.

SCRUM is not inherently bad. It’s just often misused or improperly applied. Maybe you’re experiencing what Martin Fowler calls Flaccid Scrum—where the rituals are performed but the values are lost. Don’t mistake SCRUM standup meetings for status reporting; use information radiators for transparency instead.

If you want fresh perspectives, read authors like Allen Holub and Dave Farley—the CI/CD guru. Simon Sinek’s Start With Why is a must-read on leadership and purpose. For those intrigued by metrics, How to Measure Anything by Douglas Hubbard offers insights—though that’s a topic for another day.

If you came here looking for definitive answers, I’m sorry to disappoint. I have more questions than answers. People rarely change their minds just because they’re told to. They adopt new viewpoints when external forces compel them.

So, is there life after SCRUM? Absolutely—if you’re willing to look for it.