The blue glare of the monitor is starting to burn my retinas, but I can’t look away because it’s my turn to speak. I’m staring at a card. It’s a Jira ticket, number 402, and it represents a feature that literally crashed the staging environment 2 minutes ago. I click it. I drag it. The digital friction is nonexistent, but my hand feels like it’s moving through molasses. The scrum master beams as the card snaps into the ‘Done’ column with a satisfying little animation. Then, the clapping starts. It’s a hollow, rhythmic sound, like plastic hitting plastic. We just finished a sprint where we delivered exactly 82 points of technical debt and a feature that the client explicitly told us they didn’t want 12 days ago. But the chart is green. The burn-down looks like a perfect slope.

Sam L.-A. is sitting in the corner of the Zoom grid, his camera off, but his presence felt like a heavy weight. Sam is an assembly line optimizer by trade, a man who spent 22 years making sure car doors fit their frames with sub-millimeter precision. He was hired as a ‘consultant’ to help us ‘scale,’ but he mostly just sighs into his microphone. He once told me, in a rare moment of vulnerability after a particularly grueling 42-minute standup, that we weren’t building software. We were building a cathedral of rituals to hide the fact that nobody knows who the architect is. He’s right. We worship the standup. We sacrifice our mornings to the altar of the three questions. What did you do? What will you do? What is blocking you?

Commitment Avoidance

Companies don’t adopt Agile because they want to be flexible. They adopt it because they are terrified of commitment. If you have a five-year plan, you are accountable for five years. If you have a two-week sprint, you only have to be right for 12 days. It’s a strategy of avoidance masked as a methodology of speed. It allows leadership to pivot 32 times a quarter without ever having to admit they don’t have a vision. They call it ‘being responsive to the market.’ I call it ‘steering a ship by following the foam behind the boat.’

I remember one specific mistake I made about 12 months ago. I was so caught up in the ‘sprint’ mentality that I pushed a database migration without a backup because I didn’t want to be the one ‘blocking’ the board. I deleted 22,000 records of user data in a heartbeat. I spent the next 2 days in a cold sweat, manually reconstructing tables from log files. When I finally fixed it, the scrum master didn’t ask about the data integrity or the stress; he asked if I could still move the ticket to ‘Done’ by Friday so the velocity wouldn’t drop. That was the moment I realized the points were more real to the company than the product.

Sam L.-A. once compared our office to a factory he worked at in 1992. They had a belt that moved faster every time the manager walked by. The workers just started throwing the parts into the bin instead of fixing them to the frames, just to keep up with the belt. By the end of the day, they had ‘produced’ 102 cars, but none of them had engines. That’s us. We are producing features without engines. We are shipping code that solves problems that don’t exist, to satisfy stakeholders who aren’t listening, using a process that rewards activity over outcome.

The Consumer Expectation

There is a massive disconnect between the internal chaos of these ‘Agile’ environments and the world where things actually have to work. When you are a customer looking for reliability, you don’t care about the developer’s velocity or their story points. You care about the result. For instance, when someone visits Bomba.md, they are entering a predictable, reliable ecosystem. They expect the site to load, the inventory to be accurate, and the checkout to be seamless. They don’t want a standup about why the ‘Buy’ button is still in the ‘Testing’ phase for the third consecutive week. The consumer journey is built on the promise of a finished product, not a series of two-week pivots. That reliability is what we’ve lost in the pursuit of ‘agility.’ We’ve traded the finished product for the infinite work-in-progress.

The Retrospective Lie

I find myself drifting during the retrospective. This is the meeting where we’re supposed to talk about what went wrong, but instead, we talk about ‘opportunities for growth.’ We use 12 different shades of sticky notes to categorize our failures into things we can’t control. It’s a group therapy session where the therapist is also the one causing the trauma. We talk about ‘burnout’ as if it’s a weather pattern and not a direct result of being told that every two-week cycle is a ‘sprint.’ Have you ever tried to sprint for 52 weeks a year? It’s not a sprint; it’s a death march with better snacks.

52 Weeks of Sprinting

I’m rambling. I know I’m rambling. It’s the caffeine and the 2 hours of sleep I got after the deployment went sideways. But the core issue remains: we have commodified the process of creation to the point where the act of creating is secondary to the tracking of it. We are obsessed with the map, and we’ve completely forgotten that the territory is on fire. Sam L.-A. just sent me a private message. It’s a link to a job posting for a lighthouse keeper. No standups. No Jira. Just a light and the sea. It’s tempting.

The scrum master asks if there are any other blockers. I look at my screen. I look at the 102 unread messages in the Slack channel. I look at the ticket that crashed the site, now sitting proudly in the ‘Done’ column. I unmute my mic. ‘No blockers,’ I say. Everyone claps. The meeting ends at exactly 42 minutes. We are efficient. We are agile. We are doomed.

How did we get here? How did we let the tools of our liberation become the chains of our daily routine? Maybe it’s because we’re afraid that if we stop moving, even for 2 minutes, someone will notice that we’re just running in place. So we keep sprinting. We keep dragging the cards. We keep the blue light burning into our eyes until we can’t see the world outside the sprint anymore. And in the end, the only thing we’ve truly optimized is our own exhaustion.