Processes, tools, and extensive documentation are not going to save your ass, but the Agile Manifesto may.
A friend just landed a job after a long hiatus. The very next day, I asked him if he’d been fired yet. I know, I’m mean, but with my close friends, this is how we communicate. Don’t judge.
He laughed (Narrator: in fact he did not) and then, for the bazillionth time, told me how nice it must be working at Microsoft. “You guys have all the processes, all the resources. Everything just works!”
Bro.
I spent almost 15 years working in “the third world” before Microsoft, and let me tell you—some of the development processes we had back then were better than what I see today at a trillion-dollar company. Money and expertise don’t automatically solve scaling challenges. It’s easier to implement great dynamics in a 20-person startup than in a massive corporation with legacy systems, layers of approvals, and a decision-making process that sometimes feels like a UN summit.
Now, don’t get me wrong, Microsoft is an incredible company. But the idea that every team runs like a well-oiled machine? Yeah, no. The reality is more like a massive airport: some gates are efficient, others make you question the meaning of life while waiting for baggage claim.
And speaking of processes, my friend then went off about how his company manages risks. Apparently, they… don’t. At all. (Yikes.)
But here’s the thing—I don’t believe risk management, planning, estimation, or any software development process should be rigidly standardized. A napkin with risks scribbled in coffee stains? Sometimes that’s all you need. The right process is the one that fits the context. My friend should have just observed for a few weeks before making recommendations. Instead, he came in on day two ready to change the world. Rookie mistake.
That’s when I thought, “Man, I need to write about Agile again.”
Because Agile—real Agile, not the bloated, over-processed, meeting-heavy nonsense some companies call Agile—is one of the greatest things to happen in software development. Maybe even the greatest. It wasn’t “created” so much as it was documented, an aspirational state that too many teams have somehow managed to turn into a bureaucratic nightmare.
But first, let’s be clear: SCRUM IS NOT AGILE. Agile is not a process or a set of processes, it is a mindset, a philosophy, a set of values and principles that guide how we work and interact.
So, let’s revisit the core Agile values, shall we?
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Think about it—what really matters? Having a process for communication, or actual communication? Working software, or a beautiful 200-page requirements doc that nobody reads? A solid plan for managing risks, or actually mitigating risks in real-time?
It’s like a restaurant. You don’t care how the kitchen is managed, what inventory system they use, or whether their supply chain is AI-powered—you just want good food, served on time, and not poisoned. Michelin-star restaurants have meticulous processes, sure, but at the end of the day, the result is what matters.
So next time you’re drowning in meetings about processes, ask yourself:
- Is it working?
- If not, is more process really the solution?
- Or is it actually about the people, the team dynamics, and the way we collaborate?
Think about it. And stay tuned—I’ll be writing more into these Agile values soon.
Take care. And share this with only friend in need.