How to get stakeholders addicted to attending demos

Do one of these characters sound like your business stakeholders?

Waterfall Warrior:  "I don't have time to look at mid-sprint demos, it's not like anything changes if I do."

Optimistic PO:  "I don't need to take time to look at the software mid-sprint, I already wrote down what I want."

The Waterfall Warrior is carrying the perception of non-agile projects -- all changes go through the Change Board, whose middle name is "Denial."  Attending early demos is just a waste of time, as the news (bad or good) is the same whether she hears it every week, or just once at the end of the sprint.

The Optimistic PO believes in your team's perfection -- maybe too much!  They don't yet see the problem that their original docs are full of ambiguity.  

Both of these are a contract negotiation model.  How do we get them to participate, and as the Manifesto says, favor customer collaboration over contract negotiation?

Nicotine.

Have your mid-sprint demos in a very warm room, and as they enter, secretly put a nicotine patch on them, and remove it when they leave.  Eventually, they will become trained that early demos deliver a mild euphoria.  If a few days pass with no demo, your stakeholders become anxious, and jittery.  They come to the Scrum Master and ask, "Hey, can you give me a demo?  I could really use a demo right about now."

There's one problem with this solution: it's felony assault.  A better idea is to find something more addictive, and easier to deliver. 

"Yes."

Saying "yes" to changes, with small or zero change in the cost, is like crack cocaine to stakeholders.  But how do we magically make changes cheap or free?  Timing.  Typically work that is recently created is the cheapest to change.  It has nothing built upon it, no disruption cost, and if we give preliminary demos before costly activities like final QA, less rework cost.  Try to put yourself in a situation where you're often saying, "Yes, we can change that.  No, it's not a schedule impact, I just build it this morning."

It's the role of the Scrum Master to help the team move to this "right time", but also to highlight with some fanfare what just happened.  Enthusiastic personalities might say, "Wait, say that again?  We just found a change and are going to do it, with no project impact?  That's great!"  You could say "groovy" here, but that's probably stretching the metaphor.  Regardless of your personality, it's the role of the Scrum Master to be sure that the stakeholder realizes that this is different than it has been before, and it's not just luck.  It's a result of their attendance.  Done properly, a few days later the stakeholder will come to the Scrum Master and say:

"Hey man, you got any demos?"