Michael Kusters poses The Fireman's dilemma:
The hero who saved the day will make headline news. The person who did background work to prevent hundreds of fires goes unnoticed, and may even face scrutiny for that one fire which occurred despite their best efforts.
This dilemma affects the entire #Agile space: Developers, coaches - and even managers.
A coach's value is often only seen by managers and developers who have been in constant firefighting mode for years. Their feedback is often, "it's so calm ... what happened?"
Developers suddenly find themselves doing a lot less overtime and much fewer conversations with irate users - and managers suddenly realize their calendar has free spots because the constant escalations disappeared.

But environments that cherish and reward acts of heroism don't see that as an advantage. They're looking for heroic firefighters, and there's just no need for a hero when there's no princess in peril.
And they show disregard for those developers who aren't "doing whatever it takes." And they diminish the influence of managers who aren't de-escalating crisis after crisis.
Question 1: Do you see these expectations of saving the day?
Question 2: How do you address them?
I respond as follows:
Some people say "Just build it right the first time." or "Life has no "Reset" button. There are no Do-overs!"
When iteration is morally wrong, Superman is evil if he doesn't save every person, every moment, forever.
Question 1 Reply: You describe default culture. Yes, I see the FireFighters dilemma at every client and employer I encounter.
Question 2 Reply: I address it by going Meta on it. I declare the fire to permanently put it in the metaphoric Fire-Fighting Dilemma Fire. We stoke that fire with Kudos Cards Economy (a game documented by Jurgen Appelo) which moves human systems dynamics from pandemic apathy toward the mission of the enterprise, to a sub-optimization of the Now-Self-Money-Fame-Game. We starve that fire with Kudos Improvement Cards Economy (a game hinted at by Sterman & Penning's Nobody Ever Gets Credit For Fixing Problems That Never Happened ...until they actually DO!).                                  https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf

Scrum patterns can be applied to group and individual learning, to enhance and accelerate the benefits of reading a book, taking a class (in-person, on-line, instructor-led, or self-led).  In fact, the only parameter/guideline (constraint) of Scrum that it may behoove an individual learner to loosen would be minimum size of the Scrum Team.  Watching the following video (which is provided in the Japanese language only, as of this writing)  will reveal some of the reasons why I recommend applying Scrum to serious, professional learning:
Did you know that you can turn "On" subtitles, and "Auto-translate" from Japanese to English? AND you can speed up the video to 2X speed. I invite you to try it with this particular video: 
https://www.youtube.com/watch?v=EOiXdlNQMkI
I will elaborate on what Scrumming a book, or Scrumming a class looks like, in a future blog.  Please comment, or contact me if you are interested in How? or Why? I advocate working this way.

It is known that Scrum is based on Lean because the document that defines Scrum, The Scrum Guide, explicitly states, "Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials."
There may be people who disagree with what constitutes Lean, and who is a thought-leader in the realm of Lean-thinking, however, I will assert that Eliyahu Goldratt was one of them.  He was the originator of the Theory of Constraints (ToC) and the author of a dozen books related to continuous improvement in mass manufacturing.  A central metaphor to one of his books entitled, "The Goal" was Drum - Buffer - Rope, scheduling process focused on increasing flow and throughput.
The "Drum" is a symbol of steady cadence, which to a mass manufacturing line can be expressed as takt time.  "Buffer" represents an accumulation of materials, work orders, or input enabling the smooth progression of adding value through a system.  The Buffer absorbs variability inside and around the work system. "The Rope refers to the mechanism that controls the flow through the entire process." as the DevSoc article explains.
In Scrum there are 5 Scrum events which occur on steady cadence.  The Sprint is a container event with a duration of 1 month or less.  There are 3 Scrum Artifacts in Scrum.  One of them is called the Sprint Backlog which is a buffer, and the Increment is another buffer.  When a Scrum Team is practicing single-piece flow inside of their Sprint, they are essentially placing a Rope metaphor into their work system (which also contains a Definition of Done) to increase the likelihood of creating value amidst variability, uncertainty, ambiguity and complexity (VUCA).
I want to stress the fact that Sprints in Scrum are carefully design to yield value in conditions entirely distinct from those of mass-production factory floors. Scrum succeeds amidst VUCA to produce novel, completely unprecedented end-user value incrementally one or more times within a Sprint.  Unless and until all of the elements listed in the Definition of Done are rigorously and transparently verified to be completely satisfied, a separate item in the Sprint Backlog is not undertaken by anyone on the Scrum Team.
Even in the case where no such practice as single-piece flow is in effect among a Scrum Team, the Metaphor of Drum - Buffer - Rope applies to Scrum Teams.  The Buffer is again, the items which the Scrum Team pulls into their Sprint at the Sprint Planning Event.   (Ropes can only be pulled, never pushed successfully.  Goldratt stressed the indispensible characteristic of "pull systems" to ToC.)  By the Scrum Team making a voluntary and informed choice of how much work to pull into their Sprint, overburden is avoided, and risk of non-delivery drastically decreases. 
​The Sprint is a fixed (unvaried) length, the cadence of which is symbolized by the drum.  Regular, uniform cadence allows humans to instinctively anticipate when the next boot will drop, the curtain will fall, or the work will culminate into value to inspect, learn from, and improve upon in future Sprints. 
I might go so far as to say that the summation of all the Sprint Goals into the Product Goal (showcased within the Product Backlog) is a type of Goldrattian Buffer.  At the Product Owner's sole discretion and explicit designation, multiple Increments produced by the Developers of the Scrum Team in single or multiple Sprints may be accumulated into an individual release, which fits the profile of yet another Goldrattian Buffer, though it is not an endemic, parameterized constraint from the Scrum Guide.  Rather, the Product Owner adapts her plan for release to the continuously emerging realities of the market the Product serves. One could rightfully say, the release timing is variable and "Empirically optimized."
The Rope symbolizes more than pull systems alone.  It also is a mechanism that controls flow.  Each Sprint has both a Sprint Goal and at least 1 usable, shippable Increment.  The Rope ties together everyone on the Scrum Team to focus their efforts and attention on no other work that fulfilling the Sprint Goal within the cadence of the Sprint.  The Rope binds them to the Sprint Goal, as the focus of their combined work efforts.
Every Scrum Event has it's own "Time Box" which is on cadence, and each has its own clearly defined and agreed purpose, which is the Rope pulling the focus of the participants in the respective Scrum event together.  The growing, evolving, increasing artifacts and data points are the Buffer to each event, as are the various, valuable outcomes: learning, decisions, experiments, and new or modified Product Backlog Items.
Without the enabling constraints represented by Drum - Buffer - Rope, which in Scrum are the time-boxes and cadence of Scrum Events, combined with the Sprint Goal, Sprint Backlog, Definition of Done and the cross-functional consistent membership of a small, long-lived Scrum Team, waste and delay would occur in the process of creating the Increment(s) of the Sprint.
The ability to forecast and circumvent any kind of waste including overburden or delay (to say nothing of the 8 Lean Wastes) is enabled by constraints. The Focus which arises by working within the confines of the Drum - Buffer - Rope constraints is called a "Scrum Value" and there are 5 of them: Focus, Openness, Respect, Courage, and Commitment.  The Scrum Values support the people who take on themselves the enabling constraints mentioned above.
Yeah, but so what?
Applying systems thinking is critical to success of the Sprint.  Without a very firm understanding of the interrelatedness of the enabling constraints, with all of the best of intentions, someone might propose or insist on removing some of Scrum's elements.  Tampering with the system called Scrum is ill-advised.  So, Scrum Masters, trainers, and supporters of Scrum would be wise to actively share information about why Scrum works, help others see it as a stable work system too, and continue with a Beginner's Mind to inspect its operation, and uncover deeper awareness how the system dynamics impact longer-term outcomes.
Eliyahu Goldratt was a visionary thought leader who substantially informed the revolutionary thinking which Scrum is based on, and continues to elevate the human condition.  I celebrate his life along with thousands and perhaps millions of business people and new product developers world-wide.
​Thank you, Mr. Goldratt!

Anyone who has tried to scale Scrum, with DevOps practices embedded probably knows that communication across the Scrum Teams and within the Scrum Teams is key.  If you've ever used Nexus, which I highly recommend, then you already know that there are visualizations of the work which are highly effective such as the Cross Team Refinement Board.  One way for the Scrum Teams to further increase their effectiveness in building working Increments of software early and often within the Sprint is to pre-agree when there will be a release to the production environment, or a release candidate cut.  You have many choices as self-managed teams, and teams in a Nexus. 

Don Brown mentions the use of a "Release Train" approach for cutting releases on fixed intervals throughout the day.  If you have a Nexus Integration Team (NIT) you have the option of releasing at will, not necessarily at fixed intervals within a day, or a Sprint, and taking a continuous improvement approach to your DORA metric performance, your Nexus may aspire to gradually and intentionally shorting the time between releases, inspecting and adapting as you go, across several Sprints. 

​If that's the case, then drawing vertical lines with specific date/time indicated down your Cross Team Refinement Board and/or vertical lines inside the "Done" column of your Nexus Sprint Backlog for all stakeholders and Scrum Team members enables them to be aware of and discuss the implications in Nexus Daily Scrums, Daily Scrums and any other occasions.  Signaling actions in advance prevents surprises, good and bad.  Let's optimize for the whole, building trust for everyone.

Southwest Airlines had a very bad day, last year.  Maybe it's really been a bad few decades for them.  Here's 1 article in the New York Times which you might read about it if you haven't already: ​https://www.nytimes.com/2022/12/31/opinion/southwest-airlines-computers.html 
As an Agile enthusiast, the matter of software, and the distribution or concentration of decision making rights in one that is relevant to work.
I also observe self-defeating generator functions with vast numbers of human beings' behavior in the workplace.
It seems that where individual humans perish as a result of organizational dysfunction, we collectively take drastic measures. When nearly unfathomable amounts of money and livelihoods are destroyed, and oceans of customers are inconvenienced, we take no action beyond sheepish shrugs and venting perfunctory complaints.
Another great irony is that the main argument I have repeatedly been given for why dictatorships (aka. authority hierarchies) are indispensable to enterprise, is because they're so much faster in making decisions during a crisis.
I have the following to say about such claims:
1. The quality of the decisions made by a lone dictator are inferior to those made collectively by everyone effected by or involved with the matter which the decision is relevant to.
2. The speed of disseminating newly minted decisions by dictators is glacially slow in a crisis.
3. There is little or no accountability for the decisions of the dictator.
4. It is next to impossible to distinguish quality of execution on decisions from quality of decision.
5. People don't make their best efforts on carrying out others' decisions.
6. Noise overcomes signal about dictators' decisions, reliably resulting in confusion, despair, and disengagement in the crisis.
Authoritarian structure, mechanisms and policy thwarts human intentions everywhere in the human experience, long-term.

In the world, there are programmers and Agile Coaches who are morally and/or practically against all estimates given to knowledge work, especially new product development in general, and computer programming in particular.  I am not a member of the 'No Estimates' gang.
I've written down some of my thoughts, and would like to share them.

What if estimates were a prisoner's dilemma? Employers guess that they can make payroll, and programmers guess that they can make a product. Say what you want, but either way there are lots of scenarios where people go into unemployment because businesses close down for lack of revenue, and there are lots of scenarios where executives get rich from the working software made in a few Sprints by programmers who make little more than a working wage.  Sometimes the harsh realities of life are better or worse than we'd like.  People would prefer to have a feel for how likely things are going to be very sour, or very sweet in the near future, and a vague sense of what possible, probable, or certainly impossible in the distant future.  This is why many of us mere mortals make estimates of lots of things: work, funds, and head-counts.

So long as there is an abundance of resentment, distrust and indifference to the interests of any counter-parties (investor, developer or user) in this bizarre love/hate triangle, nobody can catch magic in a bottle. On the other hand,  when trust, agreement and engagement are present between all counter-parties, sometimes to everyone's delight, life is good sustainably.

Anyone is within their rights to point fingers and lay blame on managers (certainly a popular scapegoat among some Agile practitioners) and you don't need to look far for a post in LinkedIn claiming with a certainty that people who manage other people always beat them over the head with estimates, and insidiously claim that the estimates were a promise. (Pretty strong words.) Why go fixing a cynic?

"Well, that was Deming." says an Agile Coach in the room.  
​
My response to such a comment would be this:
Yes, Deming was trying to prevent management from committing business suicide, according to Deming. I don't think that Deming has said that people managers need to go away forever. I've noticed that Toyota has lots and lots of people managers, with positional authority. It's not great, but it is a long-standing fact. To my knowledge Deming's words or deeds do not suggest that people managers are unneeded or inherently evil. 

Also, Deming was ignored by his primary market: the United States. Deming and Goldratt alienated most of the mainstream in the United States corporate governance circles by being so strident and fatalistic as they were. Throughput accounting is not a commonly practiced thing in the world today. -Again I am open to thinking differently if someone wants to make that case here.

It would be folly to think that by lumping together the managers of the world, vilifying them, and claiming we pre-know they have a hidden agenda to libel workers, we'll thereby succeed in making the world substantially better.

I know a sales manager in the world, who really hates Deming, or at least hated Deming when I met the manager.  I still wonder if there was some ham-fisted application of Deming's Theory of Profound Knowledge or off-handed remark which some consultant may have used in an abusive way that was very off-putting to my sales manager friend.  Seems like a spoiled learning opportunity, to me.  Let's not throw the baby of good planning, and frequent delivery of customer value, out with the bathwater of honest mistakes, and the best of intentions run amok.   Estimates are useful when used only within the Scrum Team for Sprint Planning, and maybe used by the Product Owner for longer-term planning.  Estimates are not always a bad idea, abusive, or counter-productive.  

A friend asked me if I knew of an exercise to use in some classroom training, presumable about Agile product development.  I offered him something that I think many Scrum Masters, Agile Coaches, or Change Agents might find useful as they gently guide the learning of a given community of practice or center of excellence that they support.

This is usually played at the end of a session of Improv class, where the students make a circle, like a kind of "Dance Off" or Cage Match, and the idea is to try to take the most valuable Learning Objective which they think they've got the strongest understanding of, and then demonstrate exactly the opposite (or whatever it's definitely not), and everybody in the circle guesses what the learning is, and applauds on a loudness scale to the degree that the person demonstrating it wrong, really got it backwards...really, really, wrong.
The Trainer/Coach uses their arms like a sound meter to indicate the loudness of the crowd reaction, and can observe how well the class members collectively and individually are mastering the subject material.
As the applause grow louder the person demonstrating in the middle is doing a faux breakdance that ends with them point (sassy, spicy, 'How do you like them apples?' attitude) to the person in the circle that goes next. (Always pick the quiet/distracted one. It pulls them into the game.)
And the cycle repeats until everyone has demonstrated and got a Learning Object horribly intentionally wrong.
Here's an Example:
Let's say that one of the learnings is to "stay consistent in the character you're taking into an improv scene" and I get picked to get it wrong inside the circle, so I start talking like a certain trope (character) with a particular accent, or verbal tick, mannerisms or some kind of attitude/way of being, and I'm interacting with an invisible person, or someone off-stage, or in the circle, and then suddenly I change my attitude, all my mannerism or accent to something completely different, or the verbal tick disappears. -I totally got it wrong.

I don't SAY or DESCRIBE the learning objective and what it means to get it wrong. I actually DO a really poor job of improv, on purpose, by getting that aspect of good improv wrong (one of the Learning Objectives of the class lesson)...and I take the violation of the rule/guideline which we just learned today, and then keep messing it up, over and over while taking it to it's logical extreme, so that it's so bad that it's hilarious, and so glaringly ineffective and unworkable that everyone knows I'm couldn't possibly be getting it wrong by mistake. I'm messing it up on purpose, to show how clear I am about the principle/Learning Objective in class. You'd have to try hard to get it wrong, to the degree I'm displaying.

Make sense? Fun, right!?!

What if we defined a story point to be:

"The relative likelihood that this whole Scrum team is inadvertently, collectively under the wrong impression about what it will actually take to make the product do something that helps the user with the problem under consideration."

Things it could take which cannot be foreknown include: time, effort, policy changes to the org, political consensus, freedom to try crazy ideas, beginner's luck, unlearning biases, new tools, a no-fly-zone, a clear splash zone, 3 outages, coinciding calendars, a partridge, a pizza tree, a towel, chewing gum, foil, duct tape & 1 thin mint.

Said differently again: The less likely that the Scrum team believes they are to mis-intuit what needs to happen to deliver User Story B (relative to User Story X, which had greater Story points just before the same team pulled it into the Sprint to work on X) the LOWER the User Story point. The Scrum team is evaluating its own degree of fallibility inside the context of producing User Story B amidst current conditions and team members, everything else being equal in the enterprise. 

The Scrum team also assumes in the assessment, the enterprise will support and empower at historic levels, the Scrum team to do whatever it takes to get User Story B "Done, by the team's definition of Done."  So, as the rest of the enterprise is even more supportive and empowering of the Scrum Team, it follows that the User Story points the Scrum Team assigns to user stories decreases, on average, or they keep getting Done early and have the option to get more unplanned stories Done by the end of the Sprint, or do something even more valuable with the slack time.  Good news!

And there's catch.  Isn't there always, though?  In the spirit of increasing quality, expandable, maintainable architecture, and clean code, the team's definition of Done, grows only more stringent over time, slowly raising the bar on technical excellence and good design which the Scrum team(s) hold themselves to.  That'll really take something to achieve each Sprint, and increases User Story Points.

Now, one more wrinkle: when the rest of the enterprise is less supportive and empowering of the Scrum Team, it then follows that the User Story points which the Scrum Team assigns to user stories increases, on average to reflect impairment. If the Scrum Team neglects baking those ambient variances into their Story Point estimates,  a common pattern emerges wherein they keep not getting Done each Sprint. 

A chain is only as strong as its weakest link.  A dependency chain runs only as fast as it's slowest link.  So, either the powers that be in the enterprise respond to the Scrum Team's requests (for decisions, unrestricted access, or sensitive information) faster than the Scrum Team is moving already, or better still: authorize the Scrum Team to act on your behalf, so that you (the executive leadership) or some committee is not the bottleneck, slowing down the chain of events (dependencies) that must happen for delivery to occur within the Sprint time box.

Given this is how the whole system of Scrum in the enterprise works, one can see how self-sabotaging it would be for people outside the Scrum team to tamper with User Story Points, trying to sway them or stonewall the Scrum team from facts about the rest of the enterprise, or vice versa.  Transparency itself, in both directions informs the Scrum team which prevents false impressions, effectively LOWERING User Story points they assign to any given User Story, so MORE gets Done each Sprint.  Let's accept that even an all-knowing Scrum Team or Team of teams, still works in concert with its corporate environment.  So, how the rest of the enterprise functions or not, impacts the outcome for better or worse.

Always assume that transparency is lacking in your system until you have evidence to the contrary.  Decision latency of less than 1 day is extremely rare in multi-leveled corporate structures with many hand-offs and reporting lines.  You cannot improve what you do not measure, and it runs against human nature to complain to higher-ups about their slowness to decide, let alone publish their short-comings.  Let's exercise our personal leadership.  Leaders go first here.  Tattle on yourself, and improve.  You'll thank yourself in the future.