For management, it's not really about the process du jour per se. It is about standardization, frameworks, and control. Read 'Seeing like a state'
From Ruby Rogues 184 RR
"JESSICA: Alright. So, I am going to echo one of Greg’s picks because it was on my list but for a different reason. ‘Seeing like a State’ is an amazing book. And I think it’s drastically changed the way I look at software, not for the same reason as Greg talked about but because it shows why what we do is hard. ‘Seeing like a State’ talks about all the subtleties of human systems and human interactions at the local context level. It talks about all the improvisation that everyone does on a day-to-day basis and how in real human communities, we’re constantly changing the system to adjust to a slightly different reality, to corner cases we hadn’t seen before but now we have. It’s shifting and it’s not well-defined. And suddenly it makes complete sense that the hardest part of software is figuring out what we want to do. That’s it. It’s a great book."
"standardization, frameworks, and control" If management wants this than good.
In my experience its the constant change(I don't mind controlled change, but hidden change), constant scope creep, constant increasing of tasks, without increasing estimates. The constant being asked to "do things faster" without caring about quality, then being blamed about quality at a later date that makes things fail. Trying to implement every single feature, rather than focusing on a small set of useful features.
In a word its management that makes projects fail. You need a system to set constraints on managament so they have to make proper trade offs and don't expect everything in a small amount of time.
It's easy to manage if you expect everything can be done. What makes management hard is making the trade offs because you have limited resources.
If you implement a standard way of doing things, you can stop management wrecking projects.
Boss comes in and asks to change something? Well it has to go through the normal estimation process and the estimate increased etc
They can't ask you to cut corners, because it must go through the same quality procedures
etc
A lot of developers are complicit in this, because they have a super hero complex. They want to show off, and have unrealistic expectations of themselves. Management think they getting a great deal, but in the end the developer can't deliver. One of the parts of becoming a senior developer is to start to really know yourself. Then adjusting your systems to compensate.
One thing i like about SCRUM is the velocity technique, because uses past history to estimate rather than ego driven estimates.
Frameworks and standard techniques are there to protect developers much more than to protect managers.
Funny how one comment on HN can bring a relatively old and unknown book from obscurity to top spot on Amazon sales chart
(it's a sub-section but still). Of course it's just an assumption that there is a correlation between.
From Ruby Rogues 184 RR
"JESSICA: Alright. So, I am going to echo one of Greg’s picks because it was on my list but for a different reason. ‘Seeing like a State’ is an amazing book. And I think it’s drastically changed the way I look at software, not for the same reason as Greg talked about but because it shows why what we do is hard. ‘Seeing like a State’ talks about all the subtleties of human systems and human interactions at the local context level. It talks about all the improvisation that everyone does on a day-to-day basis and how in real human communities, we’re constantly changing the system to adjust to a slightly different reality, to corner cases we hadn’t seen before but now we have. It’s shifting and it’s not well-defined. And suddenly it makes complete sense that the hardest part of software is figuring out what we want to do. That’s it. It’s a great book."
http://www.amazon.com/Seeing-like-State-Certain-Condition/dp...