Using alternative techniques - still Scrum?
My team are experimenting with techniques which are different to classic implementations of Scrum. Let me give you some examples:
* Walking the board DS instead of the 3 questions
* Ditching story points and velocity, replacing with story counting and using Monte Carlo Simulation to forecast what will be in the sprint - a #NoEstimates approach
* Not doing task breakdown in Sprint Planning - instead using a Kanban style board where stories flow across
Strictly speaking, I don't believe this can be called "Scrum", given the Guide calls out the 3 questions and I believe there is a mention of estimation and task breakdown.
I think of this as a Ha or Ri stage in the Shu Ha Ri Model - kind of feels once you pass Shu, you should no longer call it "Scrum" - what are your thoughts?
I think of Scrum being specific about the key elements of Scrum (daily Scrum, Sprint Planning, ...). Some of the things you mentioned, like story points or velocity are optional in Scrum. Some say, if you're not doing Scrum, by the Scrum Guide, you're not doing Scrum, you're doing "ScrumBut." That is we're doing Scrum, but we only do the Daily standup on Tues and Thurs and we don't do retrospectives every couple of Sprints, ... That's not Scrum based on the Scrum Guide.
Note there is flexibility in how some things are done. Again, as an example, burn-down charts are optional, velocity is optional, Scrum boards are optional, ... So there are choices you can make within the Scrum Framework.
My experience has been that it's best to start with Scrum by the Guide and modify after you're learned Scrum. This, leads to moving away from Scrum alone where you may mix Scrum with other variations... Get good at Scrum first before you try to change the framework.
Consider walking the board and wrapping up the Scrum with each team member then summarizing their own position.
Start with SCRUM by the guide. At least it's well documented and easy accessible. Team members and everyone else involved need to be on the same page (preferably on the same sentence or at least the same paragraph).
If this fails for some reason then an alternative way of working could be introduced, but only if everyone involved is familiar with this way of working. If you call it Scrum and anyone with Scrum experience enters the team, he/she will be confronted with a different way of working.
If your family plays a self-invented game at home called Choker (playing Chess with Poker rules) and only your family members know how to play this game then you can't invite your neighbor to come and play a game of chess or a game of poker. If he thinks he's coming to play Chess he will be in for a big surprise. He has no way of winning any games either. Any bystanders expecting to see a poker game, have no clue what this Choker game is all about either.
If the changes in the Chess game are only the color or the shape of the pieces then you can still call it Chess. If new pieces are introduced and certain pieces move differently and two dices are used before every move and a trivia card needs to be answered then you can't call it Chess. It's Choker...
As Rick Smith stated, the examples given are not specified in The Scrum Guide. Those are techniques that can be used within the Scrum framework. Trying different methods can be an important part of learning in order to create a high performance Scrum Team.
Excellent example, Nicko DeBeer! "A common language referring to the process must be shared by all participants." If you are violating the guide, do not call it Scrum. "Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." Any time that a Scrum Team wants to modify the framework, there needs to be a discussion about why that role, artifact, event, and rule exists and what value could be lost with said change.
The Scrum Guide does not require that each Development Team member answer each of the three questions in turn; that's a status report. Walking the board is another technique that often results in a status report. The purpose of the Daily Scrum event is to inspect and forecast. Through a discussion the Development Team can explain the information to expressed in the questions.