5 things wrong with Agile…and how I’d fix them
It’s been 7 and a half years since I first encountered the now dreaded term Agile. Well, not really dreaded, just…frowned upon a lot. And I dare say it’s not without good reason.
Agile started off like a really cool thing. A way in which developers can actually create code that mattered without having to redo everything on launch day? Sign me up…oh but how wrong we were.
You want to know when I first started absolutely despising this process and how it’s implemented? 2 months into my first job. No more, no less. Here I was, fresh out of college, full of enthusiasm, and wanting to code my way to happiness. Until finally, I hit the jackpot and entered a project with an actual client. Little did I know…
I vividly remember my first ever sprint planning meeting. 6 hours stuck in the same room, discussing XP points or whatever they’re called. That memory never left me and I think was one of the deciding factors in me finally pursuing my musical passion.
But I digress. Over the years, I have noticed certain things that ruined this process. And yes, I’m going to milk the fact that the original creators, or one of them anyway, said that the process is done for: linky-link.
But none have been more prevalent than the ones I’m going to describe to you today. Let’s start off with the fact that:
1. No one can decide on a bloody team format
The main problem Agile has is its somewhat inconsistent format (understatement of the millennium). Here are but a few ways in which I have seen it implemented in teams:
- with a business analyst
- without a business analyst
- sprints that lasted 1 week
- sprints that lasted 4 weeks
- sprints that last a vaguely defined amount of time between 1 and 4 weeks
At this point, as a developer, it’s really hard to understand what is expected of you. And no amount of adaptability will help you be productive in such inconsistent environments. It’s very easy to get distracted and lose both momentum and productivity.
The ideal format that I have found has the following traits:
- 2 week-long sprints, that start on Monday and end on Friday; only change this when holidays occur but never delay ending a sprint to the next week; end it earlier and plan accordingly
- with a business analyst if a project is large (e.g. an existing application that’s already in production); without a BA if the application is new or very young (a maximum of 6 months old)
- if a project requires a team larger than 5 members, there needs to be a dedicated Scrum Master to deal with administrative issues; I feel a Project Manager fits this bill perfectly
- changes in the backlog should be no bigger than 10 story points from the first estimations, meaning that in the end, you should have a maximum of 10 story points above or below the initial total number (that is, if you truly intend on keeping this metric; I’d recommend against it but…you know what, read more on this below)
- standard definitions of ready and done, with a task being considered complete once it has been analyzed, developed, reviewed, tested and of course approved by the client
- code reviews should take no longer than 15 minutes per task
2. There needs to be a backlog freeze
And it needs to be enforced with Doom Slayer like fierceness.
The sprint planning meeting is the meeting that decides what is to be done in the current sprint. The result of that meeting is a backlog of tasks. Once the 3rd day of the spring has ended, there are to be no changes allowed to the tasks. Any and all changes to the backlog need to be done before that. They also need to respect the whole 10 points criteria from above.
And I don’t want to hear the “but it’s a priority” excuse. This needs to be decided in the sprint planning meeting. And if something urgent actually shows up, the 3 days and 10 points rules still need to be respected.
There is an incessant desire to treat everything like a priority. I’ve seen it done numerous times. What you need to understand is the fact that when everything is a priority, nothing is. Decide on what actually brings value to your app and focus on that. The rest can be done later.
3. Complexity measurement needs to go
Freddie Mercury said, in his own words, he was a mediocre pianist. And yet when people listen to Bohemian Rhapsody, they’re like: “holy Maykrs, that song is absolutely the most beautiful and complex thing I’ve ever listened to”. Either that or they go like: “who’s Queen?”, like a former work colleague said, to my insane disbelief.
Measuring the complexity of something is impossible. I find modern pop songs boring and uninspired. But after doing a bit of reading on the whole music shtick, I learned why they are like this. It’s because they need to trigger weird algorithms that no one understands so they can get streams.
In the end, everything boils down to how much time you’ve worked on tasks. In short, the whole “story points determine complexity” should be replaced with “story points determine the necessary time I think it would take for a member of this team to finish the user story, and by finish I mean everything from development, to review and testing”.
4. Meeting times need to be “gone, reduced to atoms”
I cannot describe how many days of my life I’ve spent in meetings that overstayed their welcome by about 75% more than they actually needed to last.
Meetings are the main enemy of productivity. Especially when they are never-ending. Sprint planning should take no more than two hours. If no one can decide in a maximum of 10 minutes on what a story is about, drop it from the sprint. Trying to implement something that no one knows how to describe will result in an increase in frustration levels.
Daily meetings should under no circumstance last more than 15 minutes. Impromptu meetings should be kept at a minimum number and duration. Think 1–2 such meetings per week that should last a maximum of 30 minutes.
5. Every person needs to know their role
And preferably, every person needs to fill out a single role. That’s not to say everyone shouldn’t provide input, they should, but a single person must never fill more than one role.
There needs to be a clear understanding of what role each person in that team serves. Everyone needs to know who the developers are, who the managers are, and who the Product Owner is.
Also, everybody needs to know who they can ask for clarification regarding the task they are handling. In other words, there needs to be someone who has the final say regarding the output of the task. In my experience, it’s usually the Product Owner (or Owners).
Another thing I would add here is to not shy away from delegating. In other words, if the project would benefit from a dedicated person for a certain role, then, by all means, do it. Making someone be responsible for doing software development, being a team lead and a Scrum Master is going to end badly. And telling them to be a developer 80% of the time, a Scrum Master 10% of the time and a Team Lead the remaining 10% is even more confusing.
Conclusion
To say I’m not a fan of Agile is to say Doomguy is not a fan of demons. Especially the ones who went after Daisy, his pet rabbit.
That being said though, I am not really against this methodology, as I do feel that it has its good parts. It’s just that the bad parts tend to go haywire pretty fast if you’re not careful. And given how companies form a cult around this bad boy…you know what, tune in when I discuss the company cult. There’s way more to say about that than a simple paragraph.
Anyhow, hope you enjoyed my rambling here. If you have, check out the other articles I have around here.
If you’re interested in my music, you can stream it on Spotify and you can also follow me on Instagram (I am active there every single day).
Until next time, I wish you a pleasant day.
