The words we choose, often communicate more than the words themselves

With this in mind, here’s six phrases that are often red flags when used in agile projects. Their use is more often than not a sign of underlying issues that will impede a team’s ability to truly perform.

1. “We’re doing what works for the team”

A noble expression which on the surface might seem to be exactly what agile is all about; responding to change and adapting to the circumstances.

But, does it work for the customer, or for the business, or for the stakeholders? What ‘works for the team’ might be building up large amounts of un-shippable work, or working on features that simply aren’t the stakeholders’ priorities.

Could something else work even better, but require a bit of effort? Doing ‘what works for the team’ is often synonymous with resisting change, or a lack of understanding of the landscape. It reminds me of being a child and trying to fix a relative’s computer when something is obviously wrong with it, but they resist change because they are comfortable with what they currently have, flawed as it may be.

Agile practices and techniques typically shine a very bright spotlight on problems. For example, Scrum won’t fix problems with weak product ownership, but it will make it very obvious. Many teams choose to switch the spotlight off rather than fixing the issue. If hiding from problems is what ‘works for the team’ then there are definitely significant problems underlying.

2. “We do [/don’t] do this because we’re agile”

“Agile” doesn’t tell teams what to do, so quite simply should never be used as justification for doing something. Yet, it often is.

“We’re agile, so we don’t write documentation”, or “agile says we should estimate user stories” and many other variations echo through the hallways of many companies, both large and small.

“Agile”, or more accurately the agile manifesto does outline some values and principles, and of course teams should use these to help guide them but they are not in themselves justification or reason.

3. “Sprint Demo”

What if the Sprint Review was an opportunity to do more than just inspect the increment? What if teams could also use this to look at the Product Backlog, and work with stakeholders to better understand what to do next? What if they could look at the market and see how it has changed, and make decisions based on that? What if the Development Team provided some insight into their work, which could then be understood by stakeholders and improvements to their interactions made as a consequence?

Good news, the Sprint Review is all of those things. Teams mustn’t miss this opportunity if they want to be successful.

4. “That’s an idealism”

While some companies release software to production many times a day (some do it many hundred or even thousands of times a day), others continue to insist that it simply isn’t possible for them to release more than once a quarter.

At its core, agile is all about ‘working software over comprehensive documentation’, and so it is little wonder that almost every agile practice that you come across is rooted in the real world, in real teams, doing real work, for real customers. They’re not born out of University research departments. So when people insist that it simply isn’t possible to deliver working software at least every Sprint, or that stakeholders will never be engaged with the team on a regular basis, their competitors continue to surge ahead.

5. “Our goal is to do the Sprint backlog”

If this is your thinking, just do continuous flow because you’re missing one of the most fundamental parts of Scrum. Sprint Goals represent the valuable increment that teams are working towards, and when the increment has value no greater than the sum of its component parts, Scrum is likely not an effective way to manage a complex project.

6. “Scrum says…”

Similar but still different to #2, this is a great indicator of a lack of knowledge and understanding of Scrum within a team.

There are times, of course, when a team or team-member needs to have the rules laid out in front of them, particularly if they are just beginning their agile journey (‘shu’ stage where simply following the rules is the best option), but generally speaking once a team starts to mature, teams are coached and guided through underlying principles, concepts and values. They should be committed to their decisions and to their process, which they are unlikely to be with purely a rulebook to guide them.

So, when teams choose to skip their Sprint Review, a good Scrum Master won’t simply open the Scrum Guide and recite that “a Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed”. Rather, they will explain why this event is valuable, and the potential consequences on the team’s ability to inspect & adapt, and on transparency, if it were to be skipped. They will also recognise that when a team is thinking about skipping something like the Sprint Review, it is probably a sign that the event isn’t working, and the root cause isn’t the event itself but rather something deeper: maybe it’s just being poorly run, or maybe — in the case of the Sprint Review — there are no stakeholders engaged with the project, or maybe the team simply cannot deliver a ‘done’ increment within the Sprint time box so there is nothing to review.


These phrases are not guarantees of problems, but they are often very good warning signs and allow for a very quick assessment of team health.