Back in the 1980’s, IT work was mostly construction work. Roll in the machines, run the wires, install the terminals, turn stuff on. Because of that, the practice of managing software development in those same departments ended up using construction project management.
Big plans were made up front, schedules created, work broken down and estimated, budgets figured out, and everything tracked and reported.
The people managing the construction of what we would now call a data center were not aware of what they were doing when they adopted construction practices into a form of knowledge work.
Change requests on projects are intended to be rejected almost all the time to protect the plan. Because a building is extremely expensive to reverse, the repeatability is so high, and the cost of change increases as construction proceeds, changes must be prevented. Software development efforts, which involved constant change, mis-use change requests as a way of tracking changes and recording agreement.
It works, but it is expensive, slow, and vulnerable to disruption by competitors using more flexible approaches.
By the time development experts were rolling out iterative, incremental ways of working to handle the uncertainty of software development, it was too late. The software world believed that project management was just how it should be done. It became a cultural belief – almost like a religion.
Today, it’s not enough to explain that something would work better, or that there is a framework you can try designed to handle the uncertainty of software. It is also necessary to battle uphill against strong, deeply held beliefs that are tied to identity about planning and management of people and work. To suggest overhauling how work is performed is akin to telling everyone that they are guilty of years and years of mismanagement. The push back isn’t illogical – it is a battle to protect personal legacy.
This causes another problem: The new frameworks are vulnerable to subversion. When an organization that would be severely changed by the framework is forced to use one, they bend and change the framework to fit the current paradigm. The framework, which was intended to bring change and if used properly bring improved delivery is rendered an empty shell that does not provide results. Because no one ever measured anything before or after adoption, no one can see the depth of this mistake. That’s how we ended up with Zombie Scrum.
What now? What is the goal you need to achieve? Are you measuring if you are accomplishing it? Make some changes. Do the measurements hold, improve, or deteriorate? What next?
Using an empirical approach today is necessary because of the many ridiculous claims, too much enmeshment with identity and legacy, and too much corruption of the goals and outcomes of the new frameworks. Too much money and time has been wasted resisting ideas without fully attempting them or making changes and imagining improvement without actually getting it.
It’s not dead. It’s just a lot more difficult than people thought it would be, and it will take a lot longer and lot more work than anyone wanted.
