3 ms·

>>> Our career is create on demand on schedule. Spot on. Lately, I've started questioning if agile development isn't the worst thing that has happened to my ov

by dev360 11y ago

>>> Our career is create on demand on schedule. Spot on. Lately, I've started questioning if agile development isn't the worst thing that has happened to my overall happiness :) Waterfall had severe drawbacks, but in any reasonably sized organizations, you'd have a lot of time on your hands in between projects, QA testing and acceptance testing. I still miss being able to hack on small stuff on work time without anybody breathing down your neck.

geebee 11y ago
I wouldn't want to go back to waterfall, but my experiences with "on demand on schedule" (a very astute phrase, that) have caused me to realize it did have advantages. Good software usually doesn't result from massive upfront requirements analysis, design, and scheduling, and the iterate and repeat approach has huge benefits (provided you've done some planning about where you're going). However, waterfall did have one big advantage, in that it forces the business side to be clear about what they want. This is an impossible and unfair task, and of course the business side will need to change, amend, modify, limit and expand scope, and so forth. The advantage is that it's unfair to everyone. I know this will sound terribly cynical (and every time I say it, someone asks, not unreasonably, "why do you even work where you work!?"), but waterfall is a contract that puts everyone in breach. The all too common corruption of agile turns into a situation where only the developer is failing to make deadlines or deliver on promises, with a daily standup reminder of this fact. I'm only partly cynical here. Software is a big, confusing, chaotic mess, and that's ok, it's the nature of the craft. However, people, especially on the outside, get frustrated. I think that the business side perceives the impossibility of truly estimating and planning software better when they try (and fail) to do waterfall. It puts them in the position of coming to the developer or technical team and saying "sorry, I know we sent you those specs, but it isn't working, we need to change our minds." With (corrupted) "agile", they are cleared of this responsibility, and they can just show up every day (or every few days), think about nothing but a very specific task, ask the dev for a time estimate, and then wonder why it hasn't gotten done (yet). When agile works well, it's when the entire team is ok with measuring progress by the value of working software, released frequently. Those have been rare occasions for me, but that has been the best experience, the happiest one, for me. Corrupted agile has been the very worst. Waterfall is somewhere in the middle.
- marktangotango 11y ago
  >> , in that it forces the business side to be clear about what they want. +1000, business analysts? I haven't seen a business analyst in 10 years.

by dev360 11y ago

geebee 11y ago

I wouldn't want to go back to waterfall, but my experiences with "on demand on schedule" (a very astute phrase, that) have caused me to realize it did have advantages. Good software usually doesn't result from massive upfront requirements analysis, design, and scheduling, and the iterate and repeat approach has huge benefits (provided you've done some planning about where you're going). However, waterfall did have one big advantage, in that it forces the business side to be clear about what they want. This is an impossible and unfair task, and of course the business side will need to change, amend, modify, limit and expand scope, and so forth. The advantage is that it's unfair to everyone. I know this will sound terribly cynical (and every time I say it, someone asks, not unreasonably, "why do you even work where you work!?"), but waterfall is a contract that puts everyone in breach. The all too common corruption of agile turns into a situation where only the developer is failing to make deadlines or deliver on promises, with a daily standup reminder of this fact. I'm only partly cynical here. Software is a big, confusing, chaotic mess, and that's ok, it's the nature of the craft. However, people, especially on the outside, get frustrated. I think that the business side perceives the impossibility of truly estimating and planning software better when they try (and fail) to do waterfall. It puts them in the position of coming to the developer or technical team and saying "sorry, I know we sent you those specs, but it isn't working, we need to change our minds." With (corrupted) "agile", they are cleared of this responsibility, and they can just show up every day (or every few days), think about nothing but a very specific task, ask the dev for a time estimate, and then wonder why it hasn't gotten done (yet). When agile works well, it's when the entire team is ok with measuring progress by the value of working software, released frequently. Those have been rare occasions for me, but that has been the best experience, the happiest one, for me. Corrupted agile has been the very worst. Waterfall is somewhere in the middle.

marktangotango 11y ago
>> , in that it forces the business side to be clear about what they want. +1000, business analysts? I haven't seen a business analyst in 10 years.