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.

Ever lost your glasses only to be told they are someplace on your body obscured from your view?
(Like on top of your head?)
It happens.  People see things that are right up in their face.  And that's about it.  So, to make it easier to catch people's eye, we put books there, project slides there, and wave funny flags there.  Personal perspective, bias, and expectations make some things invisible to the active viewer and that's what is mean by "blind spots."
The worst part about blind spots is that we all have them.  Building trust in an organization is important because when it's coming from someone we know we can trust, instead of brushing away well-intentioned feedback, sometimes we can just look: the paper stuck to the heel of your shoe.  You know that don't want it there, but only when you're aware of it.  A friend who notices something because they're seeing you from a different perspective than you, can tell you about it.
"Thanks friend!  -You've got my back."
"And I've got yours.  -A friend in need..."
So, working together we can more quickly find errors, oversights, and omissions.  We fill in the gaps we missed, and none of us makes a fuss or keeps score all the time.  Trusting each other to tell when it really counts makes all the difference in both work effectiveness and efficiency.

Ever notice with the passage of time that great technological advances keep happening at an ever increasing pace?  Yet, people seem less and less satisfied with the quality of life they experience pervasively?  Subjectivity certainly enters the picture, yes.  But, what's going to make the difference for your customers, employees, strategic partners, and the organization as a whole?  All said, what supports the whole ecosystem of work in your world?
Is the question even answerable? - Not for most people. 
​However, I see an opportunity here.  I'm talking about something bigger than just turning a buck, or passing the buck.  We live in an age where anyone can invent entirely new paradigms for living, interacting, and interpreting what's happening all around us.  Focusing on what people outside the organization, such as customers want, makes all the difference in what we notice.  -What's missing.   What's working, and who cares?
Being attuned to what our social environment is pulling for has things jump out for us, which we never noticed before, and Real Options unfold for us to jump into action that never existed in our perception.
What can you do on a daily basis to attune to customer wants and needs?