I'm intrigued by this!!!!!

/rant

This is very similar to our methodology at Super-Ego Games. We divide the work into iterations, which are then split into stories (high-level tasks like "add Vin Turbo Trivia into the game"). These are split into tasks against which hours are logged. Each iteration is 4 weeks, after which the department heads have a long boring meeting to close all open issues, etc. Then we do it all again.

This causes our work to come in waves. We have mini crunch times towards the end of particularly brutal iterations (like this last one), then the work lightens a bit. This helps keep everyone more or less sane.

On the flip side, once an iteration is over, we tend to forget about it. This leaves little remnant tasks that often don't get done until someone plays the game an says "hey, why isn't the Vin Turbo Trivia quiz working?"

(can you tell which task is giving me grief right now? )

-Rez

I like Agile, very much though I haven't been able to use it much beyond XP for One. XP for One is using units and test first development, no pair programming. I haven't many managers yet that believe in it. If any of you are managers that do think me when you need extra help

The hardest part for me in getting into it was learning to write unit tests before coding the routines and modules to tested. I confess that writing good tests that really test
input parameter boundries well is and likely will always give me trouble. Test first has helped me to become better I think because i changed my thought process from:

This is what i have to do, this how i plan to do it. Later in the debugger How did I screw this up?

Now my thought process is:

This what i have to do, this how i plan to do it. Write the tests (this is how i'll screw it up mostly likely)

Just adding extra step has helped clean up a lot of my sloppy mistakes (passing a NULL, loop indexes off by 1 etc)

I really should read more about Agile Development before I jump in, but here goes my uninformed opinion:

I totally buy into what Agile tries to accomplish in that you get very polished features with tangible results every 30 days or so, but the part that seems to be missing is the big picture. On that, I probably just don't know enough about Agile Development, but it seems as if Agile makes an assumption of a seemingly infinite (or drastically flexible) development budget as opposed to a development budget that is supposed to last for a specific amount of time.

I understand that Agile development is not cowboy programming, but I see no aspect of the Agile process to guarantee that you will have a ready-to-ship product in X number of months.

At the risk of sounding like a stuffy shirt inflexible plan-monger, this Agile Development manifesto scares me:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
  
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
  
• Responding to change over following a plan

It scares me because I've always valued documentation, plans, processes, and tools over the will power of the error-prone human being who may or may not be lazy. This agile development process feels like operating in the dark with a very weak flashlight... and you've only got twenty minutes to find new batteries before the light goes out forever.

But like I said, I don't know enough about this process. I need to read up on this. This may just require a leap of faith into something that might look like sharp, pointy spikes on the outside, but once you dive in, everything becomes soft, fragrant roses.

yeah, roses.

I'd love for somebody to counter the point about hitting the scheduled ship date, but if not, then I'll read up on this and come back to this thread to counter myself, if I can.

I've come to the conclusion that Agile Development is an extreme that places the burden of scheduling away from the producer onto the trenches, which has the potential weakness of missing out on the big picture when you only have a finite development period.

In contrast, the waterfall method is the opposite extreme that places the burden of scheduling away from the trenches onto the producer, which has the potential weakness of an underscoped product that doesn't quite reach its potential.

Either weakness can be thwarted if there is enough producer in each trench worker or enough trench worker in the producer. In the end, I feel that going to either extreme is bad. A hybrid system that takes advantage of the two would be ideal, in my mind. Whatever the case, if any trench worker feels like they don't have any producer in them, well... they really oughta arrange to get some in them as soon as possible.

"No plan survives contact with the enemy."
-Sun Tsu

Just remember.... moderation in all things. One extreme or the other is typically bad.

-Rez