Agile Tools and Anti-Patterns

What tools are for

The first value of the Agile Manifesto (2001) reads "Individuals and interactions over processes and tools". That is not a rejection of tools — almost every team uses one — but a reminder of their place. A board or backlog tool is good when it makes the work transparent: what is being worked on, what is waiting, what is blocked, what comes next. It is bad when it becomes an instrument of control: hours logged per ticket, managers reassigning work from a dashboard, people updating fields for reports nobody reads.

Three rules of thumb help:

• Process first, tool second. Agree how you work — the columns of the board, the Definition of Done, the WIP limits — and then configure the tool to match. A tool's default workflow is someone else's process.
• Keep it light. Every mandatory field and every extra status costs time on every item, every day. If a field is not used to make a decision, remove it.
• The tool does not replace the conversation. A Product Backlog item in a tool is a reminder of a conversation with the Product Owner and stakeholders, not a complete specification.

Board and backlog tools

Most teams use one of a handful of tools. They differ in ecosystem, flexibility and price more than in what they can do — all of them show a backlog and a board.

Jira

Jira, from Atlassian, is a work-tracking tool widely used by software teams. It supports Scrum boards with Sprints and backlogs, Kanban boards with column limits, reports, automation rules and a query language (JQL, the Jira Query Language). Its strength is flexibility and integration with other Atlassian products such as Confluence; its weakness is the same flexibility, which lets organizations build workflows with dozens of statuses and mandatory fields.

Atlassian has renamed several things recently, so documentation and colleagues may use either word. As of 2026, according to Atlassian's announcements: Jira Software and Jira Work Management were merged into one product simply called Jira (announced in 2024); an "issue" is now called a work item (2025); and "projects" are being renamed to spaces across Jira Cloud. Jira Service Management, used by service desks, remains a separate product (see ITSM in Practice).

Azure Boards

Azure Boards is the work-tracking part of Microsoft's Azure DevOps, next to Azure Repos, Azure Pipelines, Azure Test Plans and Azure Artifacts. It offers backlogs, Sprint planning, Kanban boards and queries, and links work items directly to commits, pull requests and builds. A project starts from a process template — Basic, Agile, Scrum or CMMI — which decides the work item types (for example "Product Backlog Item" and "Task" in the Scrum template). It is common in organizations that already use Microsoft tooling, and it is also available on-premises as Azure DevOps Server.

GitHub Projects, Trello and Linear

• GitHub Projects organizes GitHub issues and pull requests in tables, boards and roadmaps, with custom fields such as iteration and priority. It suits teams whose code already lives on GitHub and who want the backlog next to the code.
• Trello (owned by Atlassian since 2017) is a simple board of lists and cards. It is easy to start with and good for small teams and non-software work, but offers less for backlog ordering and reporting.
• Linear is a fast, opinionated issue tracker aimed at software teams, with built-in iterations (which it calls "cycles") and roadmaps.

Physical boards

A whiteboard with sticky notes is still a valid tool, and often the best one for a co-located team. It is always visible, it costs nothing, anyone can change it, and standing in front of it starts conversations. Its limits: it does not work for remote team members, it keeps no history, and stakeholders elsewhere cannot see it. Many teams that switch to a digital tool start by drawing their process on a wall first, so the tool follows the process instead of the other way around.

Metrics that help and metrics that hurt

Every tool produces charts. The question is which numbers help the team and its stakeholders make better decisions, and which ones change behavior for the worse. A useful warning is Goodhart's law, usually quoted as "when a measure becomes a target, it ceases to be a good measure": people optimize the number instead of the thing it was meant to show.

Metrics that help

• Flow metrics — work in progress, throughput, cycle time and work item age — show how work moves and where it gets stuck. See Kanban.
• Outcomes: did the change make a difference? Fewer calls about meter readings after the self-service feature, more customers using the app. See The Product Owner in Practice for Evidence-Based Management.
• Customer satisfaction, from surveys, reviews or support contacts — the user's view, not the team's.
• Escaped defects: defects found after release, by users or in production. A rising number says the Definition of Done or the testing is not strong enough.
• Delivery performance such as the DORA metrics (change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate).

Good metrics are used by the team to improve, are looked at as trends rather than single values, and are balanced: speed together with quality, so one cannot be bought at the expense of the other.

Metrics that hurt

• Velocity as a KPI. Velocity — the amount of work a team typically completes in a Sprint — is a planning aid for that team only. Used as a key performance indicator ("increase velocity by 10%") or to compare teams, it simply inflates the estimates: points go up, nothing else does.
• Utilization. Keeping everyone 100% busy maximizes waiting: work queues up, cycle times grow and nobody has room to help a colleague or handle an urgent item.
• Story points per person. It turns a team estimate into an individual score, discourages helping others and rewards picking easy items.
• Vanity metrics, explained below.

A vanity metric is a number that looks impressive and only goes up, but does not help anyone decide anything: total registered portal accounts, lines of code, number of tickets closed, Sprints completed. Ask of every number on a dashboard: "If this changed, what would we do differently?" If the answer is nothing, it is decoration.

Anti-patterns

An anti-pattern is a common, recurring response to a problem that seems reasonable but usually makes things worse — the opposite of a good practice that people nevertheless keep reinventing. The word comes from software design, but it is widely used for ways of working. Recognizing one is the first step; the label is not an accusation, because almost every anti-pattern starts as a sensible compromise.

Cargo cult agile and agile in name only

Cargo cult agile copies the visible rituals of agile — stand-ups, Sprints, boards, sticky notes, job titles — without the thinking behind them: short feedback loops, working product, inspecting and adapting. The name borrows from physicist Richard Feynman's 1974 Caltech commencement address on "cargo cult science": research that has the outward form of science but does not work. The result is often called "agile in name only": the organization has renamed project managers to Scrum Masters and phases to Sprints, but plans, decisions and releases happen exactly as before.

A quick test: if the team never changes its way of working, never releases more often than before, and never talks to a user, the rituals are cargo.

Zombie Scrum

Zombie Scrum is Scrum that looks like Scrum from a distance — all events take place, the artifacts exist — but has no beating heart. The term was popularized by the book Zombie Scrum Survival Guide (2020) by Johannes Schartau, Christiaan Verwijs and Barry Overeem. Typical symptoms:

• no working, releasable product at the end of a Sprint — "done" means "handed to testing";
• no contact with customers or users; the Sprint Review is a slide show for managers;
• no improvement: the Retrospective produces the same complaints every time, and nothing changes;
• low energy and indifference — the team goes through the motions because the calendar says so.

Dark Scrum

Dark Scrum is Ron Jeffries' name, from a 2016 article, for Scrum used as a tool of pressure. He wrote: "Too often, at least in software, Scrum seems to oppress people." Examples: managers who treat the Sprint forecast as a promise and punish misses; a Daily Scrum turned into a status interrogation of each Developer; more work pushed into the Sprint after it has started; and the transparency of the board used to find someone to blame. Jeffries' point is that the framework itself does not ask for any of this — it comes from old habits of command and control wearing new names.

Water-Scrum-Fall

Water-Scrum-Fall describes organizations where only the middle of the process is agile. The term comes from a 2011 Forrester report by Dave West, which called it the reality of agile for most organizations at the time. Requirements and a fixed plan are made up front ("water"), the team builds in Sprints ("Scrum"), and the result waits for a big, infrequent release ("fall").

Water-Scrum-Fall is not always a choice; contracts, budget cycles and release processes push organizations into it. It still delivers some benefits — the team gets better at building — but it misses the main one: learning from real users early. Moving toward smaller releases, with automated continuous integration and delivery and a flexible scope inside a fixed budget, shortens the loop step by step.

More common anti-patterns

• Too many meetings. The Scrum events have maximum durations — for a one-month Sprint they add up to 15 hours plus 15 minutes a day, and less for shorter Sprints. When teams complain about meetings, the cause is usually extra status meetings on top, or events that run without a clear purpose and drift past their timebox.
• The Product Owner as a proxy. The Product Owner collects requests and passes them on, but every real decision goes to a manager or committee. Scrum expects the organization to respect the Product Owner's decisions; a proxy turns every question into a delay.
• The Sprint as a mini-waterfall. Analysis in the first days, coding in the middle, testing crammed into the last day — and what does not pass testing rolls into the next Sprint. The Increment is rarely done.
• Fixed scope, fixed date, fixed team — and "agile". If nothing can be adapted, there is nothing to inspect for. Agile works by fixing time and cost and letting scope flex.

From symptom to first step

You rarely fix an anti-pattern in one go. The table gives a symptom you can notice and a small first step a team, Scrum Master or Product Owner can take.

Criticism, fairly

Agile has plenty of critics, and many of them are former practitioners. Some criticism points at real problems: a certification industry that produces Scrum Masters after a two-day course, frameworks sold as transformations, and scaling frameworks that some see as adding the bureaucracy agile set out to remove (see Scaling Agile). Other criticism is really about the anti-patterns on this page — about practices the frameworks themselves warn against.

A fair conclusion: frameworks are tools, and a tool used against its purpose gives poor results. When agile "does not work", the useful question is not "agile or not?" but "which part of our way of working stops us from getting fast, honest feedback — and what can we change first?"