When Agility Stumbles in Development Teams
“Estimating tasks will slow you down. Don’t do it.”
Jeff Sutherland, the co-creator of Scrum, has been known to express skepticism about the efficacy of task estimation in Agile methodologies. He has mentioned that estimating tasks will slow you down, to note that his teams abandoned this practice over ten years ago. This perspective is based on observations from data involving 60,000 teams, suggesting that teams that do not engage in task estimation tend to perform better than those that do. According to Sutherland, the best teams focus on small stories and move towards acceptance test-driven development, avoiding detailed task estimations.
Promising flexibility, adaptability, and a continuous delivery model, Agile has been widely and blindly adopted with the intent of improving productivity and responsiveness. However, beneath the surface of sprint meetings and boards, a growing number of critics argues that Agile might not be the ideal fit for all or any development team.
Is Agile tripping? or perhaps I’m just becoming a critic?
Meetings, and meetings, and more …
One of the foundational elements of Agile is frequent meetings — daily stand-ups, sprint planning, retrospectives, reviews, and the new end of month that someone just added to this madness. Designed to keep everyone on the same page and projects on track, these meetings have become a point of contention. They often devolve into time-consuming distractions that interrupt the deep work necessary for complex problem-solving and coding. Developers might spend more time discussing work than actually doing it, leading to a paradox where agility in process sacrifices efficiency in output.
Imagine a backend software developer being added to 20 different channels, and being tagged every 5 minutes on all this channels. Now imagine, this same person going to 3–4 different meetings, on daily basis, to respond to the messages he/she already replied on these channels.
Software developers are at their most productive when given uninterrupted time to focus. In contrast, the interruptive nature of constant meetings can lead to context switching, which decrease productivity. When developers are pulled into frequent check-ins, the cognitive load of resuming their tasks can diminish both the quality and quantity of code they produce, so lets not wonder why we found missing requirements or issues all around.
Feedback on the above, give back time to developers by properly communicating what you need on small tasks with less than 5 action items. Keep it short and concise. Read that again <
The Tyranny of Metrics and Task Estimation
Velocity, burn-down graphs, and story points are used to measure the progress of development teams. However, when these metrics are misapplied as performance indicators rather than planning tools, they can foster a counterproductive environment. The focus shifts from creating quality code to hitting arbitrary numbers, which can incentivize quick fixes, hot fixes, and superficial completions over thorough and innovative solutions.
Task estimation, a core Agile practice, involves predicting how long tasks will take to complete. While useful in theory, the practice can lead to significant stress and reduced productivity. Estimation is notoriously difficult in software development, where unexpected “complexities”(not to say delays or third party nonsense) can derail even the most experienced seniors. The pressure to meet these estimates can lead to rushed work or cut corners, ultimately degrading the quality of the software and quality it self.
Feedback on the above, IF you work on a team that does hot fixes on each and every sprint release, this may be a reflection of a burnout or misalignment when it comes to creating quality code > Take a step back, and remove estimation, give your team the time they need, focus on improvement based on iterations, and not iterations that reflect improvement.
Real Progress vs Perceived Progress
Agile methodologies aim to enhance transparency and track progress, but the constant monitoring and updating can sometimes blur the line between real and perceived progress.
Have you ever completed a task just because you have to? Have you ever wonder if what you are doing makes sense? Have you ever though about the technical debt your implementation will eventually make?
The iterative nature of Agile can lead to a focus on short-term goals at the expense of long-term quality and innovation. Teams might find themselves regularly delivering increments that appear productive in status updates but are misaligned with broader project objectives or real user needs.
Feedback on the above, STOP, raise your hand, you are the one doing the work, the heavy lifting, speak, communicate, and before even starting to code, let them know, it makes no sense, and then explain why :)
Wrapping agility
We could use a cold strait line, such as, Agile was not created by developers, or for developers. But the focus here is not who created it, but Why? What they were trying to solve back in 2001? Yes, 23 years ago …
Hmm …