When you lack evidence (or have too much)

I have been writing a couple of articles about presenting new ideas in workshops.

But sometimes you want to make a point, but you lack the evidence to back it up.  And sometimes you have heaps of points to make, full of evidence and highly relevant learning, but all the evidence will actually get in the way.

So let’s look at ways to present ideas, that reduce the use of evidence.  You might like some of these and not others, so read through and see what you think.

You might also notice other people using these approaches quite often when you start to listen for them.

Softening the message to support the evidence

Sometimes you want to make a point in passing but not really prove it. You want to get the point across, but you do not want to spend time discussing or exploring it.

This is where people make their claim less extreme and thus they can provide less evidence before moving on.

Consider, for example, the statement:

Agile projects do not need testers or business analysts

For a scrum master who never knew what a BA did, this could be fine.  But for a BA who is wondering if they are going to get a role on a project, this is not going to pass without considerable discussion.

Instead, weaker points would need less evidence

Some agile projects were successful last year without having a dedicated BA

Some people feel that developers can do their own analysis, creating less need for a dedicated business analyst

I think that analysis is important, but that different people can perform it in a team, so while business analysis needs to be done, it might not be done by someone with the job title of business analyst

By weakening our argument we hope to avoid having to discuss it.  People can agree that we are right, as far as what we said, but they can disagree at some point.  So they can hold off to have that discussion another time.

Replacing real evidence with assurance

Where you have credibility with the team, or you don’t really have the evidence to back up your claims, you might not benefit from providing real evidence.

You will notice people do this a lot – they provide you with assurances that something is true.  Making it harder for you to argue without making a big deal of it.  This can backfire if you annoy people, but can also get an idea out there for consideration.

Here are some examples of not providing evidence:

I can assure you that people love BA’s

Everybody knows that requirements documents are pointless

A lot of people feel that one on one interviews are time consuming

In my experience, having a BA on the team generally saves more money than you spend on his or her salary

In each case I assert that something is true – but the only evidence I provide is that someone believes the statement to be true.

Listen to people when they talk in your meetings, you might be surprised how often people use this approach.

If you are looking for potential gaps in people’s assumptions then these comments can be the ones to look into more deeply.  But there is a reason people use this approach a lot – it allows people to make a point without having to prove everything with research that is itself based on assumptions.

So this is one way of providing “evidence” when using the following framing:

Raising the counter argument before anyone else does

I like to think that I consider multiple views on a topic before pushing one view.  That is a something I like about myself.

But unfortunately it comes with a downside, I sometimes get feedback that I don’t seem committed to the view I am stating, or that people are not sure what to think.

Consider this example

Agile is a great approach.  It doesn’t always work and their are lots of zealots who push stupid ideas on everyone, but agile can work

This can leave the impression that agile is actually pretty dumb when what I wanted to say was that it is good, but I accept that there are limitations and exceptions.

The problem, apparently, is that what I say first sounds like an introduction and what I say last comes across as the conclusion.

It is similar to when someone says “I like him, but …”

What people here is the bit that came last.

A coach tried to help me by telling me not to argue both cases.  Just state one clear message and shut up.  For example

Agile is great and you should do it

That makes sense.  People can form and opinion and ask me questions or challenge me if they are not convinced.

I can also give a reason why agile is good, using our framing

We should be Agile on our projects (stated idea)

Many companies have reduced time to market and wasted effort when they used agile (evidence – maybe not definitive but still evidence)

We have been saying that we are slow to market and waste a lot of effort (relevance)

So using agile techniques will help us solve the problems we know we have (benefit or implication

That is good, I guess, but it is not always how my brain works.  Even as I talk I am often imagining that someone will raise an argument against what I am saying – or that I will soon be in an argument where people throw the word agile into every statement and start becoming zealots.

So I want to state the counter argument and present my own.

The trick though, is to state the argument you do not want to have (the expected objection) and then throw in the word but.  Then you make your own argument and that becomes the starting point for the next part of the discussion.

No approach works perfectly in all circumstances and there are a lot of zealots selling silver bullets these days BUT when applied properly, agile approaches lead to less waste and better communication

Now if someone was planning to yell out “what about the zealots – we hate them” then I have already accepted that zealots are bad.  It seems like a pointless argument.

Too much evidence

Having too much evidence does not really sound like a bad problem to have.  But in fact providing too much evidence is a common problem that really does undermine the message.

Consider the following statements

Business analysts are really important on projects

Without a BA you will find that developers will build fun code and not listen to customers

Projects with good BA’s tend to come in on time and on budget – like project Orion

Every project that saves money by dropping the BA though, has failed to go live on time – like project Nebulous

Testers are like BA’s but smarter so they can do a lot of testing and the BA work

Testers will also control your developers better, since your developers all lack accountability

If you work in IT projects then you might accept some of these arbitrary claims, but you are likely to disagree with others. And this is the problem.

If people agree with what you say, then you don’t need a lot of evidence.  So providing a lot of unneeded information can distract people or cause them to turn off.  In this case it is better to provide just one point before moving on.

If people are undecided though, you might expect that the more evidence you provide, the more convincing your argument. In fact though the opposite usually happens.

People listen to your points and then stop on the least believable point.  Then they attack that point and then they start focusing on why you are wrong.

Similarly, people who already disagree will ignore all your strong points and pick the one that, for them, is the weakest.

So when you have a lot of reasons for something, resist the urge to provide them all.

In a document you can get away with (say) three reasons.  In a conversation in a workshop it is probably better to provide only one.  Then add more if it comes up.

In conclusion

These approaches can help you in your workshops.  They often help clarify your message without absorbing a lot of time

And I can assure you that they are all easy to apply and with practice they become easy to use.

The most important part of the workshop is the facilitating of the discussion and exercises, not the presentation of your ideas. But presenting your ideas clearly and effectively helps you to focus on the facilitation and to keep people engaged.

If you are looking to improve your workshops by improving the clarity of the points you are making when you want to present ideas, the best place to start is probably to keep it simple.

Then consider more structured wording and finally consider some of the techniques above.

I hope that is helpful – good luck with your workshops.