> if you have a great team, it will organize itself anyway. If you have a bad team, jumping on the agile bandwagon won't help you
I agree, however most teams fall somewhere between great and bad. Also, there may be many different stake holders and changing requirements in a project. In these circumstances some discipline is needed to ensure that developer hours are used wisely. The options here are:
1. No process. Rely on the team to self-organize.
2. A waterfall like process (All planning up front, long term development goals
3. An agile like process (Short term development benchmarks, daily stand ups, constant re-evaluation of goals)
Of the three, the first works well for a very small team, or a truly excellent teams. A bad team is going to fail no matter which is chosen. But, for teams in between, or for projects where there is confusion about requirements, I'd argue that option three is clearly the best of the bunch.
I agree, however most teams fall somewhere between great and bad. Also, there may be many different stake holders and changing requirements in a project. In these circumstances some discipline is needed to ensure that developer hours are used wisely. The options here are:
1. No process. Rely on the team to self-organize.
2. A waterfall like process (All planning up front, long term development goals
3. An agile like process (Short term development benchmarks, daily stand ups, constant re-evaluation of goals)
Of the three, the first works well for a very small team, or a truly excellent teams. A bad team is going to fail no matter which is chosen. But, for teams in between, or for projects where there is confusion about requirements, I'd argue that option three is clearly the best of the bunch.