The manifesto quote was accurate I believe but ascribing all of the management BS and everything else to "agile" was ridiculous.
The really successful software projects I have been involved with had very reasonable requirements. In that they was not a long list of them and the core problems had plenty of time allocated.
That's the first key in my mind. Limit the scope. Overall. Another thing is to close feedback loops in terms of making sure that there are actually users using releases.
The number one biggest thing that has helped me is to avoid having places for managers or users to add an infinite list of features they want. I usually only need one or two things to work on every 3-5 days. We discuss every thing directly in text (or sometimes voice) chat based on the users testing the working application as it progresses.
I think this is also best for small teams, although recently I have done mainly solo projects.
I know one of the ideas with feature/issue trackers is that there are too many things to keep tabs on without them. But it seems like for a lot of projects, having the tracker means people fail to communicate directly when necessary, create busywork, and do not focus on priorities enough. If there is so much stuff going on that it actually can't fit in the chat room then maybe that's too much stuff.
Obviously things are going to be different for a large team handling something really extensive like Google Chrome, which is actually a full overlay operating system.
The really successful software projects I have been involved with had very reasonable requirements. In that they was not a long list of them and the core problems had plenty of time allocated.
That's the first key in my mind. Limit the scope. Overall. Another thing is to close feedback loops in terms of making sure that there are actually users using releases.
The number one biggest thing that has helped me is to avoid having places for managers or users to add an infinite list of features they want. I usually only need one or two things to work on every 3-5 days. We discuss every thing directly in text (or sometimes voice) chat based on the users testing the working application as it progresses.
I think this is also best for small teams, although recently I have done mainly solo projects.
I know one of the ideas with feature/issue trackers is that there are too many things to keep tabs on without them. But it seems like for a lot of projects, having the tracker means people fail to communicate directly when necessary, create busywork, and do not focus on priorities enough. If there is so much stuff going on that it actually can't fit in the chat room then maybe that's too much stuff.
Obviously things are going to be different for a large team handling something really extensive like Google Chrome, which is actually a full overlay operating system.