The Agile Paradox: Faster, but Slower
In 2001, something evil was invented. They thought this is the greatest way of building and managing the process. I am here to tell you how evil Agile is, how horrible it is, and why you shouldn’t use Agile. You will understand why the naming of this technique is wrong, it should be called “causes layoffs because of how slow it is and how inaccurate it is to measure the performance of developers”.
I believe I am gonna encounter “well ackhtually 🤓” people after publishing this. But hold your horses end swallow the pill first. And for godsake, grow up.
Let’s dive into some insights about agile:
The Agile philosophy promotes collective input from collaborators, partners, and customers to achieve its goals: deliver faster high-quality value, improve customer satisfaction, and build a company culture of continuous improvement.
It really brings together the team’s thoughts. Because it forces you to make unnecessary meetings.
The Daily Guy Who Always Talks About His Dog
Every day, you wake up, the first thing you need to do is attend the daily meeting. If you are lucky enough there will be < 5 people in the meeting. Also there is a scrum master as attendee. SM asks questions to everyone, “How is the process going with this task?” and you answer patiently. Because since invention of the evil, this question has been asking to innocent people. So you got used to it.
Some guy talks about his dog, another man talks about his weekend. And end of the day what everyone basically said is: “Yesterday I did what I had to do, today I will do what I have to do today”. Do you see how dumb this is going now? After 5-15 minutes meeting ends. So you go to work. But there is a bigger problem.
Non-Agile agile
One of my previous companies, at Service Department (which you take care of production e-commerce website) we were using Agile. I had the exact same process as what I wrote above. We had dailies, refinement and retrospective meetings. I believe that the only useful meeting is the refinement meeting, because its purpose is to decide whether a certain task is feasible, who can do it and brainstorm about it. That’s the end of how useful this meeting is, the rest is nonsense. The rest of the time we were scoring the tasks we received, but I always questioned how many points a task should be. According to what, according to whom, should this be the right score, did everyone understand the task correctly?
We had a document prepared by Tech Leads about how many points some task types should be. The task types in that document were very general. So more or less the document was like this:
- Low cost landing page -> x points
- Mid cost landing page -> 2x points
- High cost landing page -> 3x points
They had no idea how much they had screwed up.
After the meeting (this meetings were held at the end of the day usually, i.e the next day) you start doing the tasks. But in refinement meetings, the scrum master prioritizes the tasks. So, some tasks are urgent, others are not. Let’s imagine we have a task named “Change all spans in modal descriptions to p tags”. As far as I can see, this is not urgent. So, scrum master puts it last in the task queue. But if we have more urgent tasks then that, it could take days to change all spans to p. You think how simple this task is and you think (as a customer) they will probably do it in 1 day, pessimistically in 2 days. But no, if you have more urgent tasks you could do this task at end of the sprint, 10 days later?
As we can see, agile has became “non-agile” with this type of process. I am not going to recommend a brilliant way to solve all the agile problems in this post. And also this is not my job.
Nonsense Measurement System
After I finished my first month in this company, I was a few points below what was expected of me, both because I was new and because there weren’t that many tasks, because someone new had joined the team. One year after I left this job, a friend of mine who joined there told me about a thread started by tech leads in Slack (private channel accidentally made public for a few minutes), “Why are these guys’ KPIs so low?” thread. My name was also mentioned in that thread. In the next message, he also mentioned that a team leader said that these guys just started working, that’s why their KPIs are low. Imagine as a Tech Lead you make the interviews and when developer got accepted, you half-onboard them and yet you still ask why their KPIs are low, with your insufficient measurement system.
Conclusion
Agile is like Communism. Sounds good in theory, but it’s never actually been used successfully. And every time someone tells a story about it failing the apologists inevitably reply with, “but that wasn’t real agile.” I would suggest that if something is so hard to get right, then maybe it’s not such a great methodology after all.