> Sprints are nonsense unless they have gaps bewtween them, noone can sprint indefinitely
This is the crux of the nonsense. A high-level engineer can work around this but for the mass of ticket punchers, it just encourages non-thinking, risk aversion, and a lack of trust between themselves do the pressure of velocity charts, which translates into buggy code, mounting legacy blockers.
I know frontend engineers who didn't know what a finite state machine was, nevermind how it was implicit in their business code. For the mass of mediocre engineeers, sprints kill incentive to learn and become a better engineer; no is rewarding you.
Product doesn't care cause they're incentive structure is advesarial to Engineering push-back on tech debt, refactoring, etc. Sprints allow them to make sure their bonus is on time. Then Product people quit when BS mounts, another round of Product management shows up, and rinse, repeat.
I've seen this cycle happen three times in one org in just 5 years, the org where I started as a Junior.
And don't let DevOps also be working against sprints in a mediocre org
Sprints have, for most of the industry, not the Top 10% employers and what not, frankly regressed the industry.
Everyone stops working for the organization and starts trying to figure out how to make the organization work for them, from engineering to product to devops, etc. Good hiring is also a factor in what you'll get out of your employers, but sprints don't get you more at either rate.
'Sprint' does not mean you have to push yourself to code as fast as you can, nor does it mean that you have to start coding straight away. In fact part of the work may not involve coding at all (e.g. studies and architecture work) and these activities can also be part of a sprint.
Sprints are just time-bounded units to plan and execute the work with the stated aim of having working software at the end of each sprint. You can do that indefinitely in the same way you can follow another software development methodology indefinitely.
> 'Sprint' does not mean you have to push yourself to code as fast as you can, nor does it mean that you have to start coding straight away. In fact part of the work may not involve coding at all (e.g. studies and architecture work) and these activities can also be part of a sprint.
I agree with this statement. However, I believe the term is poorly chosen and, in my experience with managers, frequently misunderstood.
There are two issues I have with the term. First, sprints, as a physical activity, are about short, very hard, bursts of work which are fundamentally unsustainable. Even an athlete competing in sprints takes a good break between each one. Second, "sprint" conveys a sense that the focus is on speed because that's how we judge sprinters.
The first point suggests that Scrum needs a different kind of interval than just a sprint. It needs something like a rest period. Not a "sit down and do nothing" period, but analogous to the "active recovery" that athletes often take part in between exertions. Something productive, supportive, but secondary to the principle objective (a runner isn't at the race to stretch, but they stretch so they can continue to race).
That second point is important, managers hear sprint and they think speed. Any kind of slow down or delay makes them think that the team is just dicking around. The idea that a sprint could be spent on anything bringing indirect value (rather than direct) like test and deployment automation, refactoring and cleanup, or training is antithetical to this perception. Consequently you cannot, easily, put those activities into sprints, or you have to disguise them or mete them out over a series of sprints so that enough "real" value is being created from the management perspective.
Finally, "agile" is about responsiveness. The term was chosen for the manifesto deliberately. We don't look at Usain Bolt on race day and say, "Wow, that man is agile". But you would talk about the agility of a football player who loses speed dodging, avoiding, and leaping around a field to get a 100 yard touchdown. The agile player is responsive to opposition and present conditions. They do need to be fast, but their ultimate speed isn't just from raw speed but from their ability to maintain progress despite adverse conditions. A faster but less agile player could get lucky, but more often will get blocked. The use of the term "sprint" in Scrum conveys no real sense that adaptation and responsiveness are important.
In my experience sprints just represent artificial constructs that in the long run serve no real purpose. We end up saying strange things like "I won't be finished with X until next sprint", or "we took in 15 points this sprint". I've seen people become more interested in what I call "Jira ticket engineering" than the actual work.
In my experience sprints just represent artificial constructs that in the long run serve no real purpose
This is exactly what I meant by calling them nonsense. Calling them rounds or periods would have made much more sense. Especially since a coding sprint was already a thing, and meant lets ignore everything else and just write code for a few days.
I've seen people become more interested in what I call "Jira ticket engineering" than the actual work.
We use Rally, but I have seen the same thing. There is hope among some that switching to Jira will solve that problem.
Standups are good for small teams all working on the same thing, and only if no managers are present. Unless the manager is writing code too .
Kanban seems ok but i havent used it for any period of time.
The various tools are nice for remembering what needs to be done and making shared checklists.