Agile is a tool, not a solution. In this case, I would phrase agile as a tool which can be used to help leadership understand the company they are running. If leadership not only does not wish to understand their company, but would go further such that we can say that they wish to not understand their company, there really isn't anything that can be done from a tool perspective. This is now a 100% emotional intelligence problem. How do you teach a senior executive how to run their company? This is far beyond agile, and indeed may qualify you to run your own company (so have humility in the process... running a company like this is a heck of a challenge! If I were to work at SpaceX, I'd be hard pressed to argue against Elon Musk's approach of working people to the bone. Its how his company functions)
One approach I use is to try to analyze the problem from the senior executive's position. They are trying to navigate a business environment. These environments are often treacherous, with imperfect information. One of SCRUM's goals is transparency, but once you get up high enough, opacity is often a virtue. As a simple example, I know of very few companies that offer unlimited transparency to permit their customers to inspect their inner workings. In fact, I don't think they exist. There's always a level of opacity here, to protect business secrets, and a complicated trust relationship between customer and producer.
This relationship is probably the place to look. What does your company provide the customer, including what promises and contracts management signs, not just the final products. In long-lead-time production, these contracts themselves are often work products that are essential for making the final delivery happen. As much as I hate to say it, sometimes this is true even when the contracts are absurdly idealized. How your company goes about "correcting" their absurd promises is also a key element of this... the relationship between customer and producer is important!
Then, look at your relationship between the senior executive and the rest of the teams. Ask yourself how transparent that relationship should be. You may arrive at the conclusion that it should be transparent, which is the idealized answer. Or you may decide that this leadership is toxic enough that you actually need to insulate the work from them. I cannot recommend one way or the other, its your company with your individual people involved. But there should be some balance that you can strike.
With these in mind, you can start to formulate goals in the form "Support company product X through interacting with senior executive Y." These goals, once small enough, become product (or even sprint) goals for your agile team.
Then, use agile for what it's good for:
- If the senior executive (your "customer") changes direction often, use agile to respond to these changes.
- Use agile to protect the developers. You may not be able to protect them from the OT the senior leadership is calling for, but you can collect metrics which can be used to protect the reputation and performance reviews of the developers. (the OT may burn them out, but you can do your best to support them until then)
- Use agile to develop the people, not just the product. Jeff Southerland's TED talk explains how he uses SCRUM as a tool to develop better self-lead leaders. At the very least, when senior management's OT expectations burn the team our, they can go to their next job with a valuable skillset.
- There's an interesting balance to be struck with letting the developers bend the "just get it done as fast as possible" mindset. Giving the developers some freedom to do things differently may not quite support the "transparency" ideal with your toxic leadership, but empowered developers are more willing to work long hours than cogs in the machine. You may actually be supporting your leadership's real expectations of OT by treating your developers like human beings able to chart their own path. Teach them how to plot it within the structure leadership provides -- this is a very useful life skill.
- As an anecdote, I worked on a toxic team with bad leadership (not senior leadership, but senior enough for our small team). We chose to use SCRUM as our tool for planning, and between us and our direct leadership, we focused on transparency. We recognized the toxic environment above us, and literally treated the production as a training exercise in how to develop successfully in a real world environment (rather than the idealized utopias they teach in classess). Much of how I use SCRUM today leverages this experience, because I now have confidence that, should an environment turn toxic, the tools and planning elements I am putting in place will be sufficient to survive. (And that particular effort was so successful by management's selected metrics, that it got extended for two additional periods of performance...)
- Manage expectations and enable the team. This is the obvious stuff you already know, but I felt it was worth putting a bullet at the end, just to make sure it made the bulleted list. Use this as tools to show that your team is working as advertised. Use burndown charts with the real velocities (both actual velocity and scaled to 0% overtime). Get your team more resources. God I wish it was as easy as I make it sound when writing this bullet... but the bullet is here anyways! In other words, "go do the thing you know you were supposed to be doing." You already understand it, or you wouldn't be asking these questions on Stack Exchange.
Now I know there's a billion agile methods out there, at least one for every developer. Some use different terms. My environment uses the concepts of both stories and features. Features are specified by leadership (like your senior exec.) and they can be whatever they need in the product. The stories are developed by the team, for the team. I find this division to be very useful because it assigns responsibility for planning failures squarely in the right wheelhouse. If your team plans stories to complete a feature, and fails to complete them in a timely manner, that's on them (and you should work with your team to build up better estimation). However, if the issue is management putting unreasonable deadlines in place, that shows up in the breakout of a feature. The approach of "planning packages" from EVMS can be a useful tool here. Management may assign the size of planning packages, which can then be compared against the velocity data you have. The team has to eventually break this out, developing a set of stories to implement the feature that was planned. If they come up with a much larger number, then there's a negotiating phase where the scope may shift, and then there's a reckoning where the leadership is forced to admit that they handed a 1000 point planing package to the developers which, when realized, was 3500 points.
A particular chart I have found useful for this is a product burndown chart for the lifespan of the effort (since you have deadlines). On this chart, I draw work in planning packages in a different color from work in stories. This results in a nice visual pattern: everywhere a poorly done planning package is broken out, there's a simultaneous drop in the amount of planning-package color and a sudden jump in total scope. It is then up to you and your emotional intelligence to demonstrate to the senior leadership that all of your scope creeps happen in the feature/planning-package parts, and that your sprint planning is spot on.