Does Ken and Jeff's Scrum Guide book give flexibility to modify Scrum?

The Scrum Guide says:

“Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”

Understand and embrace the Scrum Values. They are mentioned in the Scrum Guide.

Also understand that Scrum is about empiricism, which relies on transparency, inspection, and adaptation.

Understand the section of the Scrum Guide that Ian quoted above. If you don't follow the rules of the Scrum Guide, it might be the right thing to do, but then it's not Scrum.

With all that in mind, Scrum encourages you to inspect and adapt as much as it makes sense, whilst keeping within the framework defined in the Scrum Guide.

Scrum is a Framework, not a Process, within which you can employ various processes and techniques. Even for teams in the same organization, the Scrum processes they practice are not exactly the same.

The Scrum Framework is immutable, but the practices and techniques for building a Scrum Process that is specific to individual development teams can be changed.

About the Scrum Framework and Processes I recently posted an article on LinkedIn that you can refer to.

https://lnkd.in/fmukzcy

Imeluntuk, don't know whether you're familiar with a Constitution (some countries don't have one). A Constitution is nothing more nothing less than a framework that has to be followed - and what one does within the constitutional boundaries is irrelevant as long as the constitutional rules aren't broken. 

So you can think of Scrum as a Constitution - a set of rules, roles, events and artifacts that are all required in order to have transparency, inspection and adaptation. Within Scrum you can use whatever tools, methods, processes you want as long as said rules, roles, events, articats aren't ignored/bypassed.

First clarification:

That quote is referring to the additional practices that people often do along with Scrum, but aren't mandated by Scrum, such as using User Stories (nothing in the Scrum Guide mandates User Stories,) story points, planning poker, software development practices (automated testing, TDD, BDD), software architecture principles and design (SOLID, REST/JSON APIs v SOAP, microservices, cloud-hosted, etc), modern branching and merging strategy, etc.

It is NOT referring to the key elements of Scrum itself.

And in regards to the flexibility of Scrum, my take is pretty simple: Don't call it Scrum unless you're actually doing Scrum.

--------

(And here's where I diverge from the original conversation a bit and go into my wider head space)

Let's use a metaphor:

You can build a house out of wood, concrete, steel, or masonry. Each material requires different considerations, has different risks, and has different benefits.

You can ALSO mix-and-match these materials, BUT once you start doing that, you have a whole different set of considerations. A timber-and-concrete home requires different connections, fasteners, and considerations than wood alone, concrete alone, or a wood-and-steel construction.

Using Scrum, XP, Kanban, DSDM, etc is very similar. There are elements of each approach that can augment and improve one another as you blend them together, but you need to understand WHY those pieces are there in the first place before you start adding or removing them. Most organizations skip the "understanding," telling me "We want to do Scrum," and then proceed to say "except for that...and that...and that...and that..." The justification is always the same: I (as the consultant) don't understand the special circumstances of their organization.

The real problem is that organization doesn't understand agile principles or practices and doesn't want to face the actual hard process of dealing with deep systemic change.

So I've stopped watering things down for them. If you aren't going to actually do Scrum, don't call it Scrum. You're dong something else..

...and that's fine.

Really, I mean that. It's fine to do something other than Scrum, but let's be honest about that and talk about the implications of those decisions instead of pretending.

When you get down to it, Scrum really doesn't mandate that many things.

1. Cross-Functional development team between 3-9 people that is given the autonomy to build and deploy software development to production on their own with minimal dependencies and are empowered to eliminate those dependencies and continually pursue software development best practices like automated testing.
   
    
2. Product Owner who's given authority to say "no" to anyone in the organization (including the CEO) as long as they have a good demonstrable reason for dong so AND had direct access to the end users that will actually be using the software.
   
   
   
    
3. Planned Work is time boxed to no longer than a month (the Sprint,) and that work is respected, only taking a back seat to absolutely critical production issues or a change in the market/organization that render the Sprint Goal obsolete.4 Events per increment cycle: Daily Scrum (daily), Retrospective, Review, Planning.
   
    
4. Produce completely integrated software that adds value to the end user and the organization at the end of every Sprint.
   
    
5. A list of the current known and/or planned work for the development team to execute (a product backlog), that is subject to change.

Still, that's hard for a lot of organizations. They face large organizational impediments from the old way of doing things and pressure from hire ups that will make some of these things impossible.

Ok, we can work with that. In those cases, we're "working towards doing Scrum, but we're not there yet," and if anyone asks me, "well why aren't we getting the benefits of Scrum," my answer is "...because we don't actually do Scrum -- we're not there yet -- here's what I need in order to get there."

@Kevin Krupp, I really loved the way you explained certain challenges and responses we normally face as scrum masters. 

I'd like to ask everyone though, if certain things are not mandated by scrum, can we still succeed in implementing scrum if certain things are not practiced for ex: no planning poker, teams not having a conversation about user stories or no short descriptive user stories at all, not ranking PBI's by importance etc. Can you help answer by examples?

What is the right thing to call it, implementing or doing scrum?

can we still succeed in implementing scrum if certain things are not practiced for ex: no planning poker, teams not having a conversation about user stories or no short descriptive user stories at all, not ranking PBI's by importance etc.

None of these things are requisite parts of the Scrum Framework. Hence it may be possible to implement Scrum successfully without them.

A team should use the techniques and practices which increase the chances of a successful Scrum implementation where value is maximized. A service team may estimate on the basis of throughput for example, use pro-forma ticketed requests instead of user stories, and PBIs might be ordered by their arrival time.

I'd like to ask everyone though, if certain things are not mandated by scrum, can we still succeed in implementing scrum if certain things are not practiced for ex: no planning poker, teams not having a conversation about user stories or no short descriptive user stories at all, not ranking PBI's by importance etc. Can you help answer by examples?

Very good question. So far I haven't been in a Scrum setup (or agile setup for that matter) where user stories weren't used. How correctly - that's another story. Also interested to hear real examples from more experienced people than us two.

What is the right thing to call it, implementing or doing scrum?

Perhaps it's most appropriate to say "transition to Scrum" if one's not there yet. If they are, then maybe "we're following Scrum" - though I've heards many forms (including the two you mention), ie practising Scrum, abiding by Scrum, working in Scrum, etc.