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

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? 

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.

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. 

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.

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. 

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.

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.

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. 

There are 5 events in Scrum.

As others said, start with why. 

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?

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?

@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.  

Ryan, that was beautifully and thoroughly explained. I also had a problem with the 4 wheel analogy as the wheels do not serve the same purpose. Those 4 wheels would be imperative to the car so that it could function as a 4 wheel car. However, those 4 wheels serve different purposes (and that's where the comparison is no longer viable).

Hello Community members, thank you all for the brilliant answers given to the above worries of Harshal, I have been very confused with the Tell Me about Yourself" interview question, lots of people suggest different answers to this particular question, some say it demands that you give only your career profile, some others say it is good to give a brief resume of yourself starting even from childhood, previous jobs and achievements, some challenges faced at work and your current job and future ambitions and round it up with why you are leaving your current job and why you want to work with the organization.

So where does one actually start when you are asked this famous question during an interview? must we say all these things in 2 to 3 minutes or it depends if the interviewer gives you the laxity to take your time and walk him/her through your career path you could use more time.

I know we have community members here who have been interviewing for several years and will be able to help me clear this doubt once and for all. Let me know what you would expect if you were the interview.

Samuel