Here is a tension worth sitting with. In 2025, 84% of Agile practitioners reported using AI in their delivery work, up from 68% a year earlier, according to Digital.ai’s 18th State of Agile Report. In roughly the same window, a study of 600 software engineers found that projects built on Agile Manifesto practices were 268% more likely to fail than projects that did the opposite. Adoption keeps climbing. Success does not. That gap is where managers either make Agile work or quietly sabotage it.
Most managers arrive at Agile confused about what it asks of them specifically, not as a team member, but as the person accountable for the team’s outcomes. Your team runs standups. Someone in a planning meeting says “we need to be more agile” without defining the term. And you are left to figure out where you fit in a system that, on paper, does not include a role called “manager.”
What Agile Actually Is (And What It Isn’t)
Agile is not a process, a set of meetings, or a project management tool. The Agile Manifesto, written in 2001 by seventeen software developers, is four values and twelve principles. The values are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Every word is deliberate. It does not say “no processes” or “no documentation.” It says over. Agile is a set of priorities, not a prohibition. Organizations that implement it by piling on more meetings, more tracking tools, and more documentation are doing the opposite of what the manifesto describes.
For managers, the value that matters most is the last one: responding to change over following a plan. This is where Agile collides with how most managers were trained. Traditional project management assumes you can define scope upfront, plan the work completely, then execute against that plan. Agile assumes that premise is usually wrong. Requirements shift, priorities move, and the ability to adapt beats the ability to predict.
There is an honest counterpoint here, though, and it is worth taking seriously. That same 2024 study by Dr Junade Ali and Engprax found that projects with clear requirements documented before development began were far more likely to succeed. “Responding to change” was never meant to be an excuse for starting work with no idea what you are building. The best Agile managers hold both truths at once: get clear on the problem before you commit, then stay willing to adjust as you learn.
Where the Manager Actually Fits
In classic Scrum, the most common Agile framework, there is no project manager role. There is a Product Owner who prioritizes the work, a Scrum Master who facilitates the process, and the team that does the work. Managers look at that structure and ask a fair question: where do I fit?
In most real organizations, the manager’s job shifts from directing work to enabling it. The Scrum Alliance frames it as setting the team up for success and then supporting from the boundary. In practice that means four things.
- Removing blockers. Your team should be able to work without waiting on you to make a decision. Clear the path; do not stand at the front of it.
- Maintaining context. Short cycles make teams lose sight of the larger strategy. You bridge that gap by connecting sprint work to business objectives.
- Protecting capacity. One of the fastest ways to break Agile is treating people as interchangeable resources you can pull mid-sprint. Protect the team’s ability to finish what they started.
- Supporting growth. Agile assumes teams improve through retrospectives and iteration. You support that through coaching, not correction.
The hard part is not the new responsibilities. It is letting go of the old ones. Delegating, stepping back from day-to-day decisions, and trusting the team to run their own work all feel counterintuitive. In Agile, the instinct to direct is often the very thing blocking the team.
The data shows how open the field is. The State of Agile Report found that 73% of practitioners want stronger leadership support and clearer alignment between delivery work and business goals, yet only 29% of Agile leaders are held accountable for connecting their team’s work to business outcomes. If you actually show up, understand the framework, and remove obstacles, you are already ahead of most managers in the discipline.
Scrum, Kanban, and Why Most Teams Blend Them
Scrum and Kanban are the two frameworks you will meet most often. They solve different problems.
Scrum organizes work into fixed-length iterations called sprints, usually one to four weeks. At the start, the team pulls a set of items from a prioritized backlog and commits to finishing them. At the end, they review what shipped and run a retrospective to improve the next cycle. Scrum fits complex, exploratory work where requirements shift, where the team needs a forcing function to ship, and where regular feedback improves quality. It struggles when work is highly unpredictable, or when external dependencies make sprint commitments unrealistic.
Kanban drops fixed iterations. Work flows continuously across a board (To Do, In Progress, Done), and the core discipline is limiting work in progress: you cannot start something new until something else is finished. That single rule prevents the common failure where everyone works on five things and finishes none. Kanban suits operational teams with a steady incoming stream, like support or maintenance, and it is a gentler entry point for teams not ready to commit to sprints.
Your job is not to pick a framework and enforce it. It is to understand the problem your team is solving and help them find an approach that fits. Most teams end up somewhere in the middle, and the data confirms it: 74% of organizations now use hybrid or blended models rather than a single pure framework. Sprint planning from Scrum, flow limits from Kanban, adapted to context.
The Uncomfortable Data on Agile Failure
Organizations spend enormous sums on Agile transformations that deliver little. Jeff Sutherland, co-creator of Scrum, estimates that 47% of Agile transformations fail outright. Broader research puts the share of transformations that never deliver the expected benefits at 70% or higher. The Engprax study went further still, finding a 65% failure rate among projects run on Agile-manifesto practices when the requirements were vague going in.
Read carefully, none of that is an indictment of Agile itself. It is an indictment of how managers implement it. The failure modes are well documented, and they almost all trace back to management behavior.
Waterfall in disguise. The team runs sprints, but scope is locked, the deadline is fixed, and any deviation needs an approval chain. That is waterfall with standups bolted on. Teams recognize it instantly and disengage.
Agile as a reporting mechanism. Burndown charts and velocity turn into performance dashboards. Managers optimize the metric instead of the outcome, so estimates inflate to protect velocity and scope quietly shrinks to hit the number. The performance management system ends up rewarding the gaming.
No real empowerment. The team is told to self-organize, but every meaningful decision still routes through the manager. The language is Agile; the authority structure is not. That combination breeds confusion and resentment.
No organizational support. Roughly 74% of transformation failures trace to a lack of organizational support. It is usually not the team failing. It is the environment refusing to change around them. If leadership treats Agile as an engineering experiment rather than an operating commitment, the odds are stacked from the start.
The through line: real Agile requires a genuine transfer of decision-making authority to the team. That is uncomfortable if you are used to being the decision point. Your value shifts to setting direction, holding alignment with strategy, and building the conditions for good work, not controlling the how.
AI Just Rewrote the Sprint
The biggest change since this topic was last worth revisiting is AI moving from the edges of the workflow into the center of it. The State of Agile Report calls this the “Fourth Wave” of software delivery: AI shifting from a supportive tool to something that helps orchestrate the whole delivery lifecycle. More than a quarter of organizations now report experimenting with agentic AI, systems that can act, decide, and optimize alongside people.
The problem is that the sprint was designed for humans. Agents do not estimate, do not get tired, and do not attend the daily standup, yet they are being dropped into backlogs built entirely around the assumption that a person does every task. That mismatch creates three practical questions for managers.
What does AI handle, and what stays human? AI is genuinely good at repetitive sprint work: drafting status updates, flagging blocked items, forecasting delivery risk from historical velocity, suggesting backlog priorities. It does not replace the judgment behind prioritization, stakeholder negotiation, or reading team dynamics. Draw that line explicitly so your team is not left guessing.
How do you keep quality while moving faster? Here is the gap the report exposed. AI adoption jumped to 84% in a single year, but only 49% of organizations have governance guardrails in place. Speed without governance manufactures problems faster than it solves them. The teams getting real results redesigned their review checkpoints before deploying agents, rather than bolting agents onto a process that never anticipated them.
How do you bring the team along? Some people adopt AI tools overnight; others resist. That is a change management problem, not a technology one. Start with low-stakes automation like meeting notes and backlog grooming suggestions before moving to anything customer-facing.
Managers who get this right use AI to amplify the original Agile principles: faster feedback, better retrospective data, less time on ceremony, more time on delivery. Managers who get it wrong use AI to generate more reporting layers, which is the same anti-pattern that has dogged Agile since the beginning.
What to Actually Do on Monday
You do not need a formal transformation or a Scrum certification to put Agile to work. Pick from these.
Keep a prioritized backlog. Maintain a visible, ranked list of your team’s work and update it as priorities move. The team should always know what matters most right now, and why.
Work in shorter cycles. Even without formal sprints, create regular review points where the team assesses what shipped, what they learned, and what comes next. Two weeks is a sound default. Monthly is usually too slow to steer by.
Limit work in progress. This is the highest-leverage change most teams can make. Cap what is actively in flight and finish before starting. The discomfort of having nothing to start signals the backlog needs attention, not that you should pull in more.
Run retrospectives that change something. After each cycle, answer three questions: what went well, what did not, and what will we do differently. Then actually change one thing. Retrospectives that never lead to action teach the team that retrospectives are theater.
Protect focus. Interruptions and mid-sprint scope changes are the enemy. Absorb those hits yourself and be the buffer between organizational chaos and your team’s focused work. That means saying “no,” or “not yet,” on the team’s behalf, which is one of the most valuable things a manager does.
Agile Is the Operating Layer, Not the Whole Job
Agile does not replace your broader responsibilities. It shapes how you carry them out. You still set direction, develop people, manage performance, and align the team with strategy. Agile handles the operational layer: how work gets planned, executed, reviewed, and improved. The framework runs the mechanics of the work. You still have to handle the humans, which is why the managers who get the most from Agile pair it with strong communication, useful one-on-ones, and the rest of the management fundamentals.
If your organization runs on a business operating system like EOS, Agile complements it cleanly. EOS sets the strategic rhythm (quarterly priorities, weekly leadership meetings) while Agile sets the execution rhythm at the team level. They work at different altitudes and rarely conflict when the boundary is clear.
The real shift Agile asks of you is not learning a framework. It is managing differently than you were managed: trusting people to decide, protecting their focus, and using every cycle to get a little better. Start with one practice this week, a ranked backlog, a WIP limit, or a retrospective you actually act on, and build from there.