Software development methodologies exist on several fault lines:
Software development isn't like most orgs, where the boss can do the job of their underling (even in most engineering disciplines this isn't true). This disrupts the normal MBA expectation of power dynamic and replaceability.
The power dynamic disruption is due to a communication barrier. It is probably mathematically impossible to encode all the issues and complexities in whatever IT system smorgasborg some IT person's day to day exists at to a box-and-arrows spreadsheet manager.
I almost suspect this is like many theory of computation proofs where complexity is either extremely high even in seemingly trivial circumstances, or exists in mathematical impossibility.
Anyway, that means the methodology exists not only at a push-and-pull fault line of power and control, it exists at a communication barrier that is fundamentally impossible to overcome.
The power dynamic disruption is such that: who manages the company, the managers, or the automated IT systems that do 90% of the management work, silently and in ways the human managers can't even fathom? Yet every modern company will only survive in the markets, even with cartel/monopoly advantages, with extensive IT systems automation. Even if they maintain position, the profit demands from shareholders will doom a management group if they can't implement IT.
But of course MBAs and management schools still don't get this. Accounting is needed by all MBAs, but IT is for "MIS people", it's for grunt work / low level MBAs.
Now add this power dynamic to heavy demand for labor, and a hatred of MBAs to pay labor good wages, possibly more than THEY make. They won't pay Developers per the real power dynamic. So:
- there's always turnover, since Devs make money by job hopping, the MBAs won't give massive amounts of money to a Dev except in rare places like Silicon Valley
- or they outsource, and there's a 12 hour delay and a language barrier on top of the normal communication barrier
So aside from the Mangement<->Labor comm barrier, there is either a System Documentation comm shortfall, so labor turnover / outsourcing destroys that, which eventually undermines productivity of a project long term, so the methodology, which is SUPPOSED to protect that long term, but has no provisions to do so, fails.
ANother dynamic is that the methodology doesn't really address disagreement. Methodologies can only address devleopment where people agree, but if there are technical, approach, economic/scope, requirements, or other differences in opinions between different groups that paralyze things, and the Management (because of the comm barrier) cannot decide or even realize they need to decide, things drag. The "methodology" fails, but software development methodologies don't have dispute resolution in them.
> Methodologies can only address devleopment where people agree
Methodologies are largely about managing, resolving, and/or moving forward in the face of disagreeement. Some may be unrealistic in how they do that (e.g., assuming consensus is always attainable).
> software development methodologies don't have dispute resolution in them.
I know of no software development methodology that does not address dispute resolution (usually, with different mechanisms for different kinds of disputes.)
Software development isn't like most orgs, where the boss can do the job of their underling (even in most engineering disciplines this isn't true). This disrupts the normal MBA expectation of power dynamic and replaceability.
The power dynamic disruption is due to a communication barrier. It is probably mathematically impossible to encode all the issues and complexities in whatever IT system smorgasborg some IT person's day to day exists at to a box-and-arrows spreadsheet manager.
I almost suspect this is like many theory of computation proofs where complexity is either extremely high even in seemingly trivial circumstances, or exists in mathematical impossibility.
Anyway, that means the methodology exists not only at a push-and-pull fault line of power and control, it exists at a communication barrier that is fundamentally impossible to overcome.
The power dynamic disruption is such that: who manages the company, the managers, or the automated IT systems that do 90% of the management work, silently and in ways the human managers can't even fathom? Yet every modern company will only survive in the markets, even with cartel/monopoly advantages, with extensive IT systems automation. Even if they maintain position, the profit demands from shareholders will doom a management group if they can't implement IT.
But of course MBAs and management schools still don't get this. Accounting is needed by all MBAs, but IT is for "MIS people", it's for grunt work / low level MBAs.
Now add this power dynamic to heavy demand for labor, and a hatred of MBAs to pay labor good wages, possibly more than THEY make. They won't pay Developers per the real power dynamic. So:
- there's always turnover, since Devs make money by job hopping, the MBAs won't give massive amounts of money to a Dev except in rare places like Silicon Valley
- or they outsource, and there's a 12 hour delay and a language barrier on top of the normal communication barrier
So aside from the Mangement<->Labor comm barrier, there is either a System Documentation comm shortfall, so labor turnover / outsourcing destroys that, which eventually undermines productivity of a project long term, so the methodology, which is SUPPOSED to protect that long term, but has no provisions to do so, fails.
ANother dynamic is that the methodology doesn't really address disagreement. Methodologies can only address devleopment where people agree, but if there are technical, approach, economic/scope, requirements, or other differences in opinions between different groups that paralyze things, and the Management (because of the comm barrier) cannot decide or even realize they need to decide, things drag. The "methodology" fails, but software development methodologies don't have dispute resolution in them.