Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them.
There is no point in delivering software which doesn't meet customer requirements. If changes to software are required because it doesn't meet requirements, pretending otherwise solves nothing. Agile processes make it easier to cope when these changes happen, and accept that if change is required then other constraints have to move – such as deadlines.
Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that?
Most tasks do not require 'longer attention spans', whatever that means. Almost literally every task can be broken into smaller parts with minimal effort, helping to expose implementations to scrutiny at earlier stages.
And while Scrum traditionally has a fixed sprint length, there's no requirement to follow that to the letter. If your constraints are such that it doesn't work, then adjust the process to suit.
But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource.
No – Scrum is about the team of individuals. Depending on a single individual is obviously stupid regardless of what process you use.
The only remotely close way of doing this is turning everyone into cogs in a machine.
Not at all true. A nice sustainable pace is reasonable for any team of skilled professionals. If you are not achieving it, your team is broken.
And takes time. Ops, sprint's time is over. I guess that refactoring can wait.
And pretending otherwise does nothing. Make refactoring a requirement for completion, and you will avoid this problem.
Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them.
There is no point in delivering software which doesn't meet customer requirements. If changes to software are required because it doesn't meet requirements, pretending otherwise solves nothing. Agile processes make it easier to cope when these changes happen, and accept that if change is required then other constraints have to move – such as deadlines.
Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that?
Most tasks do not require 'longer attention spans', whatever that means. Almost literally every task can be broken into smaller parts with minimal effort, helping to expose implementations to scrutiny at earlier stages.
And while Scrum traditionally has a fixed sprint length, there's no requirement to follow that to the letter. If your constraints are such that it doesn't work, then adjust the process to suit.
But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource.
No – Scrum is about the team of individuals. Depending on a single individual is obviously stupid regardless of what process you use.
The only remotely close way of doing this is turning everyone into cogs in a machine.
Not at all true. A nice sustainable pace is reasonable for any team of skilled professionals. If you are not achieving it, your team is broken.
And takes time. Ops, sprint's time is over. I guess that refactoring can wait.
And pretending otherwise does nothing. Make refactoring a requirement for completion, and you will avoid this problem.