| They’re purposely ill defined. The outputs they seek are emergent. You also belittle scrum for becoming too specific. Seems you’re still processing what to make of any of it. Knowledge work is immaterial and should have no prescribed rails or all you get is run of the mill outputs. It’s similar to business; billions have been spent investigating what technology or management style brought the biggest gains. The math quickly becomes so Byzantine there no meaningful conclusions. No matter how detailed our consciousness will let us imagine, there’s still one reality ruled by physics. Esoteric math may be correct in that it has the order of operations right, but that truth doesn’t give it any real influence on physical reality. |
Yes they were. The cynical side of me says that this was because they were purposefully trying to create a rallying cry or something akin to a religion to better sell their wares and were unconcerned about the fallout that would ensue.
The less cynical side of me says they did it because they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed with each other on the details, but wanted some way to push people in "that sort of direction".
The net result either way was... well, a kind of religion.
>You also belittle scrum for becoming too specific.
No, I didn't belittle scrum for being specific. It's one of the good things about it. It is, however, a specifically defined bad way of running a team. We do need designed processes as specific as scrum, that are less one-size-fits-all and that have a more systematic and refined approach to software quality, estimation and design.
"Scrumban" is definitely an improvement, but even that is still lacking.
I'd like to see software team processes treated in many respects as a kind of "software to run teams", specifically meaning:
* That it gets iterated frequently and responds to feedback at every level (not just team, but philosophically - by its founders).
* That it's clearly and precisely defined.
* That there are a variety of different config switches depending on circumstances (e.g. number of people, skill distribution, are you building CRM or flying space rockets, etc.).
* That the individual pieces (e.g. retros, sprint planning) can be chopped and changed and upgraded/iterated on individually and yet still couple to each other sensibly - akin to the UNIX philosophy.
>Knowledge work is immaterial and should have no prescribed rails
No, anarchy is no good either.