Why Your Agile Project Can Not Be A Success

1. You think agile is iterative waterfall.
2. Somebody from your top management told you to use “agile” methodology on your project.
3. You think Product Backlog = project plan,iteration = milestone , scrum-master = project manager,sprint retrospective = project status meeting and agile discipline = micromanagement.
4. The sales team decreased your estimates because they believe you can work faster.
5. You use same estimation techniques for waterfall and agile project.
6. Project estimates magically match the budget.
7. You have project manager on the project who is in charge of everything.
8. Every Friday, your project team work on data collection and prepare metrics for your project managers.
9. Your team do not have scrum master.
10. Scrum Master do not participate in coding and testing.
11. Your Scrum Master do not understand the acronyms DRY, YAGNI, or KISS.
12. You had all the requirements predefined in specification document and you think project will be get executed according to specification.
13. You think design activities are ,a time to fully and accurately define designs and models in great detail and programming as a simple translation of these to code.
14. You try to plan a project in great detail from start to finish.You try to speculatively predict all the iterations and what should happen in each one.
15. Your managers swear by Microsoft project.
16. Your managers haven’t read “Peopleware” and “Mythical man Month”.
17. You do not know anything about your team’s “velocity”.
18. Your project teams don’t have burn down charts.
19. You define all the architecture upfront at the start of the project.
20. You have only one iteration.
21. You think refactoring as a rework.
22. The last book read by your senior developer is “Mastering VB 6.0”.
23. Your software architect work in silos.
24. There is no or minimal feedback and adaptation;users are not continuously engaged in evaluation and feedback.
25. You think  “Test engineers”  cannot be introduced from day one of project since no code is developed.
26. Everyday your developers work until Midnight everyday.
27. You think software quality means creating some CMM compliance documents.
28. Your QA team does not know how to code.
29. Your test engineers could not code.
30. You have specialized roles on your project teams like developers,test engineers,project managers.
31. Your developers do not practice J/N Unit.
32. You see deviations from requirements or design during later steps ,as failure or concerns in not having sufficiently skillful or through.Next time,you try harder to get it right.

If despite all these odds, if somebody is claiming that their projects are successful then I have no doubt that there are some software heroes working in their organization;who might be thinking of leaving that organization