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 😉

Advertisements

9 thoughts on “Why Your Agile Project Can Not Be A Success

  1. Pingback: Daily News About Heroes : A few links about Heroes - Monday, 01 June 2009 01:10

  2. Kevin E. Schlabach

    I like all of these except #10.

    On a true cross-functional team, you will probably have a business analyst and/or usability person. This is especially true in a specialized domain like healthcare or banking.

    Especially in these cases the scrum master probably won’t be a developer. They are better served getting their hands dirty with the non-tech side of the work (where the bottleneck typically occurs).

    Also in large enterprise settings there is a purpose to having a dedicated scrum master to handle connecting the team (buffering) to the organization at large.

    Reply
  3. Martin Proulx

    I love your post. I would add a few more…

    – your management team believes user-stories are jokes about the end users
    – each member of the development team sits in an office or cubicle
    – team member exchange information using email and specification documents
    – the management team hired an external consultant to show the team how things should be done
    – the daily meeting lasts 2 hours
    – the management team forbids planning poker claiming it is illegal in your state

    Reply
  4. Pingback: Other interesting blog posts (June 2/2009) « Analytical Mind

  5. Pingback: Allerhand agiles und ein paar Links » MacPM.net

  6. Amit Bhatia

    While reading the post, i felt that I am reviewing my own project :). You are clever enough to understand what i’m saying 😉

    Reply
  7. Amit Bhatia

    I would like to add,
    1. Your management thinks by saying “We use Agile” is just to attract customers to show we are way forward.
    2. The developers in your organization is divided into departments as per the technologies they work in
    3. Your team lacks the “Breadth & Depth” of technology.
    4. The organization wants to please (on costs, time) the customer even at the cost of low software quality.

    Reply
  8. Pratik Patel

    Some prefer agile because there is only minimum documentation. The importance of having minimum documentation is well understood by a person who have actually gone through (or enjoyed) that phase. Apart from this, everyone’s talent in the team is well utilized and everyone in the team gets chance/time to stretch! Because all the sprints are well planned, there are no unknowns 🙂

    We are brains not body…

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s