Ever been in a situation where you're working your ass off to ship a high-quality product, but leadership keeps pushing for “faster velocity”? Or maybe you’ve dreaded daily stand-ups because they’re anything but a quick 15-minute check-in. What about that one stakeholder who loves tossing in last-minute work mid-sprint, creating chaos and torpedoing the team’s delivery goals?

Yeah. We’ve all been there.

These scenarios (and others like them) are symptoms of what I call toxic Agile practices. They sneak into your processes and slowly rot them from the inside. The best defense? Learn to spot them, understand why they happen, and build the muscle to address them head-on.

Being Too Rigid

I've seen it many times. Someone took a certification course on Scrum and now the team has to follow every letter of the process to a tee.

Here's the thing, at it's heart, Agile is meant to encourage creativity and innovation (in both product development and process optimization). Agile is flexible by it's very nature. Scrum is a framework by which teams can learn to implement Agile practices. However, by its very definition, a framework is simply " a basic structure underlying a system." Once team's have the basic concepts down they shouldn't be afraid (or discouraged) from experimenting.

For example, on some of my remote teams, we opted for Slack stand-ups instead of live meetings. Why? Because async updates let people stay focused, and still surface blockers when needed. It worked for those teams. Other teams preferred face-to-face Zoom calls, and that’s cool too - as long as it’s working.

Daily stand-ups support the Agile value of “individuals and interactions over processes and tools,” but when they devolve into robotic status updates or glorified mini-meetings? That value gets lost.

This is just one example of dogmatic framework adherence, but there are others:

• We must have a daily burn down chart! Nope. What you need is a way to effectively communicate progress. If that’s a burndown, great. If it’s a Kanban board with a cumulative flow diagram, or a Gantt chart - those are great tools too. Go with what works for your team, stakeholders and your process.

• We must use story points! Helpful for syncing early on, but once your team gets into a rhythm, use whatever method improves predictability. I dive deeper into estimating alternatives in my articles, Smaller Stories, Bigger Impact, and Predictability Over Speed.

• We must never change our sprint goal once set! I've been guilty of this in my past. And yeah, stability matters. But Agile exists to help us respond to change. Whether it’s a customer-impacting issue or a market shift, having flexible team roles (like an on-call engineer) can help address unplanned work without derailing the whole sprint.

• It's the Scrum Master's job to own the process! Think of them more like a coach. The goal is a self-organizing team, not a process dictator. Everyone should feel empowered to shape how the team works. That’s a core piece of Agile.

Being overly rigid is common when you’re first learning. But if you’re clinging to the rulebook and losing sight of the "why," it’s time to recalibrate. Agile is about learning, adapting, and evolving not just your product, but your implementation process as well.

Agile, Not Anarchy

Let’s be clear: Agile isn’t a free-for-all either. There’s a reason practices like retrospectives, backlog refinement, and documentation exist, and skipping them can cause just as much damage as being overly rigid.

• Who needs retrospectives?! You do. Even when things are going well. Retros give teams time to inspect, adapt, and actually celebrate wins. Without them, problems fester and morale tanks. It’s also one of the few sacred spaces for building psychological safety. I highly recommend using it, and using it effectively with documented and assigned action items so that ideas for improvement actually get implemented.

• We don’t have time to groom the backlog. I've seen it before, the Product Manager / Product Owner is busy and hard to pin down. And I've seen the resulting chaos: poorly defined stories, vague priorities, sprint planning disasters. Even lightweight grooming sessions are better than nothing. If your PM is MIA, find a proxy or step in yourself. You’ll thank yourself later.

• Documentation is a waste of time. False. “Working software over comprehensive documentation” doesn’t mean “zero documentation.” You still need to explain the why and how behind your systems, especially when people leave, forget, or can misinterpret. Living docs, lightweight wikis, and just-in-time notes & comments in Jira or code reviews are the way to go. I talk more about this in my related article, Writing for Humans.

A lot of teams misread the Agile manifesto, thinking "X over Y" means "never do Y." That’s not the point. It's about balance and judgment, not abandonment.

Burnout Culture

Burnout is rampant in our industry, and guess what? Most of it comes from broken Agile implementations that ignore the people Agile is supposed to serve.

• Unrealistic Goals: Engineering gives an honest estimate, and leadership pushes back with, “Can’t you do it faster?” Scope stays the same, timeline shrinks, and everyone loses. Burnout, missed deadlines, low morale, and mediocre product quality are the fallout. If this pattern repeats? You’re burning out your team. Instead: Work on understanding the trade-offs available and how best to implement (and communicate) them. Do we really need every little piece of that scope for the first version? What if we pair it down, get it out faster, obtain feedback and iterate on it bit by bit (very agile of you).

• Constant Task Switching: Multitasking feels productive but kills momentum. Context switching has a real cost. Want your team to deliver better, faster, more confidently? Help them focus. Prioritize ruthlessly. Limit work in progress (WIP). Watch productivity soar.

Poor Communication

I’ve worked with many teams that fall into the same traps: siloed work-streams that drift apart, misalignment on what’s being built, for whom, and why. Communication breaks down. Work stalls. Deliverables slip.

Here are the three biggest offenders I’ve seen:

• Lack of Collaboration: Siloed dev teams. Designers working in a vacuum. QA finding out about features after they’re built. Sound familiar? Agile teams are meant to collaborate daily, not just in ceremonies. That means cross-functional alignment, shared ownership, and treating each other like partners, not handoff machines. Otherwise, you’re not Agile, you’re just agile-flavored waterfall. Instead: Encourage cross-functional touch-points outside of the usual sprint meetings. Build relationships across roles. Hold working sessions where design, engineering, and QA are in the same (virtual) room tackling problems together. Foster a team culture where collaboration isn’t a scheduled event but rather the default mode of operation.

• Poor Feedback Loops: Agile without feedback is just a faster way to build the wrong thing. If you’re not regularly checking in with users, demoing to stakeholders, and reviewing your own work as a team, you're flying blind. Feedback loops (internal and external) are how we learn. Skip them, and you're not iterating; you’re guessing. Instead: Make feedback a built-in part of your process. Schedule regular demos with stakeholders and customers. Run usability sessions. Use retros to gather team insights and follow through on improvements. Create tight, fast feedback loops so you're always learning - and course correcting - early and often.

• Inability to Manage Up: Blindly saying "yes" to unrealistic expectations, raising issues without solutions, or waiting until it’s too late to escalate concerns all signal a failure to effectively manage your manager. As an engineering leader on an Agile team, one of the most critical (and often overlooked) skills is the ability to communicate clearly and persuasively to leadership. Instead: When your team is under pressure, frame conversations around value, risk, and outcomes, not just effort and velocity. Instead of “We need more time,” try “Here’s what we can deliver by X date, here’s what’s at risk if we don’t adjust scope, and here’s an alternate plan if speed is the top priority.” Lead the conversation on trade-offs. Be proactive, be specific, and be outcome-oriented. Executives aren’t looking for a Jira deep-dive, they need you to connect the dots between technical reality and business impact.

Happy Agile Development

Sometimes the way we use agile practices in software development can seem broken, and frustrating. Often it is simply the way it is being practiced (or abused).

When we get too rigid, too loose, or too rushed we lose sight of what Agile was meant to do in the first place: help humans work better together to build valuable things. The framework isn’t the goal. The goal is adaptability, clarity, collaboration, and continuous improvement.

So whether your team is sprinting in circles, drowning in ceremonies, or quietly burning out, take a step back. Look beyond the tools and rituals, and ask yourself: Is this working for us? Are we honoring the spirit of Agile, or just going through the motions?

The best Agile teams I’ve worked with don’t worship the process. They shape it. They question it. They evolve it. They stay flexible, focused, and fiercely human.

That’s the real secret. Agile only works when people do.

If you need a reminder around the "why" of Agile and what its core principles are, it always helps me to periodically reference the Principles Behind The Manifesto.