Scrum values of courage and transparence

In general people who handle the HR aspects and who fund Scrum should accept Agile transformation and Scrum values. If they don't, and thats' a case in many instances, organization where Scrum takes places is either stagnating or hostile (here is more reading https://www.linkedin.com/pulse/ceremonies-daily-stand-ups-other-hazards-nicholas-gabrichidze ) which requires different tactics and strategy for a Scrum team to survive and flourish.

So always start the Scrum project with estimation of environment, and keep doing it every Sprint. Set your tactics based on this estimation. Remember that its actually Scrum masters job to remove organizational impediments, promote and upheld the Scrum and its values within organization.

How you do it, is another question, you can ask for advice here, many people share their experience.

Hostile organizations, Scrum resistance and outbakes of old waterfall methods aren't worse things.

This is simple problem. The problem is known and solutions too.

What to do what there is something called "Scrum" implemented in the organization by some "Agile coaches", which in practice has nothing to do with actual Scrum as it described in Scrum guide, is more complex problem.

This is always a tough one to work through.

Courage is not about not having fear or not being scared. It can be about doing the right thing and working on tough problems while being scared.

I don't think we can teach courage, but we can demonstrate what it looks like by having courage ourselves. Perhaps in pushing to establish a physiologically safe environment or working with Stakeholders to teach them about Scrum Values and how transparency is a must if we are working empirically.

We can also offer coaching to get to the root of what makes someone afraid and work through scenarios like "what is the absolute worst thing that could happen". Imagine the answer is getting fired. If having the courage to be open is what gets you fired, then think of the lesser things that could have the same result. My hunch is that this would not be the reality, only the fear. I don't know anyone who was fired for courage alone. 

I'd say that courage takes time to build. It is being done gradually and many things have an impact. An important one is the team dynamics. One would have more courage on a team where members are supportive of each other, they have each other back when problems appear. The team might need to go through some difficult times and survive to build strong bonding. I read an interesting book recently with many examples of successful teams, from sports through business, military, etc. where the author examines closely team dynamics, especially the leader's behavior (e.g. coach). An interesting observation was that strong bonding is being also built through countless repetitions of small behavioral cues like a smile at the right moment, or taping someone back. Of course, things like showing appreciation, genuine interest, and own vulnerabilities are not less important. 

Regarding transparency toward the customer. If you sell 'software product development' as a service, showing the inner workings of Sprints is very desirable. It is also a very good selling point. I would definitely prefer the vendor with this level of transparency. 

However, if you are selling a ready-made software product it is not so obvious that you would share this. You might have some proprietary techniques or other things, which are not to be shared outside of the company. In this case, it might be sufficient to inspect and adapt on the Sprint cadence based on the transparent Increment, Product Backlog...

The last time I suggested showing to the customer the sprint backlog : the immediate reaction was: we'd have to make sure that we didn't show the customer certain user stories.

Does that indicate a lack of courage, or a deficit of soft skills?

Instead of trying to teach courage to someone who's scared, address the root causes about why they are scared so that way the thing that they should or want to do no longer frightens them.

Thank you for your answers:

I'll try to summarise:

I think that forcing yourself to work out of fear is not viable in the medium or long term. It would be the best way to fall ill, because you're expending too much useless energy. 

Working on the root causes of fear is a good thing, but can it be done in a professional context? 

Being able to talk about your fears would be a good start. 

I trained as a sophrologist rather than a coach, because I think that this work should be requested by the person themselves and outside the corporate context. 

Thinking the worst seems to me to be an anxiety-provoking and negative solution. It would be better to remain positive.

Team dynamics: This is in fact a very powerful approach, which can create a reassuring framework provided there is unfailing mutual support. 

Lets approach your question from pure professional Scrum perspective, locking emotions(fear and panic) in the box and hiding the key for a second.

So what's happened is a very simple Scrum situation-certain stakeholder inspected the sprint back log and asked to change it: to remove some items from it.

Scrum provides textbook recommendations for such situation.

Stakeholders feedback should be shared with a Scrum team as soon as possible.

Product owner and developers should discuss the changes in a Sprint backlog

The reasons why stakeholder wants to remove items from Sprint backlog had to made clear to Scrum master during the meeting with a stakeholder. They should be communicated to the Developers and PO.

Scrum master should make sure that intended changes to Sprint backlog(removing items) would not harm Sprint goal and increment of value during the sprint; technical debt should be taken in the consideration.

The assessment of the environment where Scrum team finds itself, which I have mentioned in previous post of mine should be taken in consideration. Is the refusal to meet stakeholders demand threatening the survival and security of Scrum team? If yes, it is an organisational impediment which Scrum master should address, and which will take time to fix. Decision should be made based on this factor as well.

This situation should be addressed at the Sprint review where stakeholder, who asked for the change, should be present

During the retrospective Scrum team should address the presentation of Sprint backlog as non functional requirement which should be used for improving the performance. And also discuss how should they prevent such situations in the future.

Create more livable Sprint backlog next sprint.

Elementary Watson...