Does this worldview leave room for coordination as a cooperative process? Or does coordination just mean both parties "controlling" one another? If so, what's the meaningful difference between cooperation and control?
Here are two easy examples:
1. Developing: is pair programming cooperative or a form of control? In lean terms - is one person's work a waste (they aren't generating code) and the other person's work is value (they are writing code).
2. Sprint Review: is a review that identifies friction in the protocol *by those enacting the protocol* a form of control or a form of cooperation?
I'd think pair programming is controlling the result of the work, not each other. Control in this sense not to control people, but control (setup rules, architecture guides, UX systems, direct commands) the result. Control is more about controlling outcome not controlling behavior.
We (yorba.co) are eliminating as many Taylorist management techniques as we can. Part of this effort is to accept that the original eXtreme Programming approaches (to control the result of work) were co-opted by management trying to control behavior.
So all your flowcharts can be read in the original XP context and it all looks like controlling outcomes/results. Or they can be read in the contemporary scrum context and it looks like controlling behavior. I'm not quite sure where to read the delineation in your work. That's why I was looking for a differentiation between XP-style *cooperation* at the edges vs. scrum-style *control* in the middle (management).
Does this worldview leave room for coordination as a cooperative process? Or does coordination just mean both parties "controlling" one another? If so, what's the meaningful difference between cooperation and control?
Here are two easy examples:
1. Developing: is pair programming cooperative or a form of control? In lean terms - is one person's work a waste (they aren't generating code) and the other person's work is value (they are writing code).
2. Sprint Review: is a review that identifies friction in the protocol *by those enacting the protocol* a form of control or a form of cooperation?
I'd think pair programming is controlling the result of the work, not each other. Control in this sense not to control people, but control (setup rules, architecture guides, UX systems, direct commands) the result. Control is more about controlling outcome not controlling behavior.
We (yorba.co) are eliminating as many Taylorist management techniques as we can. Part of this effort is to accept that the original eXtreme Programming approaches (to control the result of work) were co-opted by management trying to control behavior.
So all your flowcharts can be read in the original XP context and it all looks like controlling outcomes/results. Or they can be read in the contemporary scrum context and it looks like controlling behavior. I'm not quite sure where to read the delineation in your work. That's why I was looking for a differentiation between XP-style *cooperation* at the edges vs. scrum-style *control* in the middle (management).