"The manifesto for agile software development is also not agile. It would be ridiculous for a manifesto to be continually responding to change or user requests. Imagine the mess we'd have!"
We dont need to imagine, agile is creating those messes in other things, just as you feel they would with the manifesto. Why is the manifesto different to a requirements document written for a product?
The real reason why the manifesto wont change is because the author see it as a historical document, which is most likely driven by ego - not change.
Not all constraints are good constraints, some are destructive, irrelevant or enabling.
Jonathan, I'd advise you to ignore both the scrum guide and the manifesto. Clearly they are not useful for you. Find something that is useful and focus on that. That would be far more productive.
My point about your post is for discussion, I think its an important one to have. Mostly agilists have been too insular.
You know that feeling when you cant get agile principles through to people, because they have this "mental block', the modus operandi seems to get in the way. They say they understand, but don't really.
Well, I have this now but on two fronts.
1. The traditional anti-agile establishment
I am still trying - as you and agilists are to get people to adopt a more pragmatic, iterative and feedback oriented approach.
2. Agilists who don't understand that Agile is incomplete
I am trying to show agilists that the agile values are not entirely correct and that we need to expand the idea.
It is very ironic, but the agile minds of agilists are just as locked in as the "traditionalists". I cannot break into either group, as they are fixated.
I don't have an interest in "breaking in". I prefer inviting out. People are naturally creative, naturally collaborative, want to achieve, and desire both community and autonomy. We, as fellow humans—not as agilists or any other such label—need to help create environments where these needs are not oppressed. That's all. The rest will flow like magic.
I am often asked by managers, "how do I motivate my team?" My answer is always the same: "Please don't. Just stop doing those things (usually many!) that demotivate them. And watch what happens."
Hm, I suppose you could start there, but the scrum framework requires you to inspect and adapt, so your big design may be subject to change based on your learning. It is wiser to start with a rough sketch up front and let thew design emerge. As the manifesto reminds us: "The best architectures, requirements, and designs emerge from self-organizing teams."
I no longer do BDUF (my current context does not require it), but when I wrote all my spec writing and UML diagrams for entire systems, we iterated. This is a common misconception but we would design sections, review them, maybe test a prototypical example of an area we were unsure of.
We had review meetings and the design would iterate. We even did a daily standup equivalent.
My point was that the structure of Scrum is not enabling constraints directly for agility. Just because a meeting is called "retrospective" doesn't automatically enable the right sort of thinking. I have worked in scrum teams where they never grasped this concept and nothing deviated from the plan.
Scrum despite its event names and structure did not constrain the system against all other possible outcomes.
Imagine a park, where you want to prevent lay lines, you can build a guard rail so that no one can get over the fence and off the path.
The rail could be low and easily escaped, people could misunderstand the reason for it and lay lines still exist.
Since Scrum is imposing in one way, but offering very low rails, things don't always go in the direction you think. Therefore Scrum as a container is weak as I could do anything within.
I know according to scrum ideals this is not true, but it is in reality.
A butcher's knife is an enabling constraint for successful food preparation. And yet you can still kill people with one. A knife with guard rails to prevent murder would be useless.
"The manifesto for agile software development is also not agile. It would be ridiculous for a manifesto to be continually responding to change or user requests. Imagine the mess we'd have!"
We dont need to imagine, agile is creating those messes in other things, just as you feel they would with the manifesto. Why is the manifesto different to a requirements document written for a product?
The real reason why the manifesto wont change is because the author see it as a historical document, which is most likely driven by ego - not change.
Not all constraints are good constraints, some are destructive, irrelevant or enabling.
Jonathan, I'd advise you to ignore both the scrum guide and the manifesto. Clearly they are not useful for you. Find something that is useful and focus on that. That would be far more productive.
My point about your post is for discussion, I think its an important one to have. Mostly agilists have been too insular.
You know that feeling when you cant get agile principles through to people, because they have this "mental block', the modus operandi seems to get in the way. They say they understand, but don't really.
Well, I have this now but on two fronts.
1. The traditional anti-agile establishment
I am still trying - as you and agilists are to get people to adopt a more pragmatic, iterative and feedback oriented approach.
2. Agilists who don't understand that Agile is incomplete
I am trying to show agilists that the agile values are not entirely correct and that we need to expand the idea.
It is very ironic, but the agile minds of agilists are just as locked in as the "traditionalists". I cannot break into either group, as they are fixated.
I don't have an interest in "breaking in". I prefer inviting out. People are naturally creative, naturally collaborative, want to achieve, and desire both community and autonomy. We, as fellow humans—not as agilists or any other such label—need to help create environments where these needs are not oppressed. That's all. The rest will flow like magic.
I am often asked by managers, "how do I motivate my team?" My answer is always the same: "Please don't. Just stop doing those things (usually many!) that demotivate them. And watch what happens."
Scrum is not even a container for agile. You could easily do BDUF inside of the Scrum framework.
Hm, I suppose you could start there, but the scrum framework requires you to inspect and adapt, so your big design may be subject to change based on your learning. It is wiser to start with a rough sketch up front and let thew design emerge. As the manifesto reminds us: "The best architectures, requirements, and designs emerge from self-organizing teams."
I no longer do BDUF (my current context does not require it), but when I wrote all my spec writing and UML diagrams for entire systems, we iterated. This is a common misconception but we would design sections, review them, maybe test a prototypical example of an area we were unsure of.
We had review meetings and the design would iterate. We even did a daily standup equivalent.
My point was that the structure of Scrum is not enabling constraints directly for agility. Just because a meeting is called "retrospective" doesn't automatically enable the right sort of thinking. I have worked in scrum teams where they never grasped this concept and nothing deviated from the plan.
Scrum despite its event names and structure did not constrain the system against all other possible outcomes.
Imagine a park, where you want to prevent lay lines, you can build a guard rail so that no one can get over the fence and off the path.
The rail could be low and easily escaped, people could misunderstand the reason for it and lay lines still exist.
Since Scrum is imposing in one way, but offering very low rails, things don't always go in the direction you think. Therefore Scrum as a container is weak as I could do anything within.
I know according to scrum ideals this is not true, but it is in reality.
A butcher's knife is an enabling constraint for successful food preparation. And yet you can still kill people with one. A knife with guard rails to prevent murder would be useless.