Por qué cambié de opinión sobre las metodologías ágiles puristas
Hey everyone, it's Roberto Hernando here, a web developer with quite a few years under my belt. Today I want to talk to you about something that's been on my mind a lot, and something my opinion has really changed on: Agile methodologies. Yeah, those ones we all talk about that sometimes seem like the magic bullet for any project. I'm going to share my experience, from my initial fervor to my current, much more flexible and pragmatic stance. Let's see if you can relate, or at least, if it gives you something to think about.
My 'Agile Evangelist' Phase
When I started working with Agile methodologies, specifically Scrum, I became a total fanatic. I believed in everything, lock, stock, and barrel: two-week sprints, daily meetings, retrospectives, planning poker... everything! I thought it was the solution to all development problems, that it would put an end to never-ending projects and deliverables that looked nothing like what the client wanted. I remember in my previous company I tried (almost forced) everyone to adopt Scrum. I felt like anyone who wasn't doing it was rowing in the opposite direction. I felt like an evangelist, preaching the word of Agile to the four winds.
Of course, at first everything seemed to be going well. We had shorter sprints, the client saw progress faster, and it seemed like we were more organized. But little by little, problems started to emerge. The daily meetings became a fifteen-minute bore where everyone just spouted their stuff without listening to anyone else. Planning poker turned into an endless discussion about whether a task was 3 or 5 points (as if that mattered so much!). The retrospectives, into sessions of complaints and reproaches without arriving at concrete solutions. And worst of all: the feeling that we were following a process for the sake of following it, without really understanding why we were doing it.
The Reality Check: Rigidity Kills Creativity
The problem, I think, was that I was trying to apply Scrum to the letter, without adapting it to the needs of the project or the team. It was like trying to fit a square peg in a round hole. I had become so obsessed with the methodology that I had forgotten the most important thing: the people and the objective of the project. We started to lose flexibility, the real adaptability that Agile is supposed to provide. The rigidity of the process was stifling our creativity and ability to innovate.
Also, I realized that not all projects fit well with Scrum. There are smaller projects, with a small team, where perhaps it is more efficient to use a lighter approach, like Kanban. And there are projects where, simply, the client is not willing to participate actively in the process, which makes it very difficult to apply Scrum effectively.
Why Do I Think Agility is Important, Even if Not Purist?
Look, don't get me wrong. I'm not saying that Agile methodologies are useless. On the contrary, I think they are very valuable if applied correctly. What I mean is that we shouldn't be dogmatic. We can't think that one methodology is the magic solution to all problems. We have to adapt it to our needs, to our context, and to our culture. Agility, for me, is about having the ability to adapt quickly to changes, to collaborate closely with the client, and to deliver value continuously. And that can be achieved in many different ways.
What I've Learned: The Middle Ground is Key
After several years and many projects, I've come to the conclusion that the best thing is to find a middle ground. A hybrid approach that combines the best of Agile methodologies with a little common sense. For example, I still use sprints, but not always two weeks long. Sometimes I do them for a week, sometimes for three, depending on the complexity of the tasks. I also still do daily meetings, but I've reduced them to five minutes and focused them on solving concrete problems, not just a simple report of what I've done. And I do retrospectives when I really feel they are necessary, not obligatorily at the end of each sprint. Also, I'm not so obsessed with documentation anymore. I prefer to have well-commented code and solid automated tests than a bunch of documents that nobody is going to read.
Another important aspect I've learned is the importance of communication. Not only with the client, but also within the team. The more transparent and open the communication, the easier it will be to solve problems and adapt to changes. And of course, trust. Trusting the team, giving them autonomy and responsibility. In the end, they are the ones who are going to build the product, not me.
Final Thoughts
In short, my journey with Agile methodologies has been a path of constant learning. I started as an 'Agile Evangelist', convinced that I had the absolute truth. Then, I realized that reality was much more complex and that rigidity kills creativity. Now, I try to apply agility pragmatically, adapting it to each project and each team. And I think I've found a middle ground that works pretty well for me. I hope my experience helps you reflect on your own way of working and to find your own path to agility. In the end, that's what it's all about, right? To learn and improve constantly.
Now, tell me what you think. What has been your experience with Agile methodologies? Are you purists or do you prefer a more flexible approach? I'd love to read your comments!