Replace "Ensuring" with "Encouraging'#5

“Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.“ - SG

As the rules of guide relationships and interactions, I think that ensuring is too strong of a command. It can make the Scrum Master insensitive to context of the situation and act like an enforcer.

If we can imagine situations when ensuring may not be suitable, I think this should be changed.

I think the whole Scrum Team, given that they are all professionals in the game of Scrum, should be equally accountable for encouraging each other in this.

Therefore I suggest:

“For the organization to experience the benefits of Scrum, the Scrum Team members encourages that Scrum events take place and are positive, productive, and kept within the timebox.”

I strongly but respectfully disagree with this. :) Teams follow the Guide in a state of Shu before they evolve to a greater level of agile maturity. A problem I have experienced time and again, is immature teams, often in project-oriented environments trying to skip events without realising the impact it has their ability to progress empirically.

The Scrum Events have been proven to be a minimal set of practices necessary to achieve empirical process control. The majority of problems I have seen with Scrum arise from inexperienced people not’ doing things as per the Scrum guide, before they have the foundation in place. Choosing to skip events is the most common symptom of this.

Skipping events is a symptom of a problem, not a solution. The solution is to identify why the team feels the event is not valuable enough to take place. Usually its because theyre not actually doing ‘Scrum’ in an agile environment, theyre just calling it that.

The events in and of themselves create the opportunities for individuals to interact so that they can self-manage.

It is good to assume you hired mature professionals and in Scrum that begins by respecting people to be capable individuals. Being told to/ensured/enforced is a poor way of demonstrating this. There are better ways.

Encouragement in this context means to demonstrating courage and guiding why doing something is worth doing, with support, so it can be executed with intrinsic motivation. This is more in line with living the values than ‘ensuring’.

A Scrum Master can demonstrate the impact of non-attendence has as a means to encourage participation and by means of holding each other accountable as professionals. That would be a much more respectful and constructive approach then simply ensuring the events take place and ensuring they are positive. This can lead to toxic situations.

Ensuring events to me is one of the symptoms that leads to Zombie Scrum. Enforcing the events does not explicitly lead to individuals understanding the value of the events as we see many practical examples of this.

Ensuring does not have to be done in a commanding way just like a red-light/speed camera on the road can ensure drivers does not exceed the speed limit.

I do get that ensuring doesn’t have to be commanding, but a way to ensure something is to enforce something.

A red light is a visual command to stop, but it does not ensure that you stop. You could still run a red light. An iron bar, a concrete wall or an automated breaking system would ensure that your stop. That’s the difference.

I see the point here, and I feel that “encourage” does sound mild, not convincing, as if a SM may try (or may not). I’d keep “ensure”.

I strongly disagree. If one has a mechanical view of Scrum then this may seem valid as it is about the execution and running of the events.

However, this is not what Scrum is about. Scrum is about empericism, transparency, inspection and adaptation. Every event has a disinct purpose to raise trainsparency, inspect and adapt.

E.g. Sprint Planning. It is not about mechanically executing the sprint. But to make transparent the effectiveness of the planning. Questions like “Is planning working?”, “Are we planning too little or too much in advance?”, “Are we going into too much detail?”

Forcing the empericism; that transparency, inspection and adaptation , is essential to Scrum. Without this you may as well throw out Scrum and not use it.

Scrum is not about the mechanical execution of sprints, events but more about creating opportunities are get better transparency on what is going on and the change what is not working. This brings in an active risk control mechanism that allows everyone to eradicate the nonsense that is not working well.

If one does not ensure empercism, you have just killed Scrum!

@Brett can you have empiricism without ‘ensuring’ the events take place, are positive and remain within the timebox? Naturally you can.

You learn by doing and find better ways. Ensuring is what makes things mechanical.

Again if we can imagine situations where ‘ensuring’ is not sensible in the context, and the context requires adaptation, then this is empiricism at play too.

@Sjoerd Nijland , it’s not so much about ensuring the event. Instead it is about ensuring empiricism. That is a massive difference.

In this suggestion I am not refering to ensuring empiricism. It is about the line that reads:
“Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.“ - SG

I think you consider that ensuring Scrum events aims to ensure empiricism. Empiricism can be lived even without ensuring Scrum events. Whether its this way that Scrum aims to ensure empiricism in its framework I also disagree with as I outlined before. Now I am not saying we should prohibit Scrum Masters from ensuring this. But there are better ways and there will be situations where ensuring them does not make sense, not even to ensure empiricism

Sjoerd Nijland in that scenario you can ensure the Scrum events happen by teaching and inspiring people the benefit of those Scrum events. Like @Brett said, it’s a matter of perspective. If you have a mechanical / command-control perspective, then you will view that the only way to ensure is through force.

@Joshua Partogi In that scenario I can also encourage the Scrum events happen and encourage attendance by explaining that that is a good way for people to experience the benefits of them.

Just ensuring the events does not guarantee that participants will understand the benefits. There are many examples where events and attendence is ensured, but the value is not experienced.

Ensuring may not be best and may not always lead to teams experience the benefits. Neither does encouragement. So using that motivation does not qualify. In and of itself I think it is better to motivate and guide individuals so that positive and productive events are possible. We can do this through encouragement.

Disagree. SM needs to be accountable for positive team dynamic. If we keep weakening the SM role, it will continue down the track of Jira admin at the lowest cost.

I strongly disagree and many good arguments have already been laid out. I want to add one more: “Ensuring” reflects that something should happen, while leaving open how to make it happen. “Encouraging” on the other hand, prescribes the how (through encouragement). I would leave it up to the Scrum Master how to make it happen and consider the respective context of the team and the situation. There are plenty of ways for how to ensure that Scrum Events take place.. teaching, motivating, explaining, experimenting… or encouraging. Let’s not limit the Scrum Master to one way.