20 Common Logical Fallacies – Don’t Be a Victim!

The 20 Most Common Logical Fallacies

  1. Appeal to ignorance – Thinking a claim is true (or false) because it can’t be proven true (or false).
  2. Ad hominem – Making a personal attack against the person saying the argument, rather than directly addressing the issue.
  3. Strawman fallacy – Misrepresenting or exaggerating another person’s argument to make it easier to attack.
  4. Bandwagon fallacy – Thinking an argument must be true because it’s popular.
  5. Naturalistic fallacy – Believing something is good or beneficial just because it’s natural.
  6. Cherry picking – Only choosing a few examples that support your argument, rather than looking at the full picture.
  7. False dilemma – Thinking there are only two possibilities when there may be other alternatives you haven’t considered.
  8. Begging the question – Making an argument that something is true by repeating the same thing in different words.
  9. Appeal to tradition – Believing something is right just because it’s been done around for a really long time.
  10. Appeal to emotions – Trying to persuade someone by manipulating their emotions – such as fear, anger, or ridicule – rather than making a rational case.
  11. Shifting the burden of proof – Thinking instead of proving your claim is true, the other person has to prove it’s false.
  12. Appeal to authority – Believing just because an authority or “expert” believes something than it must be true.
  13. Red herring – When you change the subject to a topic that’s easier to attack.
  14. Slippery slope – Taking an argument to an exaggerated extreme. “If we let A happen, then Z will happen.”
  15. Correlation proves causation – Believing that just because two things happen at the same time, that one must have caused the other.
  16. Anecdotal evidence – Thinking that just because something applies toyou that it must be true for most people.
  17. Equivocation – Using two different meanings of a word to prove your argument.
  18. Non sequitur – Implying a logical connection between two things that doesn’t exist. “It doesn’t follow…”
  19. Ecological fallacy – Making an assumption about a specific person based on general tendencies within a group they belong to.
  20. Fallacy fallacy – Thinking just because a claim follows a logical fallacy that it must be false.

[Read more…]

Agile antipattern: Target fixation

Have you ever been so focused on something that the rest of the world seemed to disappear for a while?  This can be great under certain circumstances, but in other cases it can be extremely harmful.  When someone focuses on a target and doesn’t see anything but the target we call it “target fixation.”  This can have dire negative effects!  For example, a fighter pilot can become so fixated on a target that they forget to avoid the target and run right into it.  The same can happen as we go through a curve in a moving vehicle.

Unfortunately, a variation of this can also occur to agile teams!  When it starts happening to agile teams it can be very difficult to detect and correct because everyone thinks they are doing the right thing.  It isn’t until much later when most teams finally determine this was the problem. [Read more…]

Agile antipattern: Sizing or estimating bug fixes

Is the bug to the left a large bug or a small bug?  It looks HUGE to me!  Well, in reality it is probably between .5 and .75 inches long.  Not really a very big bug at all.  Why do we care? Because trying to size the fixing of software “bugs” is at least as hard as figuring out how big this bug is!

When I teach an Agile or Scrum course someone will almost always ask a question like “How do you handle bug fixes in iterations or sprints?”  When I ask “How do you want to handle them?” we get into a pretty interesting discussion.  Most people say something similar to “We should prioritize them with the user stories, size them like we do user stories and then see what fits into each iteration.”  I usually smile and ask any developers if they know ahead of time how long it will take to fix a defect.  They ALWAYS say “Sometimes.”  And THAT is the problem! [Read more…]

Agile antipatterns: Agile burn-down chart roundup post

Do you want to see several different ways agile and scrum burn-down charts can lie?  If so, you are in the right place! This month I went on a burn-down chart craze and posted several blog entries about the different ways those charts can lie to us or expose us to team dysfunction.  In order, the blog entries are:

The whole series had a LOT of web hits, so clearly I’ve touched a nerve.  Good luck improving your agile or scrum metrics.  Sometime next year I’ll do a series on metrics in general.  Our current state of the art for agile teams is pretty pathetic because the data can be skewed so badly (as shown by all of these blog posts).

Until next time I’ll be Making Agile a Reality® by helping people understand the real meaning behind their agile burn down charts.

Agile antipattern: Another burndown chart that lies!

sprintburndown6That burndown chart looks sweet doesn’t it?  The team finished the iteration on time.  What could possibly be wrong.  Well, a lot actually.  Notice that one day this team completed a tremendous amount of work.  Do you ever see teams really do that?  It certainly could be a symptom of allowing large stories and they just got completed that day.  But I’m not buying it.  When I see a chart like this I immediately think the team is hiding something.  Most of the time they are hiding that they changed the scope for the iteration.  They saw their trajectory and simply said we have to remove some scope in order to have a successful iteration.  DO NOT BE TEMPTED TO DO THIS!!!  There are far better ways to fail.  If a team starts to believe this is ok then they will use it as a fallback position too often.  How do I know this is the situation?  Easy, I look at the burnUP chart.

[Read more…]

Agile antipattern: Changing the definition of done

sprintburndown5Ever see a burndown chart like the one to the left?  I’ve been on a big burndown chart kick lately and when I saw this one I just couldn’t resist using it.  This one is a bit different from my previous blog entries here and here.  This burndown chart is a release burndown rather than an iteration burndown.  It sure looks like the team was incredibly successful and finished early, right?  Wrong!  What this burndown actually shows is all of the stories being “done” and the release not actually occurring for several more iterations.  How is that possible? [Read more…]

Agile antipattern: Burndown “wall”

sprintburndown4Does your team have an iteration burndown chart (giving credit only for completed stories) look like the one to the left? If so there are a couple of possible explanations.  Last week I blogged about how this could be a symptom of working on user stories that are too large.  However, there is another possible explanation, and it is one that is FAR harder to solve.  The culprit is pushing testing to the end of the iteration.  The difference between the two is the steepness and abruptness of the wall.  When testing at the end is truly being done there are no stories finished until the last couple of days of the iteration while large stories pushes most until the last half of the iteration.  See last week’s entry on large stories to see the subtle difference in the burndown charts. [Read more…]

Agile antipattern: Burndown charts that hide the truth

sprintburndownSee that burndown chart over there to the left?  It looks beautiful doesn’t it?  It is an actual burndown chart with no made up data.  It looks like this team is kicking butt and having a great sprint.  Unfortunately, the chart lies!  It turns out this team is actually in difficulty and in fact are unlikely to make their sprint commitment.  Are you confused yet?  I know when I do this exercise during agile courses the course attendees all look at me like I’m crazy.  I assure you, I am not crazy.  This team is in trouble, it just doesn’t show up in this chart!

[Read more…]

Agile antipattern: Doing Agile!

successladderI spent the past week in Orlando, Florida  at the Agile Development Practices conference and I heard a number of people say “We do agile at our company.”  When pressed further it suddenly became “We do agile at our company except we don’t do …”  To me that sums up the problem of DOING agile versus BEING agile.  It is quite easy to DO agile.  You pick the non-threatening pieces and parts and simply do those.  Then you say you are doing agile and no one is the wiser.  Unfortunately, when pressed you have to admit to not quite doing agile very well. [Read more…]

Agile antipattern: Working overtime

working_overtimeEver feel like the guy over there to the left?  Yeah, me too.  Sorry to offend some people with my language, but working overtime really sucks.  I always felt it meant someone else’s bad planning meant I had to have a lousy day, night, weekend (maybe all 3 at once!).  For agile teams, working overtime is bad in so many ways it is hard to count them all.  This post isn’t meant to give ammunition for someone in the middle of a death march.  Once you are in a death march the organization has two choices: a) keep up the death march and pay whatever penalties come up aftward, or b) recognize the penalties may be larger than the benefit and change the objective to be reasonable.  For people on a death march, I’m sorry you are where you are right now, but this blog post won’t really help you.  This blog post is meant to help people on agile teams where overtime is starting to become more prevalent.  Those people need help – FAST! [Read more…]