> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. It depends. Wit

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. It depends. With certain projects, the overriding risk is that you're building something that nobody wants. In this case, Agile makes a lot of sense, and specifications are a waste of time until you've validated customer demand. For other projects, you're very confident that demand exists for the product you're building, and specifications start to make a lot of sense. Big caveat though - you can get this assessment very very wrong. "Demand" can be a very open-ended concept (e.g. in the entertainment industry), but that doesn't necessarily translate to user satisfaction. No Man's Sky, for example, probably should have been put in front of players a lot earlier. That means building to a looser spec in shorter cycles with more iteration (more "Agile", for want of a better term). This is why product managers are so important - they need to make this judgment. It's a difficult balancing act to juggle "minimum features and user testing", "grand product vision" and "efficient and manageable development cycles".