Almost every IT team on earth will tell you they do Agile. Almost none of them actually do.
They have the standups. The sprints. The Jira board covered in tickets. All the ceremonies. And they have missed the entire point of why any of it exists.
I have been an IT project manager for over 10 years, and I have worked inside a lot of teams that called themselves Agile. Some of them genuinely were, and it was a completely different way of working. Most of them were running Scrum ceremonies on top of the exact same old command-and-control machine underneath. So this is not what a certification course taught me. I have watched the real thing, I have watched the costume version, and I can tell you exactly where the two split apart.
How ceremonies replaced the way of working
It is not that everyone is lying on purpose. Most teams genuinely believe they are Agile. They are just wrong about what the word means.
Somewhere along the way, Agile stopped meaning a way of working and started meaning a set of meetings. So a team looks at itself and goes, “we do a daily standup, we work in two-week sprints, we have a retro, there is a board with tickets on it. We are Agile.” Box checked.
Think about why that is the easy path. The ceremonies are simple to copy. You can install them in a week. You schedule some recurring meetings, you buy a Jira license, you send someone on a two-day Scrum course, and you look Agile. The actual thing Agile asks for is much harder, because it requires giving up control, changing how decisions get made, and trusting a team to run itself. Most organizations do not want to do that. So they take the part they can copy and skip the part that is hard.
It is easy to buy the ceremonies. It is hard to give up the control. So most companies keep the control, perform the ceremonies, and then wonder why nothing got better.
This is how you end up with the worst of both worlds. You have added a pile of new meetings to everyone’s calendar, but the way work actually gets decided and done has not changed at all. The org is still top-down. The team still cannot make its own calls. Deadlines still get handed down. You just wrapped all of that in Agile vocabulary. More overhead, none of the payoff.
What Agile is actually built on
Agile was never about standups and sprints. Those are tools. The actual point is a way of working built around four simple ideas.
- Short feedback loops. Build a little, show it to someone real, learn, adjust. Instead of disappearing for six months and hoping you built the right thing.
- Real prioritization. Always be working on the most valuable thing right now, and be willing to change what that is when the world changes.
- Empowered teams. The people doing the work can make decisions about how to do it, instead of waiting for permission on everything.
- Adapting to reality. When you learn something new, the plan changes. Reality wins over the plan.
Feedback, prioritization, ownership, adaptation. That is the whole thing.
Every Agile ceremony was invented to serve one of those four. The standup, the sprint, the retro. They are not the point. They are the delivery mechanism for the point. And a delivery mechanism with nothing inside it is just theater.
So here is the test for whether any team is actually Agile. For every ritual they perform, ask one question. Is this producing the thing it was designed to produce, or are we going through the motions? The ceremony can look identical either way. The difference is whether anything real is happening underneath it.
Let me walk you through the big ones, the real version next to the fake one.
Tell 1: the standup
Fifteen minutes, everyone together, quick sync. Simple.
Here is what it was designed for. The standup exists so the team can coordinate itself. People surface what they are blocked on, and other people on the team jump in to unblock them. “I am stuck waiting on the test environment.” “Oh, I can get you access after this.” It is the team helping the team, in real time, without a manager in the middle. The audience is each other.
The fake version: everybody goes around the circle and reports, one by one, what they did yesterday and what they will do today. But they are not talking to each other. They are talking to the manager or the lead standing there. It is a status update. It is the boss making sure everyone was busy. Nobody is unblocking anybody. People are performing productivity for the person in charge.
If your standup is everyone reporting to the manager instead of the team helping each other, that is not a standup. That is a status meeting with better branding.
The tell is easy to spot. In a real standup, people talk to each other and problems get solved on the spot. In a fake one, everyone stares at the manager, waits their turn, recites their update, and tunes out for everyone else’s. Same fifteen minutes, same circle, completely different thing happening. One is the team steering itself. The other is surveillance with a nicer name.
Tell 2: the sprint
The team works in fixed chunks of time, usually two weeks.
What is a sprint actually for? Two things. First, focus. The team commits to a small, specific set of work for those two weeks, and then that set is protected. Nobody gets to keep piling new things on mid-sprint. That protection is the entire point. It is what lets the team finish something instead of being yanked in ten directions. Second, at the end you are supposed to have something real. A small, working, potentially shippable piece you can put in front of a person and get feedback on. That is the short feedback loop in action.
The fake version: the sprint is just a two-week countdown. The team commits to some work, and on day three the boss walks in with three new urgent things and shoves them in. On day six, two more. Scope is a free-for-all. And at the end of the two weeks there is no working increment to show anyone. Just a pile of half-finished tickets that roll over into the next sprint, which is really the next two-week countdown to nowhere.
A real sprint is a promise the team gets to keep. A fake sprint is a deadline other people get to keep changing. If your scope gets rewritten every three days, you do not have sprints. You have a treadmill.
Notice what is missing in the fake version. Both of the things the sprint was for. There is no focus, because the work never stops changing. And there is no feedback loop, because nothing shippable ever comes out the other end. You have the word sprint on the calendar and none of what it was supposed to give you.
Trying to break into project management? Start here: How to become a project manager, the full step-by-step breakdown of the path.
Tell 3: the retro
At the end of each sprint, the team gets together and talks about how it went. What worked, what did not, what to change.
The retro is maybe the most important ceremony of all, because it is the one that is supposed to make the team better over time. The whole promise of Agile is a team that keeps improving, and the retro is the engine for that. The point is not to talk about problems. The point is that something actually changes because of that conversation. You identify one thing that is broken, you commit to a specific fix, and next sprint it is different.
The fake version is almost sad because it is so common. The team gets in a room. Everyone lists what went wrong, the same things that went wrong last time and the time before that. Somebody writes them on sticky notes. Everyone nods. And then nothing happens. Next sprint, the exact same problems show up and you have the exact same conversation. The retro becomes a place to vent, feel briefly heard, and change absolutely nothing.
A retro is not measured by what you talk about. It is measured by what is different next sprint. If your team complains about the same things month after month, you are running group therapy that does not work.
The tell here is the cleanest of all. Look back three sprints. Can the team point to specific things that changed because of a retro? If yes, it is real. If the retro is a recurring meeting where the same frustrations get aired and buried, that is not continuous improvement. That is continuous complaining on a schedule.
Tell 4: the backlog
The list of everything the team could work on, in theory ordered by priority, most important at the top.
What is it for? Real prioritization. A real backlog is ruthlessly ordered. There is a clear number one, a clear number two, and the team pulls work from the top. It is kept lean, because someone is constantly making the hard calls about what matters and what does not. The backlog is where the team decides what not to do, which is most of the job of prioritization.
The fake version is a graveyard. Four hundred tickets deep, going back two years, and nobody has touched the bottom three hundred since they were written. Nothing is really ordered. It is a giant pile labeled “stuff.” And because nothing is actually prioritized, what does the team work on? Whatever is on fire that day. Or whatever the loudest person demanded in the hallway. Or whatever the highest-paid person in the room said they wanted. The backlog exists, it is just decorative. The real prioritization is happening by panic and politics.
A backlog is not a list of everything you might do someday. It is a decision about what matters most right now. If nothing is truly ranked, you are not prioritizing. You are hoarding tickets.
The tell: ask a simple question. What is the single most important thing on this team right now, and why? On a real team, anyone can answer that instantly and they all give the same answer. On a fake-Agile team you get five different answers, or a shrug, or “well, it depends who you ask.” That confusion is the sound of a team that has a backlog but no prioritization.
Tell 5: the product owner
This is the one that quietly determines whether any of the rest can even work.
The product owner is supposed to be one person who owns what gets built and in what order. They talk to the users and the stakeholders, they understand what is actually valuable, and, this is the key part, they have the authority to decide. They can say yes. And more importantly, they can say no, and it sticks. That single empowered decision-maker is what makes real prioritization possible. There is one clear voice on what matters, so the team is not getting pulled apart by ten competing demands.
The fake version: the product owner has the title but none of the power. They are a ticket-writer, or a note-taker, or a project manager in a different hat who has to get sign-off from five other people before anything is decided. So when they say no, it does not mean anything, because anyone above them can overrule it and everyone knows it. Or worse, there is no real owner at all, and priorities get set by committee, which means they get set by whoever is most senior or most persistent in the meeting.
A product owner who cannot say no is not a product owner. They are a suggestion box with a job title. And a team without a real decider will always get pulled apart by whoever pushes hardest.
The tell is simple. When this person says “no, we are not doing that right now,” does it hold? Or does everyone know that a loud enough executive can walk in and flip it in five minutes? If the no does not stick, there is no real owner, and without a real owner everything else quietly falls apart. You can run every ceremony perfectly, but if nobody is empowered to decide what matters, you were never doing Agile in the first place.
The textbook-Agile team that was miserable
I worked with a team once that was, on paper, textbook Agile. Standups every morning. Two-week sprints. Retros with the sticky notes. A big Jira board. If you walked past their meetings you would have said these people are doing everything right. And they were completely miserable and constantly behind.
Because underneath all of it, nothing was protected and nobody could decide anything. Executives dropped new top priorities into the middle of every sprint. The product owner had the title but had to beg permission for every call. The retros were the same three complaints on a loop. All the ceremonies, none of the substance.
Here is the interesting part. The thing that fixed it was not more Agile. It was not a new tool or a fancier board or another certification. It was one boring change. Their manager finally agreed to one rule: once a sprint starts, the scope is locked. If something new is truly urgent, something else comes out, and that is the product owner’s call, and it holds.
That is it. One rule. Within about two months the team was calmer, faster, and actually shipping. Same people, same ceremonies, same board. The difference was that one piece of the real thing finally got switched on underneath the costume.
The ceremonies were never the problem, and they were never the solution. What matters is whether the real thing is running underneath them.
Three things you can do with this
1. Run the test on your own team. Take each ceremony, the standup, the sprint, the retro, and honestly ask whether it is producing the thing it was designed to produce. Are people unblocking each other, or reporting to the boss? Does scope hold, or get rewritten every three days? Does anything ever change after a retro? You will see your own situation clearly for the first time, and that clarity alone is worth a lot.
2. Use this in interviews. When someone asks about your Agile experience, do not recite the ceremonies. Everybody does that, and it sounds junior. Talk about the point of it instead: short feedback loops, real prioritization, empowered teams, adapting to reality. Mention that you have seen teams do all the rituals and miss all of that. The person interviewing you, if they know anything, will sit up, because you just proved you understand Agile at a level most candidates do not.
3. If you ever get to influence a team, reach for substance, not ceremony. You do not fix a struggling team by adding another meeting. You fix it by protecting one sprint, or empowering one real decision-maker, or making one retro actually change one thing. Small pieces of the real thing beat a full set of the fake thing every time.
Nobody needs more standups. What teams actually need is the thing the standup was supposed to deliver.
The problem was never Agile
I am not here to tell you Agile is a scam, or that the ceremonies are stupid. They are not. Done right, that way of working is genuinely powerful. The problem was never Agile. The problem is that most places kept the easy, visible part and quietly threw away the hard, valuable part, and then called the leftovers Agile.
Now you can see it. You can walk into any team, watch them for a week, and know the difference between a group that is actually working this way and a group that is performing the rituals. That is a rare kind of clarity, and it makes you more useful than a lot of people who have been in this world for years and still think the ceremonies are the point.
So do not get impressed by the standups and the sprints and the board full of tickets. Look underneath. Ask whether the real thing is running down there. Because that, and only that, tells you whether a team is actually Agile.
Keep reading
- What actually happens in an enterprise IT project
- What project managers actually do all day
- How project managers actually think
- Project management skills: the complete list
Ready to gain real IT PM experience?
Reading about how teams really work is not the same as running one. Inside The Eddie System you work through governed IT projects in a live PMO environment and make the calls yourself.
