Whenever we hire a new Agile practitioner, as part of the interview I ask them to discuss the Agile Manifesto [1]. And then we run through some basic program design and I ask them what tools they bring to help support various program needs. They usually bring out various ceremonies and processes and what not.

I then ask them to justify what they've offered against the Manifesto. If they're thoughtful about it (the Manifesto isn't always correct, and if you read it carefully leaves open the need for some of this stuff). If they simply insist it's correct they're cargo culting and we can move on.

What I've found is that the ceremonies are appropriately named in that many of the practitioners seem to not know what they're for or why they're done. The teams that seem to really excel are the ones that seem to have thoughtful managers that shape the practices of their dev group to the specifics of their work. The ones that seem to always be bogged down and require huge numbers of staff to get even small amounts of work done seem to be the ones that follow a checklist of getting as many of the agile practice "things" jammed into their work processes as possible.

I don't think Agile is dead, but I think it requires smarter team leads who look at what's come out of it as a set of tools to be employed against specific development challenges rather than a religion that needs worshiping.

1 - http://agilemanifesto.org/

Agile is a good case study for how good ideas get perverted quickly by consultants and companies. Object orientation also got changed from message passing to elaborate inheritance schemes. People always get confused when I tell that you can do OOP without inheritance besides a few cases.

In the software development field (and I'm sure other fields as well), we have this notion of "ownership" that means something more specific than lay people would expect. If someone "owns" a subsystem, they are not just responsible for it, they also have the authority to modify it, and they understand it well enough that they can modify it. Most often (at least in startups) the owner of a subsystem either implemented it or implemented substantial portions of it.

OK, this is on topic, I swear. This notion of ownership can apply not just just to individual contributors but scales up to teams and even larger organizations. A team can own an entire major system for example.

Software organizations of any size at all need a process in order to ship usable software. Well-run software organizations don't just have a process, they own that process as in the sense above. The organization has the responsibility for the process, they have the authority to change it, and they understand it well enough that they can. Obviously such an organization can respond to deficiencies in the process and adjust it to work better. They can even revamp it completely if they need to.

Your Agile software development process isn't going to work well if you organization doesn't fully own it.