Agile and Scrum burning me down please help me figuring out the truth

Question

hi all,

in the last while I installed MS-TFS 2008 then started to get myself prepared to use Agile Process Guidance template shipped with the TFS. with little googling I passed through Mike Cohn materials:

1. I watched his conference in youtube "sponsored by google:
   http://www.youtube.com/watch?v=fb9Rzyi8b90
   http://www.youtube.com/watch?v=jeT0pOVg0EI
2. Read his book "Agile Estimating and Planning"
3. Watching the video series in his website: http://www.mountaingoatsoftware.com/presentations-tag/video-recorded

I was very happy while absorbing and eating the techniques he is using with the teams and how agile and scrum is such a great software process/methodology until I saw Mike answering a question regarding an architect role and talking about the requirements document... at that point everything start falling apart due to the following:

1. Last year I had been assigned to make full analysis "including requirements gathering" for big project "very high priority project".
2. within 2 months of hardwork, dedication and commitment I delivered the whole analysis with full satisfaction of the customer and my BOSS and ZERO amendments.
3. Later on, the project entered the architecting, development ... phases.
4. due to the fact that the system included many competitive and exciting features I requested patenting it and its going in the process...

so imagine you are the kind of person who used to love facing all kind 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 that 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 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,

Answer 1

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.

Answer 2

As Wheaties mentioned, one strategy does not fit all situations. Agile approaches are usually well suited for products where either requirements are not known very well at the start and/or will be changing. The product is refined as the system is build iteratively and brought in-line with the customer's vision through collaboration with the customer. Now at the same time, from what I have seen, safety or something really expensive and unrecoverable e.g., a satellite, is usually not among the list of concerns for these projects.

Scrum and XP provide best practices for dealing with the management and engineering effort of being Agile respectively. You should freely adopt/modify these best practices for your circumstances but at the same time keep checking your implimentation against the spirit of Agile Manifesto.

Lastly, this interview with Linda Rising on InfoQ looks into if Agile is scientifically proven. Basically, are people in the Agile community giving themselves a "Sugar Pill"?

Interview Excerpt

Science is about experiments, about holding an idea for a short period of time and testing it and then examining the results of that test to find out whether or not the hypothesis holds up. That's really what Agile is about. Agile is about small experiments. I now believe that everything we do, not just software development, but our lives should be a series of small experiments.

We bring in every possible stakeholder, we bring in customers, we bring in users, testers work with developers. We are always examining carefully those sugar pills. Does it really work? What do you think? Are you happy with the results? That's the only thing that saves us - Agile itself. This series of small experiments.

Answer 3

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??!!!

If your PO is happy, the customers are happy, your BOSS is happy and your product is successful; then you should expect to see yourself and the team justly rewarded through increased pay and or other incentives (like vacation, stock, free lunch).

If you are looking to have Sunshine blown up you ass every day because of your "heroic" efforts that saved the day again then scrum will greatly disappoint you since agile processes by nature look to eliminate the hero position.

By the way you described your successful "2 month analysis" I would guess that your project was so well defined and or your niche so slow that you would have been successful no matter what process you used. Scrum shows its true advantage when you can't spend 2 months and come up with all the requirements and design.