An Update on Agile

(Lesson 7 from 25+ Years in Software Development)

I’ve spent years navigating the rituals of Agile development—standups, grooming, retros, planning poker. These can all be helpful… but they’re often applied so rigidly that we forget Agile’s real purpose:

Empower the people closest to the work to make the best decisions.

Too often, I’ve seen teams lose their ability to explore, experiment, and problem-solve creatively because “the sprint must go on.” We prioritize shipping features over understanding problems, and we treat engineers like order-takers instead of problem-solvers.

The Religion of Agile

I often say Agile is more like a religion than a science:

• Every team follows the rituals a little differently.

• Everyone thinks their version is the “right” one.

• There’s little consensus on what’s actually most effective.

And like religion, teams often inherit their process from whoever ran the last successful project—regardless of whether that’s the best fit for the current team or problem.

What Happens When We Get It Wrong

When PMs (often newer ones) push timelines based on wishful thinking, not real effort estimates, it can turn engineering into a transactional role:

“Just build what we say, how we say, and when we say it.”

That kills morale. And it produces work that barely functions instead of work that’s reliable, maintainable, and thoughtful.

I’ve pushed back on this repeatedly—advocating for an expanded definition of “done” that includes testing, real-world usability, documentation, and performance.

A Better Way

These days, I lean more toward Kanban-style flow:

• Less ritual, more adaptability

• Work pulled flexibly from a backlog

• Ad hoc check-ins instead of rigid ceremonies

• Clear communication across teams—without gatekeepers

Above all, I try to create environments where teams have time to think, prototype, and plan, not just ship. Where engineers have space to bring their full problem-solving power—not just their typing fingers.

Lessons Learned:

• Adjust your process to fit your team—not the other way around.

• Prioritize flow, communication, and psychological safety over rituals.

• Make time to explore, prototype, and validate.

• Expand “done” to mean robust, maintainable, performant code.

• Don’t let Jira fool you—a green board doesn’t mean a healthy product.