It sounds like agile, but really, is putting 12 bazillions features on a website a agile thing ? Agile is a company-level thing, not a development team matter.
Look at this : http://www.justin.tv/ it feels like clutter to me. I suppose that they wish that putting "features" by the dozen will help them getting more users, but I think when your users start to wonder "where do I click next ?" or "what do they want me to focus on ?" ; You are not on the good tracks.
Like soccer : stop for a second, raise your head, look around, if you run fast with your head down, you'll end in the corner.
Working with actual paying customers on another system I found they liked new features even if the new feature took an hour to develop. I believe the reason is that they felt like they were paying for something when new things were being developed often.
There were times when we didn't develop a new feature in an extended period of time (6 months) and people would just jump ship. They had more then enough features, 7 years worth of development but still if they didn't get there dose of a new feature every once and awhile they were as good as unsubscribed.
We don't share much with "agile development" except a rapid development cycle.
"Agile development" things we don't do do (from the wikipedia article):
Exhaustive unit and integration testing - our testing is sparse and only for things that need it worst
Close, daily cooperation between business people and developers - getting business people involved in day to day development is horrible, at least in our experience
Even late changes in requirements are welcomed - we don't really have "requirements"
Face-to-face conversation is the best form of communication - face to face communication is essential, but it's not the "best form of communication". It's extremely costly in comparison to email.
Although we are "agile" in the following ways, they seem so self-evident that it's difficult to think anyone would ever admit they don't follow them:
Customer satisfaction by rapid, continuous delivery of useful software - vs. slow, halting delivery of useless software?
Working software is delivered frequently (weeks rather than months) - this we do, and it's good advice. Small things we'll even do on an hourly, or minutely basis.
Working software is the principal measure of progress - broken software or nonsoftware is the measure of progress?
Projects are built around motivated individuals, who should be trusted - projects are built around commitees who can't be trusted?
Continuous attention to technical excellence and good design - no attention to technical excellence or design?
Simplicity - complexity?
Self-organizing teams - top-down organized teams? unorganized?
Regular adaptation to changing circumstances - rare adaptation to changing circumstances?
Exhaustive unit and integration testing - our testing is sparse and only for things that need it worst
Agreed, and I don't think we suffer for it.
Something we do that has a bigger bang-for-buck imho is a lot of monitoring. Just about every one of our live systems gets automatically and regularly tested to make sure it's always working. I sleep better for knowing this.
