3 ms·

Agile itself is pretty bad too. “Responding to change over sticking to the plan” is pretty much the single biggest reason why I see projects fail.

by mlthoughts2018 7y ago

jrochkind1 7y ago
I think the key motivation of agile is the recognition that the plan made in advance is often not right. If completing "the plan" is seen as success, then of course sticking to the plan is the best way to success. But if maximizing business/user value is the success, then "no plan survives first contact with the enemy." (I don't like "the enemy" concept, but this is a famous quote that gets across the concept). And I think the reason why "agile" fails is because many actors in many organizations find they are effectively rewarded for "completing the plan" regardless of business/user value, indeed.
- mlthoughts2018 7y ago
  This is just not accurate. The types of changes thrown in after early requirements gathering are most often coming from product managers and executives, not from customers and not driven by genuine feedback or budget constraints, etc. “Sticking to the plan” does not mean rigidly enforcing zero changes, but rather means keeping a commitment to the general scope and direction that was mapped out. Compromises should require extraordinary hard evidence before being accepted. This is really why Agile as a general set of guidelines is so easy to subvert and ends up being a misused tool in most every situation where Agile is deployed (Scrum of otherwise). Project management guidelines need to start out by specifying a way that quality is strictly disallowed from being subverted by competing interests that lobby for changing the plan. If a set of software project management guidelines doesn’t start out with an unchallengeable quality-above-all-else mandate that creates policy barriers to the natural entropy of different interests trying to lobby for why their preferred change has to be made, then it’s doomed to just get politically subverted. Doesn’t matter if it’s Agile, Waterfall, extreme programming, whatever. “Sticking to the plan” in the sense of setting up preemptive, high-cost barriers to anti-quality modifications to what was agreed is _the_ thing.
dragonsky67 7y ago
The problem is that if the environment or requirements have changed and you don't take account of that then you may have a successful project delivering a product that is no longer relevant.
- mlthoughts2018 7y ago
  This is the overblown excuse people use to argue for their preferred changes, when really the environment or requirements usually don’t change, and when they really do then either it’s small and you should still stick to the plan or else it’s big and the need for change is so overwhelmingly self-evident that you don’t need things like Agile slogans to generate motivation or buy-in to change things. Either way, harping on the idea of “but what if circumstances changed” is mostly just what corporate politicians do to subvert people demanding evidence for the requirement of changes.

Agile itself is pretty bad too. “Responding to change over sticking to the plan” is pretty much the single biggest reason why I see projects fail.

jrochkind1 7y ago

I think the key motivation of agile is the recognition that the plan made in advance is often not right. If completing "the plan" is seen as success, then of course sticking to the plan is the best way to success. But if maximizing business/user value is the success, then "no plan survives first contact with the enemy." (I don't like "the enemy" concept, but this is a famous quote that gets across the concept). And I think the reason why "agile" fails is because many actors in many organizations find they are effectively rewarded for "completing the plan" regardless of business/user value, indeed.

mlthoughts2018 7y ago
This is just not accurate. The types of changes thrown in after early requirements gathering are most often coming from product managers and executives, not from customers and not driven by genuine feedback or budget constraints, etc. “Sticking to the plan” does not mean rigidly enforcing zero changes, but rather means keeping a commitment to the general scope and direction that was mapped out. Compromises should require extraordinary hard evidence before being accepted. This is really why Agile as a general set of guidelines is so easy to subvert and ends up being a misused tool in most every situation where Agile is deployed (Scrum of otherwise). Project management guidelines need to start out by specifying a way that quality is strictly disallowed from being subverted by competing interests that lobby for changing the plan. If a set of software project management guidelines doesn’t start out with an unchallengeable quality-above-all-else mandate that creates policy barriers to the natural entropy of different interests trying to lobby for why their preferred change has to be made, then it’s doomed to just get politically subverted. Doesn’t matter if it’s Agile, Waterfall, extreme programming, whatever. “Sticking to the plan” in the sense of setting up preemptive, high-cost barriers to anti-quality modifications to what was agreed is _the_ thing.

dragonsky67 7y ago

The problem is that if the environment or requirements have changed and you don't take account of that then you may have a successful project delivering a product that is no longer relevant.

mlthoughts2018 7y ago
This is the overblown excuse people use to argue for their preferred changes, when really the environment or requirements usually don’t change, and when they really do then either it’s small and you should still stick to the plan or else it’s big and the need for change is so overwhelmingly self-evident that you don’t need things like Agile slogans to generate motivation or buy-in to change things. Either way, harping on the idea of “but what if circumstances changed” is mostly just what corporate politicians do to subvert people demanding evidence for the requirement of changes.