To Agile or Not Agile

I think a buzzword of software development of the last decade (and still ongoing) is Agile. Those who embrace Agile see waterwall as evil or outdated dinosaurs.

Ok, is Agile really all good and is Waterwall all evil?

If you have a bunch of bad programmers does it matter what development scheme you use?

Here are some classic elements of Agile: the daily stand-up meeting, user stories, pair programming, and iterations

Daily stand-up. It is nice to have, so you know what your teammates are doing and obstacles. But I don't like military style call: "let's stand up!" and do a for-loop around your team. A daily status email (or post to a team blog or something) will do just fine. If your teammates are actually a team they will communicate to each other without forcing a daily meeting. Instead of daily meeting, I think a weekly meeting and daily email will suffice.

Some people naively think everything can be broken up to stories easily.
Let's say you build a car. A story may be "driver starts the car". Come on, you need an entire car built before you can actually start it right? do a non-functional starter faking you turn the key is a waste of time.
More realistic is to break up your car into little units and talk about those instead.

Pair Programming: work best if you have at least one good programmer, meaningless to team up one blind person leading another blind?
I rather have 2 person assigned same task to finish it however they choose (not 2 guys looking at screen at the same time)

Iterations: at least two week each is reasonable length. There is not a whole lot of meaningful features can be done in a week.

Iteration meetings (with your client). Do you think your client have patience to talk to you EVERY iteration (week or two weeks)? Nobody has time to look at useless incomplete things. This is why your clients prefer waterwall.

Here is how I think things should be done, call it common-sense manifesto.
1) Manage expectations. Simple rule: Don't promise things you can't deliver.
2) Get good people. Only good programmers can give you code. Not your PM or your graphic designer or the cleaning ladies.
3) Have a good idea of your whole thing FIRST. Deliver chunks of it at a time.

Don't tell your developers that your client don't know what they want in the middle of iterations. HELP your client understand by giving them clickable things, come on, HTML is not hard to build, don't give them pictures and require their imaginations.

Dangerous elements of a team
1) PM who don't have a clue what it takes to get things done
2) Graphic designers who only know how to draw pictures and don't even know what HTML can do. Real life example: One guy says making a dropdown box (a <SELECT> tag editable to add items to it on the fly!
3) Requirement not gathered. Real life example: so you want a dropdown box here and you don't know the values for the dropdown? Sure I can put value1 value2 temporary, but why make me re-work

Real life experience: project start as agile and then go back to waterfall. (and I don't blame them). People just want things done, not follow your favorite manifesto.

So, the merit of Agile is... agile. It is easier to change things that way and it encourages team work. Downside is endless iterations and too many re-work and too many unforeseeable things if not done right.