When I installed MS-TFS 2008, I started to get myself prepared to use the Agile Process Guidance template, that was shipped with the TFS server. With a little googling, I went through Mike Cohn materials:
I was very happy while absorbing and eating the techniques he uses with the teams and how agile and Scrum are both such a great software process/methodology, until I saw Mike answer a question regarding the architect role and talking about the requirements document... at that point everything start falling apart, due to the following:
So imagine you are the kind of person who used to love facing all kinds of challenges and returning with excellent experience and results for the stakeholders and yourself, How fairly agile and scrum processes will credit and admit your talent and passion while the scrum master/coach treat the team as one unit that accomplish user stories and converge through trial and error approach??!!!!
With those dark thoughts about agile and Scrum I found many people "anti agile" and on top of them is "Crispin Rogers Johnson":
http://agile-crispin.blogspot.com/
That guy made an anti-statement for everything Mike Cohn used to talk about.
I really don't know what to do next! So any guidance will be appreciated.
Thanks,
For every project there is a correct development strategy. If NASA used agile or scrum they would not have the 1 in 100,000 lines of code defect rates that satelite system requires. You can't release and iterate away the bugs. If you do you wind up watching your system crash into Mars.
That said, you shouldn't have to spec out in excruciating detail every nuance of a website which is related to some Hollywood mogul's dog or fansite. That's something you'd iterate and fix while the customer gave you feedback.
There is a balance to everything and every a balance. Perhaps you should read a book like, Rapid Development. While it's slightly dated so is the mythical man month but both have lasting values. What these should teach is that there is no one way to do things but many. The project should dictate your approach not some evangelical software guru.
Disclaimer: This is in no way meant to imply that non-Agile are for "real" uses while Agile should be relegated to Scruffy McPointless projects.