The Thursday Grind: Rain, Retros, and the Art of Being the Last One Standing

Sometimes, the universe sends you a signal before you’ve even had your first cup of coffee. Today, that signal was loud, clear, and thoroughly damp.

This post isn’t about grand philosophical musings or travel diaries; it is just about today—the raw, unpolished reality of a Thursday in the life of an IT consultant. I honestly wasn’t looking forward to this day to begin with. In our current rhythm, the last Thursday of the sprint is reserved for the Retrospective and Review. For the uninitiated, that is usually a day of high tension. But this morning, the world decided to pile on a little extra friction just to keep things interesting.

It started with the rain—that relentless, gray drizzle that seeps into your bones. Then came the commute: an overcrowded train smelling of damp wool and exhaustion, accompanied by the modern torture of unstable 5G connectivity. And then, the cherry on top of this chaotic sundae: upon opening my laptop, I discovered my Chrome browser had simply vanished. Gone. Poof. I know, I know, there are better browsers out there. Purists will argue for privacy-focused alternatives, but creatures of habit like myself just want our bookmarks where we left them. Now, I’m stuck navigating my work-related pages on Edge, and staring at a Firefox icon I haven’t clicked in years. It’s a trivial tech issue, but on a day like today, it felt like a personal affront.

But let’s be honest, the missing browser is just a distraction. The real knot in my stomach is reserved for this afternoon.

For those of you who don’t work in software development, let me explain the concept of a "Retro" or "Sprint Review." It is a fundamental artifact of the Scrum/Agile methodology. Ideally, it is a safe space. At the end of every sprint (in our case, a three-week cycle), the team gathers to discuss what went well, what went wrong, and—most importantly—how we can improve. It is supposed to be constructive. It is supposed to be about process, not people.

However, theory and reality rarely shake hands in my current project. In our team, the Retro has devolved into a tri-weekly ritual of axe-grinding. It’s an arena where frustrations are vented, shortcomings are projected onto others, and the same voices dominate the airwaves with the same complaints. And today, I know exactly who the target is going to be.

To understand why the tension is so high, you have to understand the beast we are building. We aren’t building a simple webshop or a blog; we are building a massive Tax System. This isn’t just a matter of coding; it is a matter of bureaucracy. We are dealing with four different business units, plus a Legal department, plus a Procedure department. If you think getting two people to agree on a pizza topping is hard, try getting four government business units to agree on a taxation process.

We often spend weeks in meetings where the four business units debate and eventually reach a compromise. We, the IT team, take that agreement, document it, and start our analysis. We think we are safe. But then, two months later—like a delayed fuse—Legal and Procedure wake up. They swoop in and declare, "Actually, that’s not possible. You have to do it differently." The result? The work we’ve done is scrapped. The time is lost. And guess who gets blamed for the "delay" in delivery? It’s never the legal department for being late to the party; it is always IT for not being "agile" enough to pivot instantly.

Let me give you a concrete example of the madness we deal with. It’s a situation that actually made me say "WTF" out loud in the office. We had a hard requirement: before a user can file this specific tax declaration, they must apply for a special Tax Number. This number is crucial. From an IT perspective, this number is the unique identifier—it is the "coat rack" (or kapstok) upon which everything else hangs. The user account, the history, the validation rules—they all link back to this ID. We built the architecture around this fundamental truth. Then, out of the blue, the requirement changed. We were told, "Oh, actually, people should be able to file the tax declaration without having the Tax Number yet."

From a business perspective, that sounds "friendly." From an IT perspective, it is a catastrophe. If you remove the Tax Number, you have removed the coat rack. You are asking us to accept a tax filing into the system without knowing who it belongs to or what legal entity it is attached to. It is a record floating in a digital void. How do you validate it? How do you link it to a payment? How do you send a receipt? When I pointed this out—that we essentially built a house and they just removed the foundation—I was met with blank stares. "Just make it work," is the usual refrain.

But technical debt isn't the only thing piling up. The silence in the hallways is getting louder.

Recently, the atmosphere has shifted from "frantic" to "ominous." Why? Because the captains are taking the lifeboats. The two main drivers from our most critical business unit have withdrawn from the project. The Project Sponsor—the head honcho within the administration—has also left. Even the Business Project Manager has packed up and gone. (And yes, having a Project Manager on the business side while IT tries to work Agile is exactly as dysfunctional as it sounds).

It feels, to put it bluntly, like the rats are leaving the sinking ship.

The people who envisioned this system, who fought for the budget, and who made the initial promises... they are all gone. They have washed their hands of it. Now, only the execution layer remains. My own IT Manager has read the writing on the wall. His strategy has shifted from "delivering a robust system" to "Deliver an MVP (Minimum Viable Product) and Run." He wants to push something—anything—out the door so he can check a box and escape before the real fallout begins.

The biggest problem with this strategy is that there is no honor left to be gained here. Delivering this project according to the original quality standards and timeline is now mathematically impossible. We have passed the point of no return. In any other scenario—delay, budget overrun, or a buggy release—the organization will look for guilty parties. The political games to designate those scapegoats started months ago. And with the leadership gone, the finger-pointing is moving down the chain.

This brings me to the crux of my stress for this afternoon’s review. I am currently trying to wear three hats simultaneously to manage this chaos: Product Owner (on the IT side), Senior/Lead Analyst, and Business Analyst.

We all know the uncomfortable truth about trying to fill three full-time roles at once: you end up doing none of them well. It is an impossible equation. You cannot maintain the high-level strategic vision required of a Product Owner while simultaneously diving into the deep, technical weeds required of a Lead Analyst, and still find time to gather requirements like a Business Analyst. Something has to give. In my case, what gives is my sanity and the quality of the overall output, because I am stretched too thin to catch every single error.

This juggling act might be sustainable if I had a strong team of analysts to lean on, but that support structure is crumbling. My team consists mostly of juniors or mediors—people who, for whatever reason, lose the plot incredibly fast. They drown in details when they need to zoom out, and they gloss over the fundamentals when they need to dig deep. The developers aren’t blind to this, either. They know exactly where the weak links are. As a result, they don’t bother going to the other analysts with their questions. They come straight to me. My inbox and chat are perpetually flooded with questions that should be answered by the people actually assigned to the stories. I have become the bottleneck, not because I want to hoard knowledge, but because the developers know that if they ask me, they will get an answer, whereas if they ask elsewhere, they will get a blank stare. So, I end up doing the work of three people, plus the troubleshooting for the entire team.

I’ve tried to escalate this. I spoke to my employer last week to cover my bases—essentially a "Cover Your Ass" meeting to let them know I see the iceberg ahead. On Monday, I brought it up with the client manager. His response? "You’re too hard on yourself. You just need to prioritize."

We all know what "prioritize" means in corporate speak: it means "let some fires burn while you fight others," but it doesn’t solve the fact that the building is on fire.

I could ask my employer to find me a new project. I’ve been here two and a half years; I’ve done my time. But I feel a heavy sense of responsibility. Despite the chaos, I am learning a tremendous amount—mostly about how not to run a project, but also about the role of a Product Owner. That is the direction I want to grow in: maintaining the overview, guiding the vision, and stepping away from the nitty-gritty details. Right now, however, I’m stuck reviewing, correcting, and often completely rewriting the work of three other analysts. Sometimes I wonder if they add any value at all, or if they are just creating administrative overhead for me.

So, yes. In a few hours, I will walk into that meeting room. The big bosses are gone. The deadline is looming. The requirements are contradictory. And for two hours, I will likely be the scapegoat for a broken process, a confused business, and a rigid architecture.

But I’m ready. My strategy? When the accusations start flying and the tension rises, I’m just going to lean back. I will remain calm. I will take a deep breath. And I will remind myself of the most important fact of all: It’s just work. It’s just a job. And tomorrow is Friday. And the start of Carnaval!!!!

Cheers,
Peter