It’s time to move on from Agile Software Development (It's not working) - My Opinionated Review

Recently I’ve bumped into this video from Dee called “It’s time to move on from Agile Software Development (It’s not working)”. It’s awesome! If you’re not following her, do so. I did. The video touches on a lot of the bad adaptations of so-called Agile methodologies to Software Development. While I really agree with most of the content, there are some ideas that I feel were only focused on the software developer side and not the company or product delivered. This is my opinionated review.

I’ll start with the bigger point for me, in this case a user comment saying that “Waterfall done well is better than agile done poorly”. Yes, that’s absolutely true. And while there are quite a lot of companies doing agile poorly, there are (or were, before agile became the trend) companies doing waterfall poorly as well.

Waterfall was replaced by agile almost as an avalanche. It did so for a reason, the ability to change and the iterative nature of agile. Yes, the developer is loving waterfall, he’s probably at the middle or close to the end of the project. Is only at the end where the waterfall problems start. It’s the final delivery, and the client sees the product and it doesn’t match the expectations. Worse, the time of development has already been entirely consumed and a lot of changes arise. The end result? Extra time for the developer that needs to implement the changes that resulted from bad interpretation of the initial project requirements. Is that or the company needs to delay the start of new projects because it can’t close the current one, but the developer is always pressured to deliver, since for the client, it is the company that is behind schedule. Both waterfall and agile will lead to the same outcome, over-stress.

This is a great bridge to the next point. The over saturation and burn out of the developers on agile. This is a pretty serious one. Not only developers, but almost every role in IT has this issue. This industry is stressful by nature. It’s not going to be the software development methodology that is going to change it. We live by estimates, and while they are just that, rough guess estimations, they are often treated as contracts. Not just it, there’s always tech debt rising, client changes, bugs that make you lose more time than expected… It’s not easy! Working without estimates or compromises, is like bartending on a Jamaica beach. A dream job! The nature of development it’s money/cost/profit at the end of the day. That’s why this job is stressful. Estimates and the release schedules are the contracts the company establishes with the client, and yes, with shorter cycles, they can represent more iterations , more estimations and hence more stress, but at the same time the feedback and steering gets shorter so there is less wasted time overall.

Imagine a high performance athlete. He/she has established aggressive objectives and trains every day to reach them. When the objectives aren’t met, it causes frustration. It’s the same with development when the estimates are not met, but they are needed because that is the only way the company has to macro plan its operations.

My next and final point is the “Meetings, Meetings, Meetings…”. Oh, so true… It gets even worse as you gain more responsibilities, your time coding gets replaced by more and more meetings. The key is actually to make them relevant. Does everyone need to attend all team meetings? I’m a strong believer that no. Stands ups should be short and focused on the daily steering or prioritization of the team. They are not for reporting who is working on what. For that end there are issue tracking tools. Since they’re short, it’s always good to have all the team, especially now with so much remote work. Sometimes it is the only time of the day where you actually interact with some of your team members. Grooming, refinements, planning meetings should not stop the entire team. Most of them are focused on the negotiation of 3 vectors: Product, Management and Engineering. At most it should be ok with a representative of each. Product or Project manager will always push to get the things done, define their priority and represent the client. The Manager or Team Lead act as the company and negotiate the deadlines and represent all the team. As for engineering, this is where I have my personal opinion that booking all the development team for hours is not efficient. This role can be fulfilled with a more senior engineer, or better yet, the so called Staff Engineer or Principal Engineer. It’s a role that needs to be aware of the project and needs to translate the product requirements into implementation details. It’s the one responsible for the technical executions of the project, so it needs to be aware of its implementation. As such, it’s the perfect role to make the estimations for the team instead of all of them spending hours playing poker.

A short word on retrospectives, as they tend to be long and full of discussions. It helps quite a lot of you bring your topics prepared. But keep the topics short and meaningful.

Does agile development have its problems? it does. Are they enough for us to revert to waterfall methodology? Please no!

As with everything in software development, we should use what is best and works for us. Is it SCRUM, KANBAN, or others? It is up to you to find out. One way or the other, it is the company standards that we need to follow to whom we do represent. This is not a “Stop Whining” post, I’m only stating that companies and the deliveries are the main focus. Only then comes the developers, that are the engines and the powerhouse of a software development company and as all engines they need to be fueled, oiled and clean to work properly. This is where the interpretation of these frameworks needs to be contextualized to the reality of each team. We don’t need an agile 2.0, each team needs to tune the agile that fits best for them.