Top Reasons To Not Go Scrum/Agile

on Jun 25, 09 • by Todd Landry • with 4 Comments

There was a recent blog on the top 10 good reasons for Scrum, so in the spirit of equality, I thought I would do one on the top 10 reasons not to go Scrum. Now, before I get started, let it be known that I am a huge fan of Scrum and agile (so much ...

Home » Agile Development » Top Reasons To Not Go Scrum/Agile

There was a recent blog on the top 10 good reasons for Scrum, so in the spirit of equality, I thought I would do one on the top 10 reasons not to go Scrum. Now, before I get started, let it be known that I am a huge fan of Scrum and agile (so much in fact that I am certified as a Product Owner), but there are definitely situations where it just might not make sense to go that route.

1. Your development team is geographically dispersed. In my opinion, this is the main reason why it would not make a lot of sense to go Scrum. Scrum (and agile) are all about communication, and even though technology has made it easier to communicate across the globe, a winky-face over MSN cannot get the same message across as a face to face conversation.

2. If you are currently meeting deadlines and release dates. I’m a big believer in the adage, if it ain’t broke, don’t fix it. Why would you want to mess up something that is working for you? Short answer…you don’t…

3. You cannot get complete buy-in or 100% commitment from management, development, PM, etc. If a PM cannot actively attend meetings, or management wants to make rash decisions outside of the team, then it just will not work…don’t even bother trying.

4. If people need complete clarity about the solution before even starting the project. The very nature of agile/scrum lends itself to this just not happening.

5. You have a fixed deadline, with a fixed set of requirements. This happens all the time…perhaps you have specific functionality planned for a big event, or a big customer. If this is the case, then it might make sense to manage this using more traditional project management methods.

While the original blog that inspired this had 10 reasons, my time this iteration is up, so I will only provide 5. If you have others you’d like to share, feel free to leave a comment.

Related Posts

4 Responses to Top Reasons To Not Go Scrum/Agile

  1. I completely agree with point 3. The first question I ask when offered a Scrum contract is “What’s the management buy in?” Without it, you’re doomed either to fail, or to spend the first n days having to do a sales job.

    Oh, and if you ever find yourself having to sell Scrum / Agile, can I recommend:

    http://www.webgateinternational.com/2012/05/top-10-reasons-to-use-scrum-instead-of-waterfall/

  2. Thomas Lukasik says:

    Another very good reason for not going Agile is “Going Agile because everyone else is, and you fear that you will be seen as ‘behind the times’ if you don’t.”

    If this is your primary motivation, you’ll probably end up becoming a fan of the “We tried Agile, and it doesn’t work.” Group at Facebook.

    Thomas J. Lukasik
    Exnihilum

  3. Dave Rooney says:

    Point by point:

    1) I don’t disagree – for beginning teams, you want co-location. That said, though, it can and has been done. I coached a couple of groups at HP – one in France and the other in China, and they worked just fine. It is as good as being co-located? Certainly not. Is it better than avoiding Agile processes? Certainly, yes!

    2) Continuous improvement is the goal. There are always ways that teams can improve their flow and eventually the ROI. It’s not a case of pushing the team by creating aggressive deadlines, but rather that the team may not know that there are better ways of working. Agile/Scrum/Lean is one way of achieving that.

    3) With this point, I agree 100%.

    4) I would suggest that they aren’t getting complete clarity now – only an illusion of clarity.

    5) Agile is big on visibility and transparency. One key way of achieving these is through using a defined “done state” for features. I coach teams to use “Done, Done”, meaning that a feature is done from development’s perspective, done from QA’s perspective, and accepted by the business as meeting their need. THAT is a true measure of progress, as opposed to “feature complete” and “stabilization” phases that lead to severe crunches and incredible stress near the end of a release cycle. So, even when you have defined dates and defined requirements, it does still very much make sense to use an Agile process.

    Dave Rooney
    Mayford Technologies

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top