What to do when your Agile experiment goes wrong!

You've decided to experiment with Agile ways of working, but you're two weeks in and already things aren't going to plan. Standups are painful, WIP limits are being ignored and the team is complaining about admin overhead. You're not the first to be here and you certainly won't be the last, but how can you get back on track?

Most Agile experiments struggle not because the practices are wrong, but because changing how we work is genuinely difficult. Humans resist change, even positive change. Your job isn't to create perfection immediately, it's to create enough improvement that people want to continue the journey.

"Our standups turned into hour-long status meetings"

This is practically a rite of passage for new Agile teams. What started as a crisp 15-minute coordination meeting has morphed into a soul-crushing status report where everyone shares far too much detail about yesterday's activities.

The fix: Be ruthless about redirection. When someone starts diving into specifics, interrupt politely: "That sounds important, let's discuss this in the meet-after", then immediately move to the next person. It feels rude at first, but you're actually respecting everyone else's time.

Remember, standups aren't about informing 'management' or getting approval for your work. They're about team coordination, collaboration and prioritisation according to the sprint goals. Who's blocked, who needs help, who has bandwidth. When in doubt, refer to your sprint goals and make the decision that brings those closer to completion.

"People Keep Ignoring the WIP Limits"

You've set a limit of three items in your "In Progress" column, but somehow there are seven sticky notes crammed in there, and people are still pulling new work.

The deeper issue: WIP limits feel artificial when you don't understand why they exist. Your team probably thinks they're being more productive by juggling multiple tasks.

The fix: Start tracking and discussing cycle time (how long items actually take from start to finish). It can take some time to build enough data to use as evidence. In the meantime you can try to run a short workshop to demonstrate the practical value. Try the Coin Flip Game here: Coin Flip Game (Penny Flow) Template | Miroverse. When people see that their "multitasking" is actually slowing everything down, WIP limits stop feeling like arbitrary restrictions and start feeling like productivity tools.

"Management Keeps Adding Urgent Priorities Mid-Sprint"

The classic "everything is urgent" problem. Your team commits to working on specific items, but then leadership swoops in with new priorities that "absolutely must be done this week." This situation is one of the main reasons business choose Agile in the first place, so we have ways to adapt, 'be agile' and respond to changing business priorities. Clearly the capacity of the team isn't a bottomless pit though, so there will be some give and take when these situations arise.

The fix: There's an important questioned to be asked here to determine what approach you might take: Does the new work meet our Definition of Ready (DoR)?
If yes, "We can take this work into the sprint, but only at the expense of an existing planned item- which should take priority?
If no, "We can take this work into the sprint, but because it's not properly refined we can expect delivery time to increase by 20-30% for the uncertainty, and we will still have to descope some existing work. Would you prefer we deliver less items this sprint in order to deliver the new priority?"

Longer term: If your backlog of work is very shallow and your visibility of longer term business objectives and priorities is limited, it's more likely that when business priorities shift, the work in your backlog won't be refined/clear enough to be taken into a sprint on short notice. Agreeing with leadership on the minimum level of information needed for something to be added to a sprint (the Definition of Ready) will help to reduce the uncertainty and minimise the times where the answer to the question above is "no". This means that even when changes happen, your capacity isn't compromised.

"The Team Says It's Just Extra Overhead"

Some team members are grumbling that all this "Agile stuff" is just bureaucracy dressed up in fancy language. The boards, the standups, the retrospectives; it all feels like extra work on top of their "real" job.

The root cause: They're not seeing the value yet, which is completely normal in the first few weeks. In the early days you're still working out which Agile artifacts work for your team as they are, and what might need adapting. You're still working out your velocity, even just how long you want each sprint to be!

The fix: Focus relentlessly on removing obstacles for your team rather than enforcing process. When someone mentions a blocker in standup, follow up aggressively to help resolve it. When people see that these new practices actually make their work easier, resistance melts away. Use the retrospectives as the focal point for complaints/pains. When someone has an issue with the process, ask them to make a note of their frustration to be shared in the retro, so it can be discussed and perhaps improved upon.

Also, be honest about the adjustment period: "This might feel like overhead for a few weeks while we learn new habits, but the goal is to make everyone's job easier, not harder."

"We Started Strong But Lost Momentum After Two Weeks"

The initial enthusiasm has worn off, people are skipping standups, and your beautiful Kanban board is looking rather neglected.

The fix: This is where having a dedicated "process champion" becomes crucial. Someone who's committed to protecting the experiment even when motivation wanes. This person doesn't need to be the team manager; often, an enthusiastic team member works better.

Make sure not to skip retrospectives- they're a critical feedback loop. In the early days, you could even hold smaller mini retros once a week, rather than waiting to the end of your sprint. Ask: "What's working? What's frustrating? What should we adjust?" Small tweaks often reignite engagement.

It's not all bad news!

If your experiment is struggling, congratulations, you're learning valuable lessons about how change happens in your organisation. That knowledge will be invaluable when you're ready to expand beyond your pilot team.

Struggling to diagnose what's going wrong with your Agile experiment? Our MCQ coaches know how to help teams Navigate back to productivity without abandoning the valuable lessons you've already learned.

Need help designing your first Agile experiment or figuring out which approach best Connects with your team's unique challenges? Our Agile coaches specialize in translating Agile Beyond Tech, without the jargon or the dogma.

Book a consultation!

Contact us

Whether you have a request, a query, or want to work with us, use the form below to get in touch with our team.