A Checklist Exercise…
Agile development has become the gold standard for software teams worldwide, promising flexibility, iterative progress, and close collaboration.
However, from what I’ve seen, agility has morphed into a checklist exercise. Teams run sprints, conduct stand-ups, and churn out story points like clockwork—but often miss the spirit of agility. In my experience, true agility doesn’t come from frameworks; it comes from collaboration, clarity, and real-time feedback.
Understanding the “Why”
In the projects where I’ve felt the most productive and engaged, I’ve had direct access to stakeholders. These aren’t just passing conversations; they’re deep dives into the why. Why is this feature needed? Why does it matter to the end user? Why are we solving this problem in this way?
When I fully understand the purpose and impact of my work, everything flows more smoothly. Decisions are easier to make, priorities are clearer, and I can anticipate potential issues before they arise. Clarity and ownership often translates to a higher quality of work.
Contrast this with projects where information is passed down through multiple layers, each one distorting the message where the odd detail is lost in translation. By the time it reaches the development team, the details are vague or misinterpreted. I’ve been handed tickets with just a sentence or two of context, leaving me to reverse-engineer the purpose of the task. Without context, even a well-documented feature can feel like a shot in the dark.
Poor Communication
When communication breaks down, the ripple effects are felt across the project:
Wasted Time: Developers spend valuable hours chasing down clarification instead of writing code.
Misaligned Goals: Without understanding the broader objectives, developers might deliver technically correct solutions that fail to meet business needs.
Frustration: Both teams and stakeholders become frustrated when expectations aren’t met, creating tension and eroding trust.
One of the most frustrating experiences is realising that the solution you built doesn’t align with the stakeholder's vision—something that might have been avoided with a 15-minute conversation at the start.
The Rush to Deliver
Another common problem is the relentless pressure to deliver. Quoting and defining tasks can often feel rushed because teams are constantly expected to meet aggressive deadlines. Agile frameworks are supposed to prioritise adaptability, but many organisations treat sprints as rigid deadlines.
Teams are pushed to hit their story point projections, and if they don’t, there’s often a postmortem to figure out what went “wrong.” This creates a culture of output over quality. The focus shifts from delivering the right thing to just delivering something.
In the rush to complete a sprint, corners are cut, technical debt piles up, and long-term goals are sacrificed for short-term wins.
I don’t mind working in sprints. In fact, they can be incredibly effective when done right. But sprints should be a tool, not a trap. Their purpose is to create manageable chunks of work that can be iterated on, not to lock teams into unrealistic timelines.
The Myth of Agile Frameworks
Many companies claim to be agile but aren’t truly embracing what agility means. Instead of prioritising collaboration and adaptability, they’re just ticking boxes:
Stand-ups? Check.
Retrospectives? Check.
Sprints? Check.
These ceremonies become performative rather than purposeful. Teams go through the motions, but the core principles—like valuing individuals and interactions over processes and tools—are often lost.
Agility is about responding to change and improving continuously, not rigidly adhering to a framework. A company that clings to a "by-the-book" implementation of Scrum or SAFe while ignoring its spirit isn’t agile; it’s just bureaucratic.
Direct Stakeholder Communication: A Game-Changer
One of the most effective ways to improve agility is to maintain direct communication with stakeholders, especially non-technical decision-makers. Regularly sitting down with them provides clarity and context that can’t be replicated through documentation or second-hand communication.
When developers and stakeholders collaborate directly:
Decisions Are Grounded in Reality: Developers gain insight into the practical implications of their work, leading to solutions that align better with business needs.
Feedback Loops Are Shortened: Stakeholders can clarify or pivot quickly, reducing the risk of misaligned deliverables.
Trust Is Built: Regular communication fosters mutual understanding and respect, creating a more cohesive team.
However, direct communication rarely happens in many organisations. Stakeholders are often too busy, and their priorities are pulled in a hundred directions. But this lack of interaction is costly in the long run. A few hours of direct discussion upfront can save weeks of rework later.
Practical Steps to Improve Collaboration
Achieving true agility requires intentional effort:
Schedule Regular Stakeholder Meetings: Even brief weekly check-ins can provide invaluable clarity.
Involve Developers in Early Discussions: Bring developers into the room during initial planning sessions so they can ask questions and offer insights.
Encourage Open Communication: Create an environment where team members feel comfortable asking for clarification without fear of judgment.
Use Visual Tools: Tools like wireframes, flowcharts, and prototypes can help bridge the gap between technical and non-technical stakeholders.
Prioritise Feedback Loops: Incorporate regular feedback sessions into your workflow.
The Spirit of Agility
At its core, agility isn’t about sprints or stand-ups; it’s about collaboration, adaptability, and continuous improvement. It’s about empowering teams to make informed decisions and adapt to changing circumstances.
It’s not about adhering to a framework; it’s about embracing a mindset.
Final Thoughts
The most successful projects I’ve worked on weren’t defined by their adherence to an agile framework. They were defined by the people involved: stakeholders who communicated openly, teams that prioritised quality over speed, and leaders who valued collaboration over box-ticking.
If we want to build truly agile organisations, we need to move beyond the rituals and focus on the relationships.
Agile isn’t a checklist—it’s a commitment to working better together.
The Grumpy Dev is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.