Quick Thought: What To Do When One Person Says There's Value and Another Says There Isn't

January 23, 2013 — Posted by Al Shalloway

This blog in 2 sentences: You can't disprove an hypothesis with another hypothesis - you must provide evidence.  Unless you are a taxi driver, a bartender or a barber, you don't have a right to an opinion about a process you've not used (the three aforementioned folks are entitled to opinions about everything).

I have been using leading edge Lean-Agile methods (they were at the time anyway) for 14+ years: XP, Scrum, Lean, Lean-Agile, Kanban, ATDD, TDD, emergent design, ...

Throughout this time I have heard "that'll never work" often enough.  The irony is that 10+ years ago I heard this from people holding on to Waterfall, now I hear it mostly from Agilists.

Given that I am a firm believer in challenging one's thinking and given that I often make posts that talk about relationships between different activities that others deny or how to do something that others suggest are ineffective or even dangerous, it occurred to me that both my statements of being able to do something should be just as challenged as I do of my detractors when they say "it isn't possible to do what I claim".  However, it always felt like the challenge to these two statements would have to be different.  In other words, you can't just argue that you are right - you must provide different evidence. I thought about that a little this morning and here's what I think is useful challenges to present when one side says "this is useful" and another says "no it isn't."

When you claim something isn't useful, you are likely claiming one of two things:

  1. it doesn't have the effect you are suggesting
  2. it has a dangerous side effect which you are ignoring

Supporting information for either of these is useful.  However, as a person who believes in the scientific method, it is not sufficient to defeat an hypothesis with another hypothesis - one must actually try it and come up with conflicting data. 

Thus, instead of just saying why something doesn't work, one needs to provide a case where it didn't work for them.  Now the other person can:

  1. accept the new evidence as refuting their hypothesis
  2. accept the evidence and modify one's hypothesis to account for it
  3. assert that two different experiments were run (i.e., the past experience of both that they are referring to are different cases) and suggest it does not refute their hypothesis

On the other hand, when you claim that something is useful you need to provide the value you got from doing so. And you need to demonstrate that it is not a one-off occurrence.  And if one is given a counter-example, then one must do what I suggested above.

Summary

I believe in listening to conjectures from people that disagree with mine.  However, except for taxi drivers, barbers and bartenders, one is only entitled to an opinion if they expertise (i.e., knowledge and experience) in the subject.  People who conjecture about things they have no experience of should be ignored, in my opinion.  Not because they disagree with me, but because of the lack of real evidence to support any conjectures.  Many of my biggest breakthroughs have been from folks who said to do certain things that I thought were crazy - and certainly ineffective.  But the people saying them (e.g., Bob Martin, Martin Fowler, Christopher Alexander, Kent Beck, Ron Jeffries, Ward Cunningham, Rebecca Wirfs-Brock, the Gang of Four, ...) had experience (or smarts) in the area that I didn't have.  So I tried what they said - fully expecting to be proven right.  In virtually all cases, however, I wasn't - but I learned something - so that was better.

Al Shalloway
CEO, Net Objectives

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban