|
|
|
|
|
|
by pydry
854 days ago
|
|
|
I absolutely don't think we need a single precisely defined process that will work for everyone. That's scrum and it's shit. I think we just need some criteria which can provide clear answers to whether you're doing agile or bullshitting around or doing cargo cult agile. The manifesto/principles aren't that but they should have been. Instead they were some sort of vague inspiring motivational bullshit. "Build projects around motivated individuals!". Yeah, ok whatever. No mention of the word iterate though. My proposal isn't a different mindset. I actually think I have the same one as you because when I think "agile" my interpretation centers more around short feedback cycles and iterative development. I use those words. People who have done it use those words. The manifesto doesn't. The CEOs who want to bring in "agile consultants" while still keeping quarterly milestone planning sure don't. They think it's a kind of software they install in their devs are are generally oblivious to the idea that it means they have to change too. The fact that they do needs to be brought into sharp focus. The fact that the consultants who promise them waterfall in agile clothing are bullshitting needs to be brought into sharp focus. My proposal is to codify more precisely the things which make "agile" "agile" so that it becomes at the very least harder if not impossible to bullshit about it. I'm not suggesting making it less flexible. I'm suggesting we describe what it is in a way that we can categorically rule out what it isn't. And then give it a different name, to avoid all the baggage from the old one. Some name I can point to and say "we need to be doing that" which rules out at least 95% of the bullshit artists. |
|
|
It turns out that iteration (and recursion) are pretty mind blowing concepts to have to explain to people. Like for instance just explaining why is it important to iterate faster?
I've gotten lucky explaining it once or twice, [1][2]; but mostly I think it needs to be something someone experiences somehow. Either by programming or engineering or some other way.
[1] Some engineers understand what a control loop is, and you can explain why iterating (faster) actually leads to better precision than trying to measure things precisely in one go inside the loop. ( https://en.wikipedia.org/wiki/Closed-loop_controller )
[2] You might be lucky to find a manager who really understands PDCA or OODA. https://en.wikipedia.org/wiki/PDCA , https://en.wikipedia.org/wiki/OODA_loop . Unfortunately these are also somewhat prone to cargo-culting. On the "upside", OODA cargo-culting may be subject to natural selection.