“Sprints”: The biggest mistake of Software Engineering

<p>Yes, let’s talk a little about being agile and the Brazilian definition of the current state agile generated called “eXtreme Go Horse” methodology.</p> <h1>The misconceptions</h1> <p>The first thing is to get the common misconceptions out of the way.</p> <h1>Agile is going fast</h1> <p>By now, we all (should) know that agile is not about being faster. It’s about delivering value sooner and in a constant manner and being able to react and change course earlier.</p> <h1>Sprint is doing all in the time slot</h1> <blockquote> <p><em>So… you’re saying agile is not about being fast, but that it also means having… sprints?</em></p> </blockquote> <p>It might have been an unfortunate term used by the developers of Scrum, but it certainly doesn’t help with all the “agile is being fast” people like to think.</p> <p>Sprints, however, are just a time box for a certain amount of work to be done.</p> <h1>The problem</h1> <p>Executives push for agile and scrum because they think about being fast, sprints!</p> <p>But the biggest problem is that making software is not a sprint, it’s a marathon.</p> <p>And unless you’re not human, you know that you can’t sprint a marathon. It’s a <em>really</em> bad idea.</p> <p>Hell! Most people can’t even sprint a short race. And I’m also talking about software.</p> <h1>The people result</h1> <p>Burnout. Plain and simple, the profession loses a lot of good people because of burnout.</p> <p><a href="https://medium.com/@noriller/sprints-the-biggest-mistake-of-software-engineering-34115e7de008"><strong>Read More</strong></a></p>