you can't change priorities until the iteration is complete
The original agile manifesto was meant to avoid following plans blindly like that. It's only four lines one of which is "Responding to change over following a plan".
Despite what the kanban people think, Agile isn't supposed to be "small waterfall" where the work and priorities are set in advance instead of discovered as you test hypotheses through trying different technological approaches and doing back and forth with the users.
What you propose means that if in a cycle you discover that the plan was sub optimal and not well prioritized (and when you are iterating, you are in the best position to find that out) you march on towards the dead end and only adjust after the "sprint" is over? That is not agile, it may fall under scrum but really it is just small waterfall.
Good agile as it was originally stated is compatible with and even comes from a similar line of reasoning as the Lean approaches. The core of Lean is that the people closest to the technology should be put in a close relationship with the users to be in the best position possible to resolve what I like to call the crux of innovation. Innovation's most difficult and most crucial part which is to figure out what work has the most value to effort ratio, what has the most risk and needs to be studied early to clear up that risk and ultimately what the team should be working on first. At least for any work that is somewhat leading edge or a bit experimental, priorities cannot be properly assessed without experimentation, user feedback and management of uncertainty and risk trough early experimentation.
Scrum tends to ignore this core problem by positing a product owner that has the answers. This is very reminiscent of waterfall where people disconnected from the technology and who aren't experimenting and putting things in front of users, who are ultimately in a bad position to make plans are making those plans anyways. IMO what you are describing and a lot of the ideas in scrum are the very things that original agile was meant to prevent and also goes against Lean approaches.
Here is the agile manifesto:
"Individuals and interactions over processes and tools
Comments
The original agile manifesto was meant to avoid following plans blindly like that. It's only four lines one of which is "Responding to change over following a plan".
Despite what the kanban people think, Agile isn't supposed to be "small waterfall" where the work and priorities are set in advance instead of discovered as you test hypotheses through trying different technological approaches and doing back and forth with the users.
What you propose means that if in a cycle you discover that the plan was sub optimal and not well prioritized (and when you are iterating, you are in the best position to find that out) you march on towards the dead end and only adjust after the "sprint" is over? That is not agile, it may fall under scrum but really it is just small waterfall.
Good agile as it was originally stated is compatible with and even comes from a similar line of reasoning as the Lean approaches. The core of Lean is that the people closest to the technology should be put in a close relationship with the users to be in the best position possible to resolve what I like to call the crux of innovation. Innovation's most difficult and most crucial part which is to figure out what work has the most value to effort ratio, what has the most risk and needs to be studied early to clear up that risk and ultimately what the team should be working on first. At least for any work that is somewhat leading edge or a bit experimental, priorities cannot be properly assessed without experimentation, user feedback and management of uncertainty and risk trough early experimentation.
Scrum tends to ignore this core problem by positing a product owner that has the answers. This is very reminiscent of waterfall where people disconnected from the technology and who aren't experimenting and putting things in front of users, who are ultimately in a bad position to make plans are making those plans anyways. IMO what you are describing and a lot of the ideas in scrum are the very things that original agile was meant to prevent and also goes against Lean approaches.
Here is the agile manifesto:
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan"