Pressing my thumb against the sharp, cold edge of the glass conference table, I watch the sweat from a chilled water bottle pool into a perfect, mocking circle. The room is quiet, save for the hum of the HVAC that sounds like it’s gasping for air. We are 13 minutes into the sprint retrospective, and the silence is heavy enough to crush a skull. Across from me, three developers are staring at their shoes as if the answers to our missed deadlines are written in the scuff marks on their sneakers. This is the 23rd time this year we’ve sat here, performing the ritual of the post-mortem without ever admitting the body is still warm. We call it Agile, but the air in here feels remarkably like a stagnant pond. I’m Harper A., and my job is to manage the reputations of companies that swear they are the future, while their internals are rusted shut by 19th-century management philosophies.
The Illusion of Speed
I just parallel parked a seven-seater SUV into a space meant for a compact car on the first try. That act-precise, spatial, and inherently honest-is the exact opposite of what’s happening in this room. In my car, the feedback loop was immediate. If I turned too late, I hit the curb. If I turned too early, I clipped the bumper. The physics didn’t care about my intentions. But here, in the world of ‘agile’ software development, we’ve found a way to lie to the physics. We take a six-month project, chop it into 23 pieces, and call them ‘sprints,’ even though the direction is set in stone by someone who hasn’t touched a line of code since 2003. We aren’t moving faster; we’re just tripping more often and calling it ‘failing fast.’
Tripping
Frequent stumbles
Failing
The call to action
‘Fast’
The perceived speed
Management loves the vocabulary. They love saying ‘pivot’ because it sounds like they’re in a ballet instead of a car crash. They love ‘scrum’ because it implies a rugged, athletic camaraderie that they don’t actually want to participate in. What they really want is the same old predictive certainty they had in 1993, but with the cool stickers and the open-office floor plan. It’s a reputation problem. It’s my problem. I spend 43 hours a week convincing the public that these companies are nimble, while the internal reality is a series of ‘urgent’ meetings that could have been an email, or better yet, a moment of silent reflection. We’ve replaced actual productivity with the performance of productivity. We move sticky notes across a board like we’re playing a game of Tetris where the pieces never actually disappear.
The sticky note is the unit of corporate delusion.
The Hostage Situation with Better Snacks
I remember working with a firm that had 103 developers all working on a single monolithic architecture. They insisted they were agile. They had the stand-ups. They had the burn-down charts that looked like a mountain range drawn by a child with a fever. But the CEO wouldn’t let a single feature go live without a 73-page sign-off document that took 3 weeks to route through legal. That’s not agile; that’s a hostage situation with better snacks. People like me, the reputation managers, are the ones who have to spin this. We have to tell the story of ‘innovation at scale’ while the engineers are burning out because they’re being asked to be ‘flexible’ about their weekend plans but ‘rigid’ about a spec that was written in a vacuum.
There is a specific kind of hypocrisy in a manager who demands a ‘velocity’ increase of 13 percent while simultaneously adding 3 extra layers of approval for every pull request. It’s like asking a runner to sprint while you’re busy tying their shoelaces together. I’ve seen this play out in 3 different industries this year alone. We’ve adopted the ceremonies of Agile-the daily stand-up where everyone stands in a circle and lies to each other for 13 minutes-without adopting the mindset. The mindset requires trust. Trust is hard. Trust is expensive. Trust doesn’t have a Jira ticket.
Velocity Increase
Tied Together
Transparency as an Enemy
I often find myself looking for clarity in places where the structure is actually visible and honest. When I’m designing my own space, or even just thinking about how to manage a brand’s public image, I look for things that don’t hide their purpose. For instance, when you look at a well-designed bathroom, like the sleek lines of a duschkabine 1m x 1m enclosure, there is a transparency there that management avoids. You see the glass, you see the frame, you see the function. There is no ‘hidden’ waterfall logic behind a glass door. It is what it is. In software, we hide our waterfalls behind ‘agile’ curtains, and then we wonder why everyone is getting wet when they thought they were standing in a dry room.
Clear Function
Visible parts
Hidden Waterfall
Agile’s veil
Let’s talk about the ‘sprint.’ The word itself implies a burst of energy followed by rest. But in most ‘agile’ shops, it’s just a marathon where the coach yells ‘sprint!’ every 2 weeks for 3 years straight. I’ve seen 83-year-old companies try to implement this and fail because they can’t let go of the hierarchy. They want the ‘squads’ and the ‘tribes’ (blame Spotify for that particular brand of corporate LARPing), but they still want the 3rd-floor VP to have the final say on the hex code for a button. It creates a dissonance that manifests as a Glassdoor rating of 2.3 stars. That’s where I come in. I have to explain why the culture isn’t ‘toxic,’ it’s just ‘evolving.’ But between you and me, evolution usually involves some things dying off so others can live. In this case, the thing that needs to die is the idea that you can control creativity with a spreadsheet.
Measuring the Wrong Things
I’m not saying Agile is a bad idea. In its original form-the Manifesto-it was a beautiful, almost poetic call for humanity in a technical field. It prioritized ‘individuals and interactions over tools.’ But go into any corporate office today and look at the tools. They are obsessed with the tools. They spend $503 a month per seat on software to track the work, but they won’t spend 3 minutes actually listening to the person doing the work. They’ve weaponized a philosophy of freedom into a methodology of surveillance. We have 13 metrics for productivity but zero metrics for joy or technical debt or the number of times a developer wanted to throw their laptop out a window.
Quantified Output
Joy & Sanity
The car is speeding, but the engine is burning.
Embracing Chaos or Marching?
There’s a certain rhythm to a failing project. It starts with a 3-day retreat to ‘align.’ It ends with a 3-week scramble to ‘ship anything.’ In the middle is the long, dark night of the soul where everyone knows the requirements are wrong but nobody has the ‘permission’ to change them. This is the contradiction I live in. I advise these leaders on how to look ‘bold’ and ‘disruptive’ while I watch them tremble at the thought of a developer actually changing a priority mid-sprint. They want the reputation of a startup with the safety of a utility company. It doesn’t work. You can’t have both. You either embrace the chaos of genuine agility or you settle for the slow, dignified march of the waterfall. Just don’t call the march a dance.
I find myself thinking back to that parallel park. It was successful because I didn’t have a committee telling me how to turn the wheel. I didn’t have a product owner defining the ‘user story’ of the curb. I had a clear goal, a set of constraints, and the autonomy to act. If management really wanted agile, they’d stop being managers and start being coaches. They’d provide the space and the resources, then get out of the way. But that requires a level of vulnerability that most VPs haven’t felt since 1983. They are afraid that if they aren’t ‘managing,’ they aren’t valuable. They don’t realize that their value should be in removing obstacles, not being the biggest one.
Dignified March
Embrace Chaos
We recently had a client who claimed they were ‘customer-obsessed.’ They had 3 different departments dedicated to ‘the user journey.’ Yet, when a developer suggested a 3-hour fix for a bug that affected 13 percent of the user base, it was rejected because it wasn’t in the ‘sprint plan.’ The plan had become more important than the person it was supposed to serve. That’s the moment Agile died. It died when the ‘plan’ became the master instead of the tool. I watched that company’s reputation crumble in real-time as the bug went viral on social media. My job was to ‘contain’ the narrative, but how do you contain the truth that your company is too ‘agile’ to actually help its customers?
Beyond Buzzwords: True Help
If we are going to fix this, we have to stop using the words. Stop saying ‘scrum,’ stop saying ‘kanban,’ stop saying ‘velocity.’ Instead, let’s talk about ‘help.’ How can I help you get this done? What is stopping you from shipping today? Why are we doing this at all? These are the questions that terrify management because they don’t have 3-point answers. They require a level of honesty that doesn’t fit on a slide deck. As an online reputation manager, I see the cracks before the light gets in. I see the frustration in the anonymous Slack channels and the cynical memes that circulate in the 3:00 AM hours.
The industry is tired. We are tired of the rebranding of old mistakes. We are tired of the ‘Agile Coaches’ who have never shipped a product but have 33 certifications in how to talk about shipping products. We want something that feels like that perfect parallel park-a movement that is efficient, purposeful, and real. Until then, I’ll keep managing the reputations, I’ll keep spinning the ‘pivots,’ and I’ll keep watching the water pool on the glass tables, waiting for someone to finally admit that the ship isn’t moving, no matter how many times we stand up to talk about it.
The Ship Isn’t Moving
No matter how many stand-ups, the vessel remains stationary.