Hi, Habr! My name is Anton, and I am a team lead at Ozon. I have spent more than twenty years in IT, including over fifteen years in management roles, and I have worked across a wide range of software projects. While developing my management approach, I repeatedly noticed that projects often ignored their most important concern: the customer—the person for whom we are actually building these products and systems.
Agile was meant to address exactly this problem. Its purpose was to keep teams close to customers and help them create a first-class product through continuous collaboration. People and communication come first in Agile, while technology is barely mentioned at all.
The problems with Agile are discussed not only by ordinary practitioners but also by people such as Robert C. Martin and Kent Beck, two of the authors of the Agile Manifesto. Allen Holub has observed that Agile has increasingly come to mean doing half of Scrum badly while using Jira.
Everyone knows the benefits associated with Agile. Over the years, however, I have identified several negative patterns. In this article, I will look at four consequences of using Agile poorly—consequences that undermine its effectiveness—and offer recommendations for fitting Agile into processes the business can understand.
I try to examine these problems equally from the perspectives of business and IT. I hope the article will therefore be useful not only to technical managers but also to people working in business functions.
Overheard in a Bar: An Agile Non-Comedy in Five Acts
Cast:
PM — either a project manager or a product manager. Management has not decided which, so he does both jobs. In our story, he represents the business. He is relatively young, loves Agile, and believes that everything will work if the methodology is applied correctly. He believes—or his company believes—that IT is often responsible for missed project deadlines. He is business-oriented, wants to create value for customers and the company, and focuses on results. He knows the theory well and enjoys being pedantic. He has almost no technical background.
TL — an experienced team lead who grew out of software development. He has spent a lot of time on projects with almost no requirements and one-way, coercive communication from the business. He understands Agile and other software development methods. He briefly worked as a PM in the past but returned to engineering. He wants to work in a company where business behaves reasonably and collaborates closely with IT. He keeps learning, listens to others, and has shown no signs of losing touch with reality during the past three years.
DEV — a senior developer who does not care much about project methodologies and has little patience for management, strategy, or corporate culture. He completes tasks and periodically changes companies for a better salary. At home, he works on a pet project that he still cannot launch. He enjoys trolling and memes, but he is always ready to help colleagues and solve difficult technical problems. He has deep expertise and has saved companies more than once when critical systems were close to collapse. He believes in clean code, design patterns, and the majesty of refactoring.
A random listener — an IT business consultant, speaker, and article author. He is taking notes on what he hears, hopefully with reasonable accuracy.
All the characters work in different teams or companies. TL, PM, and DEV have known one another for a long time.
Important: the situation described below is hypothetical. The characters are not intended as generalizations. They are products of the author’s imagination, created only to sharpen the ideas in the article. In other words, everyone is fictional and any resemblance is coincidental.
Act One: At the Bar After a Difficult Working Day
PM: …I still think Agile is a great thing. Its principles were written back in 2001, but they remain relevant and effective. There are only four values, so anyone can remember them:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
And remember the final part: while the things on the right have value, we value the things on the left more.
TL: Yes, yes, I have heard the story. A group of people got stuck high in the mountains and negotiated four principles that initially seemed acceptable to everyone. Now the rest of us have to clean up after them.
DEV: Not bad for a gathering at a ski resort. The most we ever did was drink hot tea from thermos flasks.
Despite the limited enthusiasm shown by TL and DEV, PM continued explaining the benefits and value of the Agile Manifesto.
PM: Look, the manifesto really does focus on people and results, but it does not dismiss processes, documentation, or plans. If people stop adding their own nonsense to it, it is genuinely good.
DEV: Could we stop talking and get back to work?
TL (continuing without noticing DEV): We work with people, though, and over time the meaning of these values has changed beyond recognition. Some elements were simply ignored. One of my former PMs used to say, “Who needs documentation? You are not writing the code in Sumerian.”
DEV: Right. The developer’s opinion has been ignored again.
TL (continuing): Another PM told us deadlines were just boxes to tick—until he lost his bonus for missing those boxes. Naturally, people become frustrated after experiences like that, and Agile gets blamed instead of project management.
DEV: Fine, I will add my two cents. Some of my colleagues hate Agile. To them, it is another word for chaos. There seems to be a plan, but there is not. Roles seem to be divided, but in reality nobody is responsible for anything. My friends at another company are obsessed with story points and burndown charts. Either way, I am still the person writing the code. Call it whatever you like—the routine stays the same: write, rewrite, write again. Let’s get a table and order some fries.
IT Suffers from Management
Act Two. The same people are now sitting at a table with fries and garlic bread.
TL (continuing with a mouthful of fries): Bad managers love Agile because it completely changes the balance between authority and responsibility. Suddenly you PMs gain the traditional power to tell the engineering team exactly what to do, how to do it, what to work on, and what to abandon immediately. Yet you take no responsibility. None at all. (He gestures and wipes ketchup from his hands.) Developers and testers are blamed for everything—usually testers, but we will leave that aside.
For you, a daily or retrospective becomes a ritual of accountability. When the team says, “What did we do wrong, and what can we improve?” everyone hears, “What did you do wrong, and how will you fix it during the next two weeks?”
DEV: Exactly. I choose tickets carefully so I have the smallest possible chance of messing up during the sprint. I do not want to spend the retrospective explaining why I missed something or broke a release.
TL: But what about value for the user? (He laughs.)
DEV mutters something indistinct and takes a drink.
TL: I also feel that our PM acts like a filter between us and the real users. We receive weak feedback that has been transformed by his interpretation. Our observations and questions seem to disappear into the sand. I start with a team of strong, capable specialists and end up with a group of dependent people who do only what he tells them.
PM: Who is “he”—the business?
TL: What business? The PM, obviously. I have started noticing that my developers are increasingly reluctant to take a ticket when it requires them to think, investigate, or make a judgment. Something is wrong. (He turns his glass in frustration.)
PM: Wait, I think I remember what that is called: learned helplessness. We covered it in some motivation course. Let me search. Here: in a state of learned helplessness, a person experiencing discomfort, pain, or other negative factors does not try to improve the situation, even when improvement is possible.
Look at this. (He shows TL his phone.) According to Martin Seligman, learned helplessness in people is accompanied by a loss of freedom and control, disbelief in the possibility of change and in their own abilities, weakened will, depression, and in extreme cases even death. We may have just uncovered the great mystery of rapid burnout in IT.
Business Suffers from IT
Act Three. The same group steps outside the bar for some air.
PM: Tell me something. In the past, programmers handled development. How did that turn into several separate roles? Now you ask the business for a business analyst, a systems analyst, and naturally a tester. All of that for work that one person used to perform. I will not even start on designers.
DEV: Everyone should do their own job. I write code. The rest is not my responsibility. Gathering business requirements certainly is not, and neither is thinking on behalf of the business.
TL (to PM): Do you not think projects have become more complex while the business still wants everything yesterday?
PM: How did people manage before? I do not mean you two specifically—I mean leads and developers. Team leads barely existed until recently. Where did they come from?
TL: We all know where. (He laughs.)
PM (thinking aloud): We are confidently moving toward microservices with clearly defined areas of responsibility, so projects should theoretically become simpler. I still do not understand. Do you not think that expanding teams has slowed down the delivery of change? A more experienced colleague told me that they once implemented entire ERP subsystems in a few days, without analysts or testers. Today the same work would take months.
And there were certainly no more defects than we would produce now.
DEV: Writing bad code does not require much intelligence.
TL: And you do not write any bad code today?
DEV: Oh, forget it.
PM: Fine, suppose you are right. Products must have become better, then. Releases must be free of bugs. And overloaded interfaces definitely do not exist in 2025.
DEV, TL, and PM silently watch an expensive car pass by.
PM (breaking the silence): Understand me correctly. I am not against analysts or testers. I object when developers deliberately put on blinders and become helpless whenever those analysts and testers are unavailable. Focusing only on code may work when you are implementing algorithms, but it creates problems when you encounter business requirements.
TL: I know one head of engineering who divides developers into coders and business programmers.
DEV: Good luck recruiting those.
TL: Did I say “head of engineering” instead of “team lead”?
PM: Got you. (He laughs.)
TL: I may agree that adding more roles makes communication harder and extends delivery times. Try getting everyone into the same sync or grooming session. I attend so many meetings across different projects that my brain sometimes melts and I confuse them. Once or twice, I even created tasks in the wrong project. People implemented them and the business accepted the result. Funny.
DEV: Do not worry. Sometimes I have no idea what I am doing, but the lead seems happy.
PM: Naturally. Every employee performing part of the work once handled by a programmer now reports as an isolated unit. Where do you think pointless features, security gaps, and interfaces designed for highly technical users come from? I am convinced that staff expansion and the division of work into micro-roles are the main reasons for chaotic systems and interfaces—not managers.
DEV: Slow down. Management has also been divided into micro-roles. You do not consider that a problem?
PM: Hmm. Perhaps that contributes too.
A Sprint as an Excuse to Demand More
Act Four. The group returns to the bar to finish eating and drinking before heading home.
DEV: I often feel that the only thing PMs care about is the deadline. You have pushed us into sprints whose endings feel like small deaths. The closer we get to the end, the more often you ask, “When? When?” Pressure, pressure, pressure. One of my former team leads liked to say that, according to the laws of physics, everything gets worse under pressure.
TL: Exactly. Then the retrospective becomes an exercise in shifting responsibility for missed deadlines onto us.
PM: Come on. We ask you for estimates, you calculate something, and you give us dates. Why become offended when we return after those dates and ask for the result?
DEV: Of course we estimate. The problem comes afterward.
TL: Afterward, the PM decides the estimate is unacceptable and asks us to deliver a small part of the task or project in half the time—sometimes even sooner. The estimate for that smaller piece is no longer proportional because we estimated the whole task, not an isolated fragment.
DEV: Yet they expect a complete product within that half-window.
PM: I think you are exaggerating.
TL: Are you saying this has never happened to you?
A waiter interrupts the conversation. The group pays and starts getting ready to leave.
DEV: The only thing left for me is to spend evenings and weekends building monstrous workarounds. Just thinking about it makes me shiver. Maybe I should change jobs. I am getting tired of this.
TL: Yes—overtime or the door.
DEV: You can hold as many meetings as you like and draw as many diagrams as you want, but sooner or later you will come to me and say, “Start digging.” Preferably yesterday, because you have already spent so much time discussing it. Your discussions can sometimes be shortened or replaced with documentation. My work cannot be replaced. There is no substitute for hard work here.
TL: Yes, but my PM does not understand that you can sometimes make people work more, while you cannot make them think faster. That creates a closed loop: overtime does not help, so we add more overtime, and everyone becomes completely dissatisfied.
PM: Many people I know call this “putting an elephant into a box.” It is depressing, but what if it produces results?
TL: Over what horizon? Once, perhaps. Over the long term, I doubt it.
They enter the metro and stand silently on the escalator.
Ignoring Technical Debt
Act Five. The same group is travelling home in a metro carriage.
TL: PM, tell me something. Why does the business refuse to take technical debt seriously?
PM: Business is moving forward at a crazy pace. We need features, and users may need them too. There is simply no time for your technical debt.
DEV: It is funny when the business does not even know the debt exists.
PM: Let us be honest. Your technical debt is not particularly interesting to us because we think in categories such as “bad code does not make money; good code does.” What happens under the hood is not really our concern. The business assumes that six months from now your code, whatever its quality, may no longer be needed.
TL: Interesting. Have you considered whose debt it is?
PM: Obviously yours. It is called technical debt. Find time to fix it wherever you can. You created the problem, so you repair it.
TL: I consider it a debt the business owes to IT because we had to deliver urgently while ignoring software engineering principles, quality, and patterns.
PM: I can already imagine you going to the CEO and saying, “We have technical debt, but it is not ours—it is yours. Give us capacity, budget, and priority.”
TL: It is called debt for a reason. At some point, someone will demand repayment, and nobody is likely to forgive it. Worst of all, repayment may be demanded at two in the morning during the peak sales season. The consequences will affect everyone, but the business will suffer first. I think a CEO would understand that framing.
DEV: I absolutely love fixing production workarounds at night.
PM: Yes, it clearly hits the business first. (He looks at the metro map and thinks.) Following that logic, is there such a thing as business debt—debt that IT owes to the business?
TL: Of course. We usually call it the project portfolio.
DEV: Nice wordplay. Maybe business and IT should agree on terminology before opening the black box labelled “development.”
PM: The problems of our world are communication problems, not failures to follow instructions. What a mess.
TL gets off at his station. PM and DEV look at their phones.
How We Adapt Agile
Our characters have highlighted several painful issues. Now let us look at what can be done about them. One point is important: we do not worship Agile or try to turn the organization into a model Agile company. Our goal is to make the company resilient to change and adaptable to customer needs.
To achieve this, we developed a flow that we follow when delivering projects. Teams may adapt individual elements of the flow to the specific characteristics of their services, projects, and products.
High-Level Flow
What do you want: to win or not to lose?
What is the difference?
Those are two different strategies.
Strategically, tasks can be divided into three categories: protecting market share, increasing market share, and creating a new market.
Work in these categories is usually represented as projects or products and prioritized during dedicated meetings. Each engineering area has capacity allocated to different categories. For example, 20% may be assigned to technical debt, 40% to strategic projects, and 40% to medium-sized projects. Work within each allocation is prioritized using many criteria: money, reputation, convenience, deadlines, and others.
The most important point is that representatives of both business functions and IT participate in prioritization.
Technical debt can be treated as a retention activity because customer satisfaction directly depends on the stability and quality of existing systems. It can also be treated as growth work when the number of customers the company can serve is constrained by the capabilities of its information systems. The business understands that technical debt does not appear from nowhere. It often results from delivering under extreme time pressure or from changes in business processes.
Time must therefore be allocated to closing these gaps. Such discussions are one of the key points of interaction between business and IT.
For IT, the selected initiatives are represented as large umbrella epics. Their combination, adjusted for priority, becomes the roadmap for an area, department, or group. Every team therefore understands the approximate amount of work expected by particular periods, including technical-debt work.
When a project contains several stages, we perform another exercise: we draw a high-level implementation plan as a Gantt chart. This is particularly useful for identifying critical paths. A small project can immediately be divided from one umbrella epic into sub-epics or stories. An extremely large project is divided into phases or milestones, each of which is treated as a separate project within the same flow.
Plans are useless, but planning is indispensable. — Dwight D. Eisenhower
The tasks themselves are then implemented using Agile practices chosen by the team. One team may use Scrum, another Kanban, and a third—such as mine—may combine both. In that model, the sprint acts as a mini-milestone while tasks move through Kanban inside it.
The benefit is that business functions can manage deadlines at a high level or drill down as far as a specific task. In practice, umbrella epics and Gantt charts are usually sufficient. IT teams receive clear boundaries and timeframes, which helps them organize and synchronize work, especially across domains.
The idea can be summarized as follows: you know what must be done; decide for yourselves how to do it. You are professionals, and we trust you.
When questions, difficulties, or proposals appear during implementation, we can return to the business—for example, to reprioritize work or reduce project scope. Business teams often meet us halfway, and we return the favor when something new must be delivered that was not discussed at the beginning. Business listens to us, and we listen to the business, especially when “meteorites” appear.
Meteorites are urgent, unplanned tasks. They are often caused by regulatory changes or reactions to feedback from customers and operational functions that influence delivery speed and the handover of long-awaited orders.
What killed the dinosaurs: one asteroid or a shower of meteorites?
Now I am no longer sure.
Activities
Let us look briefly at the activities that accompany almost every project. As mentioned earlier, a team usually works on several projects at once, including technical-debt initiatives.
These activities are not carved in stone. If I believe the team should finish important tasks instead of holding a retrospective, demo, or another meeting, I will cancel the activity or ask specific people to skip it. The main rule I recommend for every meeting is to involve only the minimum necessary number of people.
Activities that require complex technical decisions are better scheduled during the first half of the day. Our cognitive performance begins to decline around 11:30, and the period after 14:00 is more suitable for less demanding work. The time around 18:00 can be effective for generating new ideas.
Retrospectives and demos work well on Friday evenings. By the end of the week, people have less appetite for routine work and are already thinking about the weekend, so the element of a show fits naturally. This timing also helps the team end the working week on a positive note.
The golden rule is simple: do not take your engineering team’s most productive development time away from them.
Kickoff meeting. Agree on project goals, success criteria, and stopping criteria. Align the views of IT and business one final time. IT naturally focuses more on requirements, the project vision, and risks visible from the technical side. Project goals generally come from the business.
Presentation to the engineering team. Help the team understand the project and involve engineers in its business purpose. Do not forget designers: they need to be immersed in the project from the beginning. I have seen companies involve designers only near the end and then discover major UX problems that required serious rework.
Epic or story grooming with the business. Questions usually emerge after the initial presentation and can be resolved with business stakeholders. Focus on “what,” not “how.” Do not discuss technical implementation at this stage.
Task grooming with the engineering team. Discuss the technical options for implementation and focus on “how.” Prefer proven solutions and technologies. The amount of work should be as small as possible while the effect remains predictable.
Dailies. Hold regular short meetings of no more than fifteen minutes for project participants. Synchronize, share progress and new information, and make problems visible. An interrogation built around “what did you do and what will you do?” is not our preferred format. It is better to discuss open questions and obstacles. The facilitator should watch the time and stop arguments; a separate meeting can be arranged when a debate needs more space.
Frequency depends on project complexity—from every day to several times per week—but at least one meeting should fall on Monday.
Demo. Present work results to business functions and future users to collect feedback and suggestions. A demo can also show ideas and work in progress, allowing feedback before final implementation. In effect, it can become a place for discussing open or controversial questions with the business and end users.
Phase retrospective. Review mistakes, especially after a demo. Collect problems and suggestions from the project team for improving the development process.
Ad hoc meetings. Use these to solve urgent problems with only the necessary participants. They can also accelerate code review. Do not overuse them, particularly when developers are involved, or people will spend the entire day in meetings instead of writing code.
Project closure. Close the project during the same business meetings where umbrella epics are prioritized—ideally to enthusiastic applause. After major projects, hold a retrospective with the customers and discuss openly what could have been done better.
The ability to voice real problems without political decoration genuinely improves the process. That is why interaction between business and IT should be as transparent as possible.
Instead of a Retrospective
Let us look once more at the Agile Manifesto, this time through the lens of adaptation.
1. Pay Attention to People and to the Tools They Use
- People create products for other people—different people, sometimes very different people.
- People should not waste time on unnecessary bureaucracy. Follow Lean’s principle of eliminating waste.
- Professionals need professional tools. When suitable tools cannot be bought, allocate resources to build them.
2. Aim for a Working Product That Users Can Use and Developers Can Support
- The product must address real user needs.
- The interface should follow a familiar standard, be common within the company, or be supported by documentation.
- A developer from another team should need as little time as possible to understand the project. Standard service templates, current documentation, and shared company practices help.
- Work with the customer and record agreements to improve collaboration.
3. The Customer Has Responsibilities as Well as Rights
Responsibilities may include responding to the team’s observations and proposals, clarifying unknowns, and testing the results of development.
- An agreement is a documented result of negotiation: a portal article, a properly described task, an addendum to a contract, or another durable artifact.
- Use a win-win approach. Recognize the interests of both the business and the engineering team. There are people on both sides.
- Create a development plan, but reserve time for change.
- Follow the tree principle: a solid foundation in the roots and flexible processes in the branches.
- Separate business requirements by necessity and criticality. The situation is rarely as simple as it first appears.
- Sometimes you need to say no, and that is normal.
Agile is not a cure-all. It is not a truth carved in stone that must be followed without question. Agile is only a manifesto—a philosophy formulated in the mountains by a small group of people. Its purpose is to help you reach the main goal: creating value for the user. Nothing more.
There is nothing wrong with being unable to use it on some projects or combining it with other methods on others.
Your toolbox contains more than a hammer, and not everything around you is necessarily a nail.