Feature Development and Traffic Growth at Justin.tv
blog.justin.tv
blog.justin.tv
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.
See http://andrewchen.typepad.com/andrew_chens_blog/2007/11/do-y... for more in depth coverage of the same idea.
So this is a proof that agile can be applied to average products for average users.
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.
"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?
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.
That and last-minute release planning (the Product Backlog).