In our case we used a both/and approach a requirements document (a guideline if you will), but we took it further with the SCRUM approach. Yes, I agree with you it is what works best for your organization.

peterchen wrote:

I disagreee. And the mantra of scrum seems to be keep the developers happy. [Big Grin]

The reason I made the previous comment is that I find it gives flexibility on both ends, not just the developer. The customer isn't chained to what they thought they meant when they said X,Y,Z in the requirements document in previous months. That is why it makes our customer happy. :)

You still have a requirements document. Some basic truths are still truths. The statement above is true. The requirement document can be viewed as the gospel, so to speak, or a guideline. I never liked the idea of a requirements document being used as something set in stone, because as we all know the customer typically knows what he/she wants, but he/she doesn't "KNOW" what he wants. Hence some truths are still truths. With that being said I have seen quicker turn around with SCRUM then a requirements document, but there again that is just my personal experience, and if people have more success using a requirement document to manage their projects more power to them. In the end, if mama (the customer) is happy than everybody is typically happier.

Traditional Requirement Documents are great, but I have found greater success in the SCRUM methodology. You could spend weeks to even months getting wrapped around requirement documents before any development actually happens. Sure there are some that may be skeptical with SCRUM for various reasons. Some people may like to deal with evolving requirement documents, but I personally don't. :) Any developer knows that the customer can always change their mind in the next release, and typically that is what happens. http://en.wikipedia.org/wiki/Scrum_(development)[^]