Wednesday, June 12, 2024

Why am I not a big fan of Agile?

I was introduced to Agile few years ago. Having navigated some of the toughest markets and sectors, the Agile rhythm took me by surprise. I thought, "Alright, give it six months before passing judgment." After seeing agile close and from a distance, here’s the verdict. 

Now, if I’m generalizing and this doesn’t apply to how you run Agile, please share your tips so I can learn. If you’re reading further, I’m assuming you get Agile terminologies. If not, ask an AI tool. 

Agile has its perks. Regular rhythm, bi-weekly presentations, steady stream of deliverables, ceremonies, yada yada. Personally, I love the daily 15-minute stand-ups. They keep everyone on the same page. Plus, something that most people don’t realise, given its tightness, the stand-ups force us to be concise—no one has time for ramblers. My team sneers at marathon talkers. But those crisp updates? Love them! 

However, for me, the advantages seem to end there. Sure, Agile is a lifesaver for companies drowning in chaos and delays and those tech companies. But does it work for others? And is it a forever fix? Even in a chaotic setup, after a few quarters, you gotta ask: Should we pivot and transition away from conventional Agile to be more effective? As projects, teams, and organizations evolve, sticking to the same Agile playbook can backfire. Here’s why I am not a big fan of Agile:   

Everything is counted in sprints: Agile loves its sprints. Typically a two-week cycle to plan and execute tasks. Sounds good, right? Wrong. It’s maddening when colleagues talk in “next sprint” instead of “this Friday” or “coming Tuesday.” It leads to overestimation. Tasks that take 5-6 days get bloated into a sprint’s work. Agile thinks in two weeks. Miss this sprint? The next deadline isn’t two days later; it’s two weeks later. In high-stakes markets, we think in days, sometimes hours. Miss Tuesday? Sure, shit happens… how about Thursday?  

Too many ceremonies: Agile is bloated with ceremonies. Daily stand-ups? Great. Planning sessions? Necessary. But backlog refinement? Really? Why not combine it with stand-ups? And retros after each sprint? Humans need time to process what's going wrong or right (be it their project, organization, or their life...). A fortnight or two don’t always provide enough context. Conversely, if something’s off, fix it now, why wait for a retro? 

Performance and return are not always correlated: In Agile, there exists a role known as the Chapter Lead, a leader within a specific craft such as Design or DESL. This individual oversees members within their chapter, responsible for maintaining the excellence of their craft through continuous training, innovation, and governance. Additionally, they oversee the growth and compensation of their chapter members. On the other side, there's the Product Owner, tasked with achieving organizational objectives like revenue, ROI, or other metrics or creating products. Their team, or squad, consists of members from various chapters, pooled together to accomplish these goals. While squad members utilize their respective crafts to meet squad objectives and spend the majority of their time with the Product Owner, the latter doesn't play a role in or influence their professional development. For instance, a member of the Design team could excel in their craft but struggle with teamwork, meeting deadlines, or showing initiative. And yet take home a good raise at the end of the year as opposed to someone who contributed substantially to achieving organisational goals. 

Sprint reviews are a snooze fest: Preparing presentations every two weeks to a room full of glazed eyes? Kill me now. Why should anyone care about incremental shifts from Point A to B? I get why the audience claps robotically. Why spend hours making up a showcase of monumental progress when they’re mostly tiny steps from A to B from an organisational stand-point?  

So, what’s the solution? Stay tuned for the next post. Oh, and by the way, my squad consistently ranks top in deliveries and Agile maturity. I’m no expert, but I’ll share some secrets of how I run Agile.