Keeping a Development Team motivated in a WaterScrumFall environment?

In my experience, most developers are motivated by default. If they aren't motivated there is something that de-motivates them. I firmly believe the only way to sustainably keep motivation high is tackling the issues that demotivate the team.

Bear in mind, that these may not necessarily be the same things that you and the other Scrum Masters and Coaches are tackling. It might be something unrelated to the WaterScrumFall situation, or something that can be fixed within the confinements of your current system.

But ultimately, if the root causes are in the way you work, the way you work needs to change if you want motivated teams.

I recognise that some motivation can be achieved by an energetic Scrum Master (or developer, or PO, or ...) working with the team, sharing a positive outlook on things and being optimistic and such. But this isn't sustainable. If the impediments don't move, people will become demotivated again. Also, this approach quite literally drains energy from the "cheerleader".

I'm finding it difficult to address individual Developer's questions/concerns, without saying "I understand your frustration, unfortunately this project is a WaterScrumFall project."

Maybe you should be honest with people that this is how you see it. If you pretend the situation is something other than what it is, you compromise your own integrity.

You can of course choose your words carefully, depending on the context.

It sounds like you have every intention of making things better, and you are working with seemingly smart people who recognise there are problems. Do the developers see what you are trying to do, and what do they think of that?

I've worked in multiple companies with problems; but it only became demotivating when I felt there was a culture of indifference to those problems. 

Thanks, Julian, completely agree!

Thanks, Simon, completely agree! 

I've only just started (still going through inductions!) so too early to say, but that will certainly be my approach.  Cue the courage value!

Maybe you should be honest with people that this is how you see it.

Yes, I'd say that's the key thing. Even if you can achieve nothing else, you should be able to put transparency in place which exposes the current barriers to agile practice. For example, this might involve identifying the dependencies, impediments, and other deficits for release which teams are currently facing, and which stop them from observing a release-quality Definition of Done each Sprint.

Whether improvement occurs as a result of such transparency may be a matter of organizational will and sponsorship, and hence largely beyond your control.

You are not agile is basically it.

There is no such thing as waterfallscrum

fixed expectation of the final product and performance is measured by progress towards that expectation

I could argue around how fixed is the final product... Just because now and in forseable future not much is expected to change, it could still happen that you either run into an unexpected situation, of provoke it yourself (by doing Sprint Review and showing that final expectation might require changing due to changed environment). Therefore, as mentioned already, be honest with the team, and also show that sprinting might still make sense.