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."

http://www.amazon.com/Seeing-like-State-Certain-Condition/dp...

"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.

> Two lashes for failing to update your task in the system

my back is still hurting ( our BigCo had methodically tried to implement Scrum/Agile/Lean during 2012/13 which happened to be such a great failure. It seems that management is so shell-shocked by it that they haven't tried to push any new methodology during the whole last year. Well, and the management lost all credibility here too - any attempt at pushing any new methodology today would make everybody laughing in their face :)

>"are we going to have a demo or not?"

almost two first weeks of a sprint almost whole organization is working on a demo for the previous sprint - that was beyond insane.

> almost two first weeks of a sprint almost whole organization is working on a demo for the previous sprint - that was beyond insane.

Wow. You're right, that's beyond crazy.

What frustrates me is that demos can be very useful, if done right, but if you're doing them because "We do Scrum, here look at this certificate I got from Scrum Alliance saying that I'm a 'Certified ScrumMaster®', see?!" like the artefacts of Scrum are magical ceremonies that will cleanse you of your software sin...

For example, we create a small video demo of a feature story as part of the story development, and we make it available for our business team (who are on the opposite side of the world) immediately. This gives them a chance to flag the occasional oversight on our part sooner, and we can fix it sooner. It works really well for us in terms of ensuring quality, but also for keeping the business team aware of what we're doing.

But if it didn't, then we should iterate on our process (like bloody Scrum says to do) and stop doing them.

>For example, we create a small video demo of a feature story as part of the story development, and we make it available for our business team (who are on the opposite side of the world) immediately. This gives them a chance to flag the occasional oversight on our part sooner, and we can fix it sooner. It works really well for us in terms of ensuring quality, but also for keeping the business team aware of what we're doing.

so far there is nothing in that paragraph specific to Scrum :) Doing demo sooner in order to get feedback and chance to fix sooner is more toward Agile. Doing demo just because it is end of sprint is Scrum. Agile and Scrum are two pretty opposite things :)

Try to see things from the manager's standpoint. Without good demos it's tough to get sales. Without sales the developers don't get paid. If you're working on a large piece of software with dozens of developers split into several teams and you don't update your tasks in the project management system how do you expect anyone outside your team to know whether your tasks are complete?

Scrum daily stand-ups, which we have, and Scrums-of-Scrums which we also have.

__Individuals and Interactions__ over Processes and Tools

After we switched to TFS, our supervisor was increasingly pushing us to plan our sprints and update our burndown. This went on for a couple iterations until he realized there was no actual benefit to all that... then we switched to kanban.

I'm not saying everybody should switch to Kanban, but in our case it is just enough process to keep track of our progress while not getting in the way of getting stuff done.

You made me laugh, but it is sad that agile devolved into a micro-management tool that empowers the project management kool-aid drinkers.

I think we all need to watch this video, particularly business and project managers. I'm shocked at the complete lack of understanding of what agile is by virtually everybody working on any project these days.