So a project was "months" behind schedule, they implemented an agile process for tracking tasks, and "everything slowed"? Slower than what? Being months behind schedule?
I get that some PMs can undervalue refactoring code / minimizing technical debt, and that's super frustrating and shortsighted. But the basic premise of this criticism of agile process is deeply flawed:
1. The claim that features took "longer" to ship is directly contradictory to the admission that the project was months behind schedule.
2. If they were behind schedule, then "inflating" their estimates in response to a detailed tracking process was not, in fact, an inflation. It was a reality check.
Estimates are really hard. But the solution is not to just "give autonomy" with zero estimation, because that's how you get into that problem they had in the first place: a guy in a room that doesn't ship for months. That's why agile's approach of breaking things down into tasks with very rough sizing and measuring actual after-the-fact time and shipping small milestones frequently is so helpful. You don't have to have super accurate estimates. You just need to report your time and then it figures out a team "velocity". That helps teams be more predictable, which is what it means to be professional and deliver things to customers on time.
Yet agile implemented top-down without team ownership of what to work on is not agile and not good for the health of the codebase. I have seen it fail repeatedly.
Basically, if your team is skilled and capable, the process is not that important, as they will find a way to get things done. If the team is not good, the process won't make them much better. The key to a smoothly performing software dev team is good hiring and good coaching.
So if you're behind schedule, your team just isn't skilled enough? That's kind of a dodge. Every team can improve.
Instead of exclusively focusing on finding "good" developers, let's also focus on evolving "good" process. Time tracking, estimates, itemizing tasks.. these are in fact good things.
I would, and have, argue that estimates and time tracking are, in general, wasted effort.
If you have good priorities, estimates are irrelevant, because you'll be working on the most important things, and that is unlikely to change no matter the estimated effort. If you don't have estimates, then you don't need time tracking to see if your estimates are correct.
You've just eliminated half of the overhead for software development - the only added cost is that you must continually understand and update your priorities (or values, if you prefer), which you should be doing anyway.
I get that some PMs can undervalue refactoring code / minimizing technical debt, and that's super frustrating and shortsighted. But the basic premise of this criticism of agile process is deeply flawed:
1. The claim that features took "longer" to ship is directly contradictory to the admission that the project was months behind schedule.
2. If they were behind schedule, then "inflating" their estimates in response to a detailed tracking process was not, in fact, an inflation. It was a reality check.
Estimates are really hard. But the solution is not to just "give autonomy" with zero estimation, because that's how you get into that problem they had in the first place: a guy in a room that doesn't ship for months. That's why agile's approach of breaking things down into tasks with very rough sizing and measuring actual after-the-fact time and shipping small milestones frequently is so helpful. You don't have to have super accurate estimates. You just need to report your time and then it figures out a team "velocity". That helps teams be more predictable, which is what it means to be professional and deliver things to customers on time.