It is no longer news that the tech industry has found its new accelerator. According to data released by GitHub, developers using AI tools like Copilot can complete tasks up to 55% faster. The promise is clear and seductive: deliver more code, in less time, with less effort.
But few pay attention to a question that must be asked before paying for subscriptions: are we heading in the right direction to accelerate?
Imagine that during a road trip you come across a huge, unpaved, and completely potholed road. You notice the car starts bouncing wildly, and to avoid losing control or damaging the vehicle, you decide to slow down and continue the trip at 1/4 of your planned speed. In this situation, do you think having a car with a more powerful engine (like a Ferrari's) would allow you to accelerate to maintain (or even increase) your planned speed? If your team suffers from priorities that change every Wednesday, Planning goals that are summarily ignored, and endless upstream dependencies, AI is not going to solve your problem.
On the contrary, it will amplify it. Accelerating the development pipeline in a chaotic environment doesn't generate innovation; it generates technical debt at the speed of light. And worst of all: your company probably does this while flaunting the "We are Agile" label.
In this article, we'll dissect how "Scrum Theater" combined with AI is destroying product reliability (and team morale), and why workflow design is the only way to pave this road.
The need for "We are Scrum"
If you ask 100 companies if they use agile methodologies, 99 will say yes. However, the State of Agile Report points out that year after year organizational culture and resistance to change (such as lack of business alignment) are the biggest obstacles to the true success of Agile.
In practice, what we see is the proliferation of Agile Theater:
- The Daily turns into a status report interrogation to justify worked hours.
- The Sprint Planning becomes a science fiction session, where the team commits to a goal that will be run over by an "urgent customer demand" two days later.
- The Retrospective does happen, but it turns into an empty ritual. The action plans raised are never put into practice because "we don't have time to stop and adjust now, we need to deliver". And worse, in a high-pressure environment, structural workflow issues start being taken personally. Those who can't take criticism get defensive, turning what should be a functional diagnosis into a battle of egos.
The attachment to the "process label" blinds companies to the reality of their own particularities. Scrum was designed to protect developers from interruptions during the Sprint cycle. If your scope changes in the middle of the iteration all the time, you are not doing Scrum; you are doing chaos-oriented management with colorful boards in Jira.
In many cases, it was exactly in this fragile and stressful scenario that the Artificial Intelligence hype landed.
The Invisible Bottleneck: The Upstream Pain
While the main stage of the Agile Theater focuses on pressuring the development squad to deliver more points per sprint, the true villain acts behind the scenes: the upstream.
The upstream represents everything that needs to happen before a developer can write the first line of useful code. If product specifications are shallow, if the design changes mid-iteration, or if the team depends on approvals from slow and bureaucratic areas, the engineering squad gets crushed.
The reality for many companies is that work doesn't flow; it gets pushed. Developers end up with multiple blocked cards in Jira, taking on the stress of trying to meet an unrealistic goal that was already born delayed and defective in another area. In this scenario, the team loses autonomy and transforms into a reactive "feature factory", putting out fires and trying to decipher half-baked requirements.
And this is where the hasty adoption of AI crosses a dangerous line.
Chatting about this topic with some developer friends, it was surprising to see that even working in companies across different tech fronts and even from different countries, we face very similar problems. For example, before the LLM boom, when a Project Manager (PM) or Product Manager hadn't fully mapped out a feature's business rules, it was evident. They explained it as best they could, and the developer, upon reading the card, could immediately identify the depth (or lack thereof) of that task's scope. It was easy to raise a hand and say: "This needs to be better understood with the client."
Today the dynamics have changed. An underprepared manager takes the little they understood from a meeting along with the transcript, throws it into an AI, asks it to "generate the requirements," and thinks, "Perfect, job done." What result do you expect to come out of this? In practice, what happens is that the developer receives a card with 50 lines of impeccable description, complete with Definition of Done (DoD), Definition of Ready (DoR), and acceptance criteria that look extremely professional, but are essentially generic and superficial. I personally consider it "less bad" to receive the actual prompt used to generate the requirements than to read 50 lines of something baseless.
In the end, not even the person who wrote the card knows exactly what they are asking for. AI has created an illusion of clarity. And what happens in practice? The developer is demanded to solve not just the technical solution, but to reverse-engineer the business rules that should have been defined way back, between the PM and the client.
Think about how many processes in your company this is happening to at this exact moment. Technical documentation, user manuals, requirement definitions, etc.
AI as a Technical Debt Accelerator
Wandering around the internet once, I saw a quote from philosopher and journalist Karl Kraus, who, in a critique of blind progress, said: "If humanity is marching toward the abyss, I would rather go on foot than in an automobile."
Giving generative AI tools to a team that lacks clarity on their responsibilities or a healthy workflow is exactly that: trading feet for a car heading towards the abyss. If it would take the company 100 days to fall off this cliff walking on foot, now it gets there in 10 days, fully motorized. If Planning was ignored and the scope of what needs to be done is nebulous, accelerating the rest of the process simply means building the wrong thing much faster.
AI manufactures entire epics, product documentation, test scripts, and code in a fast and voluminous way. But without proper planning and necessary oversight, the reliability of the entire value stream plummets. Studies like the one by GitClear mathematically prove the drop in software quality and the drastic increase in code churn (rapid code discarding), especially within 2 weeks of going to production, and this is just the final symptom of an entire chain that is sick.
The tech industry is creating what experts call a ticking time bomb of technical and organizational debt, where speed alone turns into a dangerous liability. The practical result in companies with this "Facade Scrum" is systemic: managers lose control of what truly generates value, QA teams are buried under artificially generated and inconsistent scenarios, and developers inherit requirements and systems they can't maintain or decipher months later.
But the problem was never the tool. AI is a fantastic engine; the problem is trying to use this engine to compensate for a misaligned steering wheel.
Paving the Road: Clarity before Speed
Reading this article, you might be thinking: "Wow, it's true, I'm going to immediately suggest we stop using Scrum at my company." Faced with a chaotic scenario, this is the instinctive reaction of many companies: looking for a new miraculous framework or trying to swap Scrum for a continuous flow. However, simply changing the management tool without reevaluating the teams is just changing the actors in this theater.
Before thinking about the workflow, you need to take a step back and rescue the clarity of functional responsibilities. If a manager is outsourcing the creation of business rules to AI, and the Developer is forced to act as a real-time requirements analyst to plug holes, the core problem is Team Design.
Researching how to pave this road, I came across studies that converge toward three structural pillars:
- The Rescue of Upstream (Real Product Discovery): Marty Cagan, in his book "Inspired: How to Create Tech Products Customers Love," argues that the biggest mistake tech companies make is pushing requirements to the engineering team without first investigating and mitigating risks (Value, Usability, Technical Feasibility, and Business Viability). Product discovery cannot be outsourced. AI can help refine texts, but it should never replace critical thinking and client negotiation. The product manager's role is not to fill out Jira as fast as possible; that's not how they'll guarantee the deadline promised to the client, it's by ensuring the right problem is being solved. Business rules need to be debated and deepened by humans before turning into prompts and distributed to developers.
- A Non-Negotiable Definition of Ready (DoR): Although the official Scrum guide talks about continuous refinement, the industry has adopted the Definition of Ready (DoR) as a quality gate. In Lean thinking (from Lean Software Development, derived from the Toyota Production System), injecting defective raw material into the assembly line creates a catastrophic bottleneck further down. In software development, the raw material is the requirement. The DoR is the technical team's official shield to reject "raw material" (AI-generated cards lacking depth) before it enters the pipeline and becomes technical debt. The engineering team needs the autonomy to block dysfunctional demands. An AI-generated card with 50 lines of generic scope cannot be considered "Ready for Development". The DoR must be a rigorous requirement quality filter, protecting the technical team from absorbing the chaos of the upstream.
- The Workflow as a Consequence: Modern organizational design literature proves that trying to force a working model without first understanding the team's topology is useless. Only when responsibility boundaries are clear (where the Product scope ends and Engineering begins) should the workflow be designed. Whether adopting Scrum, Kanban, or Unfix principles, the process must serve the company's reality, minimizing friction, cognitive load, and avoiding rework in progress. The workflow must be designed to reduce the cognitive load of developers; Conway's Law states that software systems are copies of the company's communication structures. If the communication between Product and Engineering is broken or outsourced to an AI, the code architecture will inevitably reflect this same breakdown and confusion.
Artificial Intelligence tools only become true superpowers when they operate on a solid organizational foundation. Accelerating the development pipeline without aligning who does what is the fastest path to collapse.
Conclusion: Direction before Speed
We all want to travel a smoother path as smoothly as possible. With each new innovation, the pace of tech companies has increased, the bar has been raised. We work in the field that experiences the most innovations; there are always new tools or new ways of doing things. Clinging to a way of working simply because "it's always been this way" is setting aside all other alternatives just because it seems easier. The awareness of where we are, why we use (or don't use) each process, and knowing where we want to go is what will provide a healthy and prosperous environment.
Before demanding speed and handing a motorized shovel to someone already digging their own grave, we need to prepare ourselves even more. A mature process absorbs innovation; a dysfunctional process is destroyed by it even faster.
Top comments (0)