What can happen if any one event is reduced in Scrum ?

Last post 04:09 pm January 11, 2021
by Daniel Wilhite
12 replies
Author
Messages
02:29 pm January 4, 2021

Hello to all community members , 

There was a recent question on why scrum prescribes the 4 events and what can happen if we reduce any one of it. 

I thought of sharing my views on this which might help others or maybe create some further insights. I would really appreciate your valuable inputs on this.

As per 2020 Scrum Guide -

“The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. Optimally, all events are held at the same time and place to reduce complexity.”

In Scrum there are 4 formal events - Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. 

Now, scrum being a framework prescribes these events as key inspect and adapt events. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation. Without any one of them will lead to lack in transparency and missed opportunity for inspect and adapt.

So, does this mean reducing even one event from this framework will lead to ‘Scrum But' or ‘Not Scrum’ ? Why does scrum guide emphasize so much on using all of them ?

Lets try to answer this with a short analogy -

There is a machine framework with 4 wheels, an engine and a driving seat with stearing wheel and gears.

Which machine comes in mind with this description ?

maybe a car, right ? 😉 

Now, lets take another machine framework but with 3 wheels, an engine and a driving seat with stearing wheel and gears.

Which machine comes in mind with this description ?

3 Wheeler vehicle ? 3 wheel motor bike ? Autorikshaw ? maybe there are more names….

Lets keep everything contstant/same in these 2 machines like seating place, gears , stearing , engine , windows & doors with just a difference in tyres.

Can it be a car then ? maybe yes maybe no ? But at the end it might still be called a 3-wheeler vehicle.

But why ? They both perform the same tasks , they run on road , take people from 1 destination to other, use same fuel etc. why cant they be called with same name - a car ?

Answer can be - FRAMEWORK of the machines. One balances & run on 4 wheels and other on 3 wheels even though doing exactly same tasks. The only difference i see is their framework. 

Now lets relate Scrum with a Car. A car with 4 events. Removing anyone of the event might change the entire framework thus leading to ‘Not Scrum’ or an altogether different framework.

Can this different framework still work ? Maybe yes maybe not ? But it will surely have a reduced transparency and lost opportunity for inspection and adaption. If for a product or an organization this reduced opportunities are acceptable then even this 3 wheel framework would work for them.

It depends upon the product and organization which vehicle would make their product journey smoother - A car or an autoriskshaw. 😉

Important thing to realize here is there are several frameworks which are in line with Agile manifesto and principles. Once a framework is choosen , it should be used to its full potential before making any amendments in order to evaluate the value generated.

 

 

06:18 pm January 4, 2021

I'd suggest not using automobiles as the basis.  And this statement is why.

There is a machine framework with 4 wheels, an engine and a driving seat with stearing wheel and gears.

You emphasize the number of wheels throughout your analogy and ignore the rest of that statement.  But you have opened up a discussion on the "driving seat, stearing (sic) wheel and gears" which could lead to things such as confusion on the roles of Scrum.  You can illustrate your analogy if you used a 4 or 3 legged table/stool and talked about the stability of the surface. 

My hesitancy on your analogy is that you never explain why all of the events are important.  Yes, you explain that there is more support having 4 events but explaining the benefits/purpose of all 4 events would be a better answer to that question.  Helping people to understand the purpose and scope of each event will better justify the need for all 4 of them.  

Also, could you link us to the original post so that we can see the original discussion? 

07:12 pm January 4, 2021

Can this different framework still work ? Maybe yes maybe not ? But it will surely have a reduced transparency and lost opportunity for inspection and adaption. If for a product or an organization this reduced opportunities are acceptable then even this 3 wheel framework would work for them.

I don't believe that removing an event immediately means that you have reduced transparency or a lost opportunity for inspection and adaptation. The Scrum Events are one set of roles, artifacts, and events that have been demonstrated to work well together to promote transparency, inspection, and adaptation. If you remove one of the Scrum Events, you may have to replace it with something else. Of course, removing or replacing the events does lead to something that isn't Scrum anymore.

Important thing to realize here is there are several frameworks which are in line with Agile manifesto and principles. Once a framework is choosen , it should be used to its full potential before making any amendments in order to evaluate the value generated.

I also don't believe that this is always true. This depends on your approach to change. You could make small, incremental, continuous changes (kaizen) or fundamental and radical changes to the way of working (kaikaku). Each has its place. If you are making small, incremental changes, you may start off with the idea of working toward a particular end state. However, the changes that you make and the things that you learn along the way may result in you deciding to change what your end state is. I'd also suggest, though, that if you do decide to make rapid, radical changes, then you should fully invest in the frameworks and methods before deciding that they do not work.

Why does scrum guide emphasize so much on using all of them ?

I don't think that this question was really fully answered. There are lots of answers here.

One potential answer is "sales and marketing". By emphasizing Scrum as a desired state, people can sell consulting, training, and certification programs. I do think that this also factors into the thinking that if you don't fully embrace what is called Scrum, you should not refer to what you are doing as Scrum.

Another potential answer is that the combination has been well-tested. This also ties back into the idea of sales and marketing. If you are working in a complex environment with uncertainty and ambiguity, Scrum has been shown to work for a lot of people a lot of the time. However, that doesn't mean that it's an end goal. It's a word that just refers to the set of things that is well-tested.

However, I also think that there's a more fundamental reason. Ubiquitous language. If someone says that their team is using Scrum, anyone who is familiar with the Scrum Guide should be able to understand, at a particular level of abstraction, how their organization or team is working. If someone says that they are using Scrum, but they aren't using a particular aspect, the word becomes meaningless. We are back to describing the way of working in a lot more details.

07:45 pm January 4, 2021

My hesitancy on your analogy is that you never explain why all of the events are important.  Yes, you explain that there is more support having 4 events but explaining the benefits/purpose of all 4 events would be a better answer to that question.  Helping people to understand the purpose and scope of each event will better justify the need for all 4 of them.  

Yes definitely explaining the purpose will be beneficial of course. Actually this question came up in one of the Agile event. And the question was what happens to the Scrum framework if one of the event is reduced ? Idea with the above explaination was to highlight that the framework might not be scrum anymore but nothing stops us in reducing any event. But will this different framework (Not Scrum) would work or benefit the organization ? May be empiricism is the answer for it. 

08:01 pm January 4, 2021

You emphasize the number of wheels throughout your analogy and ignore the rest of that statement.  But you have opened up a discussion on the "driving seat, stearing (sic) wheel and gears" which could lead to things such as confusion on the roles of Scrum.  You can illustrate your analogy if you used a 4 or 3 legged table/stool and talked about the stability of the surface. 

Thanks Daniel, point taken !!

I just wanted to bring on the focus that by removing just one tyre from a car can turn it into a 3 wheeler vehicle or an autoriskhaw. Similarly removing just one event from a Scrum can turn it into altogther different framework. So, i mentioned in analogy to keep all the other factors constant or alike in both cases. But i see your point.

08:20 pm January 4, 2021

I don't believe that removing an event immediately means that you have reduced transparency or a lost opportunity for inspection and adaptation. 

Lets say a Scrum Team reduce the daily scrum for some sprints or stop having it at all. Will it impact transparency ? and an opportunity for inspect & adapt ?  

If you remove one of the Scrum Events, you may have to replace it with something else. 

Is it necessary to replace it ? Considering result will be not scrum after removing an event anyway. 

09:28 pm January 4, 2021

Lets say a Scrum Team reduce the daily scrum for some sprints or stop having it at all. Will it impact transparency ? and an opportunity for inspect & adapt ? 

Not necessarily.

The best example is a software development team that extensively uses mob programming. The things that happen in the Daily Scrum are now happening continuously throughout the entire day. Even if one or a couple of people on the team step away, when they return they will quickly get back to speed with the team.

Depending on the particular contexts, there may be cases where the other Scrum Events can be removed and their objectives handled in some other way.

Which brings us to:

Is it necessary to replace it ? Considering result will be not scrum after removing an event anyway. 

It may or may not be necessary to replace it. The Scrum Events do tend to represent the key things that need to happen. I find it unlikely that a team would be successful if the results of any events were simply missing. The only question is if the event, as it's described in Scrum, is the best way for the team to achieve their desired outcome.

It's fine for the result to be "not Scrum". It's important that "Scrum" means something very specific, and doing anything that goes against those rules is "not Scrum". Since Scrum is a framework, there are still plenty of variations in how to "do Scrum". After all, the objective is not to "do Scrum", but to deliver value and adapt to an ever changing environment.

09:55 pm January 4, 2021

I just wanted to bring on the focus that by removing just one tyre from a car can turn it into a 3 wheeler vehicle or an autoriskhaw. 

I'd suggest its more likely to remain the 4-wheeled car it was designed to be, one wheel of which is now up on bricks. Good luck on going places in that.

11:46 pm January 4, 2021

I'd suggest its more likely to remain the 4-wheeled car it was designed to be, one wheel of which is now up on bricks. Good luck on going places in that.

Haha, you nicely brought another view point at this lost/missed opportunity. 

06:35 am January 10, 2021

There are 5 events in Scrum.

As others said, start with why. 

01:21 pm January 10, 2021

Hi Thomas. You mentioned mob programming and that 

"The things that happen in the Daily Scrum are now happening continuously throughout the entire day."

Are we sure?

"The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work"

 

“The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen (projector of course).”

 

To me a key difference here is focus.

Mob programming applies focus to elements of work. Broader discussions about Sprint Goal and progress may or may not occur as part of a team collaborating or doing mob programming.

Daily Scrum is focused, specifically, on inspecting overall progress toward the Sprint Goal and adapting accordingly.

If Developers have worked out an agreement to inspect Sprint Goal progress at least once every day as part of mobbing, then I would say they have Daily Scrum covered. Developers have selected a structure that works for them and the purpose of the event is upheld and benefits gained.

If daily inspection of progress on the Sprint Goal is not included as part of mobbing, and Developers are focused only on tasks, what is the impact to overall transparency? When will  overall progress be inspected and when will adaptations be made to support reaching the Sprint Goal?

01:42 pm January 10, 2021

Agree with Daniel’s early call out on the automobile analogy. I am struggling a bit with using wheels as an analogy for Scrum Events. I understand how they may represent imbalance, or becoming something else if one is missing. For me it also implies that each wheel has the same purpose.

Each Scrum event has its own unique purpose and each supports the others. Removing one doesn’t just impact the one, but it has the potential of impacting all.

I am wondering about using a machine as the analogy for explaining events. Are events mechanical parts? Could this association imply easy replacement of the part or be misleading about the intent of the parts?

Events set a cadence of when, as a minimum, specific artifacts and progress should be inspected and adapted. What about using something event based as an analogy? Perhaps a formula one race as an example?

Sprint: The race event itself. Everything else will happen during this race event.

Sprint Planning: Team looks at the race track, understands where the finish line is and what the goal is, and builds a forecast on how it might approach the race, the pit stops etc. (knowing it will need to adapt during the race)

Daily Scrum: Like pit stops where the team looks at progress, looks at the car, adapts by removing used tires, adding fuel…whatever is needed to make progress on the goal.

Sprint Review: Finishing the race and reviewing the results with race team and stakeholders

Retro: Review the race and how the team worked and look for ways to get better

Now think about removing any one of those events from the race and the impact it could have on the whole.

Daily Scrum (pit stop) as an example: You may say, but the team is working together throughout the race, they are talking over headsets, they are collaborating on problems. Is that enough? Should they skip the pit stop event? Or does it still provide key value to the overall success of the race?

Thoughts?

04:09 pm January 11, 2021

@Ryan Kent  I see your point about using stability as making all the events the same.  I like your analogy.  Could even use something like the Tour de France as an example.  And I think there could be some way to use a machine as an example but I'm also wondering about the "replacing parts" aspect.  

Thanks for challenging us.