7 Killer questions for Agile teams
Red flags for teams not delivering value
Killer Questions for Agile Teams: Are We Truly Delivering Value?
Before the pandemic, while working with a client, I was tasked with collating assessments for over 30 so-called "Agile teams." Each team was judged against 40 questions, each with five defined scoring levels. This assessment had been running for years, a soul-destroying exercise for both me and the teams. No one felt good about their results, and many felt bad.
The process created all sorts of management weirdness. Leaders started competing with one another, making excuses for low scores, while I teetered on the fine line of neutrality—like a crazed coaching ballerina, trying to stay friends with everyone. All the while, I couldn't shake the thought: none of these teams actually seem Agile. Even those with the highest scores lacked the hallmarks of what I would consider a truly Agile team.
We often encounter teams who believe they are applying agility without truly embracing its core principles. A quick scan of how they work reveals some key ‘misses’ in what I would expect a successful Agile team to have in place. Sadly, the prevalence of certified frameworks has contributed to this situation. Today, a leadership team may believe they have implemented Agile ways of working via a framework installation; the teams are using Jira, the façade of ceremonies exists, but something smells a bit off when we lift the covers.
Here are some telltale signs that a team isn’t getting the most out of Agile practices. It’s not about chasing some ideal of being the most Agile team—far from it. These questions are my shortcuts for quickly spotting red flags so we can skip the theatre and get straight to helping teams apply the concepts of agility where it matters most.
Let’s stop pretending. Let’s do the hard work and actually help these teams.
A Lack of Engineering Practices
Early adopters of Agile recognised the value of engineering practices such as Extreme Programming (XP), which emphasised technical excellence. After all, one of the Agile Manifesto’s principles states that Continuous attention to technical excellence and good design enhances agility. When technical practices are neglected, teams risk accumulating technical debt, slowing down delivery, and creating a brittle system that hinders change.
We could easily see a lack of engineering practices if we did a full audit, but a quicker way to tell might be to ask…
How many automated tests are running as part of deployment?
This killer question will reveal a few things. If people say none or start talking about other people responsible for testing software who are not the people creating software, you have a lot to dig into in terms of engineering practices.
A Lack of Continuous Improvement Practice
People may believe that excellent work practices are in place, and they could be right, but should we ever rest on our laurels and believe we are good enough? I applaud teams that are always wanting to improve, and how would we know if a team is committed to this? The killer question is…
Show me how you manage your retro actions?
Even teams that regularly retrospect may be terrible at following up on their actions. I want to know if the team has a method for ensuring actions are done. A team that does is well-organised and just keeps getting better!
The Feedback Loop to the Customer Isn’t Closed
Unfortunately, there will be a lot of teams out there using the trappings of Agile and yet have no connection to the customer value they are delivering. The killer question is…
Where were the customer insights from the last deployment?
If the answer is vague or someone starts pointing towards a single team member with “Product” in their job title, you might conclude that the results of deliveries are not socialised back to the team. We may do surveys, but are they filtered or delayed for a long time post-release, or not shared at all? This indicates that the team does not have the opportunity to act on the best information available to inform their next action. This kind of environment creates an unnecessary distance between the team and the customer, making it super challenging for them to deliver meaningful value!
The Team Does Not Devote Any Time to Crafting Their Own Ways of Working
Every team will benefit from an opportunity to determine how the work works. If not, then they may be blindly following someone else's framework or not have ANY particular work design for how the work gets done.
Can you share your working agreement?
A team that crafts its own working agreement points to one that has time to stop and design at least some parts of how the work gets done, and how the behaviours in the team come together to reinforce good working. A team that’s too busy or hasn’t heard of a working agreement, lacks the opportunity to design how to best do their work.
Work Is Not Broken Down into a Small, Continuous Drip of Value
It’s not easy to break work down into smaller pieces. We call these user stories, but even if you don’t call them that, it’s dangerous to have work completed as large chunks. Large batches of work move slower, hide risk, and delay the delivery of value to the customer. The killer question that splits the good from bad teams is…
What’s your team’s cycle time?
A team that knows how long their work units take to complete has enough awareness to seek out smaller pieces of work. Measuring cycle time ensures that the team is caring about work breakdown enough to keep an eye on that number.
The Team Is Working on Too Many Things at Once and Not Prioritising for Flow
We all know that feeling—doing many things and finishing none of them. Teams can easily become overwhelmed by starting too much, with good intentions, and sometimes you just need a hard constraint to keep you focused. The killer question…
What’s your WIP limit?
Teams that understand what Work in Progress (WIP) limits are and implement them are going to outperform other teams. Observing teams applying a WIP limit is to observe a team where the work flows.
Team Communication Is Passive-Aggressive
We all know a team where, on the surface, things are fine, but behind the scenes, people are bitching and moaning as individuals and calling out other people’s performance. A killer question…
How does the team celebrate wins?
This reveals if the team has any wins, and if so, do they recognise them and celebrate them?
If celebrations are few and far between, there’s likely something missing, such as work happening in large batches (see cycle time) or missing testing (see automated tests). Celebrating wins together is a good indicator of psychological safety.
A lack of winning and celebration points to many conditions that reinforce poor communication. When winning is happening (good delivery of value and positive answers to the above questions), then there’s no reason for bad communication to build up. People love to win. People love to work in teams and win together.
Use these 7 killer questions for a much faster reveal of Agile team performance.
If a company lacks the curiosity or time to reflect on how its teams operate, failure is inevitable. Agile isn’t just about implementing frameworks—it’s about continuously questioning, learning, and improving. The real measure of agility isn’t in labels or tools or laborious maturity assessments but in the ability to deliver value, adapt, and thrive in a changing environment.
If you don’t have enough curiosity or time to pose even these killer questions, then get in touch, and maybe we can help find you some!