CS Blog

CS-348 Quarter 4 | Sprint and Dogma

Bruno Noriller's “Sprints”: The biggest mistake of Software Engineering shows the negative consequences of improper use of AGILE/SCRUM-style development. Sprints are defined by the article as "time box[es] for a certain amount of work to be done", which they are. Then Noriller states that software development is a marathon, not a sprint, which is indeed the case. Though this is shrouded in a veil of adding features corporate dumped on you real quick. It can be the case in some workplaces but that shouldn't be the case. The SCRUM team decides their end goal and if they took on too many tasks, they can always renegotiate the content required to end a sprint.

Agile development, including SCRUM, is a framework designed to make software development more adaptable, iterative, and value-focused. However, it is not an end-all, be-all solution. While Agile emphasizes flexibility, frequent delivery, and continuous feedback, its effectiveness depends entirely on how it is implemented. Treating every sprint as a hard deadline will inevitably cause burnout and result in worse quality increments towards the end product.

Burnout is a real risk when teams feel pressured to finish too much work in a single sprint. One way to avoid that is to focus on a sustainable pace and give teams control over their workload. That means negotiating what gets done in a sprint, leaving time for proper testing and clean code, and not treating every iteration as a race to add more features. Sprint retrospective seemed to be neglected or nonexistent in the development strategy the author illustrated. If one sprint was crunched up, the retrospective should have that dealt with so such errors don't happen in the next cycle.

Joe Elwell commented on Noriller’s article with a perspective that got me to write this. He calls out how Agile and SCRUM can be misused when treated like a checklist or a bunch of mandatory meetings. That kind of rigidity ends up being demeaning to developers and counterproductive. Too many stand-ups, strict story-point tracking, or unbendable sprint goals can break focus, mess with workflow, and actually hurt the collaboration Agile is supposed to encourage. His point is clear: Agile is a mindset, not dogma. Teams should adapt practices to what works for them instead of blindly following frameworks.

The big takeaway from both Noriller and Elwell is that Agile works best when it respects people and technical limits. Sprints are planning tools, not hard deadlines. Agile should help teams deliver value in a sustainable way, not force them into an artificial pace. If organizations understand that, they can keep output high while keeping developers sane. Thoughtful workload management, adaptive planning, and retrospectives let teams get the benefits of iterative development without the burnout or sloppy code that comes from pushing too hard.

Noriller is right to warn against treating sprints like a pressure cooker for cramming in features, but the problem isn’t Agile or SCRUM itself. Proper use of Agile gives structure, predictability, and adaptability, all while respecting that software development is long-term work. Flexibility, team autonomy, and a sustainable pace came free with the SCRUM.

The article also dumped the eXtreme "Go Horse" (XGH) manifesto at the end and honestly I do that all the time for my personal projects. Don't wish it upon any teams though that sounds hellish.