All very good points. And I agree there seem to be a lot of misunderstandings even now.
How about, though:
2) Agile does have a good process for estimation. Estimating by relative size removes all those "unknowns". This does allow for a velocity that doesn't vary between iterations. I have three teams that have a velocity that on varies 10% between iterations. There is more to Agile than just Estimation. There is the commitment that a team makes to deliver. So, even if their estimates are off, the team is more likely willing to put in the extra time to meet the commitment. Remember, in Agile you commit to product, not points.
With regards to accurate: it isn't supposed to be accurate. It is supposed to be reliable.
4. With regards to documentation, no light design, etc. This stuff always seems so mis-understood. Agile says you do enough documentation/design to make it to the next game. But yes, not a silver bullet.
5. Agile requires any issues brought up by a retrospective to be placed in front of the backlog. I guess if management isn't willing to allow that, then they aren't following Agile. In the end, it is really all about execution which has nothing to do with Agile itself. Agile just affirms that you need to continually reflect and improve on the process itself. It doesn't explain how to manage that.
6. It is true this would be silly to say. And there is Behavior Driven Development (BDD) which requires you to test your system from end to end. There is also continual integration (CI) which allows "heavy tests" to be run periodically as opposed to continually during development.
Please note, I didn't make these "rules". I just follow them and it has worked really well for me.
How about, though:
2) Agile does have a good process for estimation. Estimating by relative size removes all those "unknowns". This does allow for a velocity that doesn't vary between iterations. I have three teams that have a velocity that on varies 10% between iterations. There is more to Agile than just Estimation. There is the commitment that a team makes to deliver. So, even if their estimates are off, the team is more likely willing to put in the extra time to meet the commitment. Remember, in Agile you commit to product, not points.
With regards to accurate: it isn't supposed to be accurate. It is supposed to be reliable.
4. With regards to documentation, no light design, etc. This stuff always seems so mis-understood. Agile says you do enough documentation/design to make it to the next game. But yes, not a silver bullet.
5. Agile requires any issues brought up by a retrospective to be placed in front of the backlog. I guess if management isn't willing to allow that, then they aren't following Agile. In the end, it is really all about execution which has nothing to do with Agile itself. Agile just affirms that you need to continually reflect and improve on the process itself. It doesn't explain how to manage that.
6. It is true this would be silly to say. And there is Behavior Driven Development (BDD) which requires you to test your system from end to end. There is also continual integration (CI) which allows "heavy tests" to be run periodically as opposed to continually during development.
Please note, I didn't make these "rules". I just follow them and it has worked really well for me.