Scrum 3.0 : Hell or Heaven ?

Very interesting. Who is 3Back, LLC ?

Well, the "Team Captain" has a nice hat.

I think I'll wait for Scrum 4.0

I hadn't heard of this until just now. Based on a cursory reading of their Whitepaper, I'm appaled.

Not because they made this framework. Everyone is free to dream up their own agile framworks and one of these days someone is going to have an idea that's better than Scrum.

What irks me is:

a) The title itself. Calling this Scrum 3.0 implies that it is, in some way, sanctioned by Jeff Sutherland and Ken Schwaber, who are recognised throughout the Scrum community as the creators and maintainers if Scrum. This is an arrogant form of marketing and it is certainly in conflict with the Scrum Values of openness and respect.

b) The Whitepaper claims that this so-called Scrum 3.0 is "consistent with the 2016 Scrum Guide", which it is clearly not! The 2016 Scrum Guide is very clear about the fact that there should only be one product owner. Splitting the role, and putting the "Business Owner", who is outside the Scrum Team (if the pretty drawings are accurate), in charge of delivery dates is the most visible violation of the Scrum Guide and I suspect that I could've found more had I read the thing in more detail.

I welcome new ideas and frameworks for agile development. But can we please not call them "Scrum" if they really aren't?

While I agree that in very many real world situations the implementation ends up with scenarios similar to those described in that Scrum3.0 guide, it 1) doesn't mean it's a good thing and 2) shouldn't be just declared as the successor of original Scrum right away. That's very ignorant. Waiting for a blog post of Ken Schwaber on this ;-)

Scrum is as per the Scrum Guide. This isn't Scrum. It is, perhaps, very vaguely reminiscent of DSDM.

If the originators were to use an original name for their work, instead of calling it a version of Scrum, a level of credibility would be established which might make it easier to evaluate on merit.

It for sure is not Scrum. It's just that especially in larger companies people try to keep a line manager in the teams or that some some manager two levels above the product owner still wants to override the product owner's decisions every now and then. And this whole Scrum 3.0 thing just feels like someone gave up trying to push the transformation any further and just introduce some new roles to define it as a good practice.

It's worth noting that page 11 of the whitepaper transitions from "Scrum 3.0" to "an example implementation of Scrum 3.0," so some of the roles (like Facilitator/Communicator) are not necessarily part of Scrum 3.0.

Scrum allows frameworks to expand off the generalized framework, so I'm not opposed to adding new roles, activities, or similar.  Making a Team Captain a delegate of the Product Owner and making it required would still be allowed by the Scrum Guide, and is still Scrum in my mind.  What I have a concern with is removing the Product Owner role entirely, and the fact that this Scrum 3.0 framework sees no problem with changing and renaming the Scrum Master role.  That's not enhancing Scrum; it's eliminating existing features of Scrum.



Setting that aside and looking at this objectively as a "non-Scrum framework," I see a problem.  Scrum 1 and 2 (by their versioning) intentionally shrunk the chain of command to condense Scrum into a single collapsed unit responsible for delivering Stakeholder value.  Scrum 3.0 seeks to lighten the load and simplify the duties of the Product Owner.  The Scrum Guide addresses this with delegation (which is a parallel process) but this new framework addresses it by adding another level of abstraction between the team and the delivered value.  If backlog prioritization is moved out of the team, and leadership is being enforced, where is the self-directing component of Scrum?



Or since Scrum 3.0 wants real world adoption and scenarios, what happens if the "Team Captain" quits, or if the "Business Owner" does?  Can the team remain efficient and agile while a replacement is found?

Just found out that almost the same day as scrum30.org was registered, also a service called scrumdictionary.com was registered, kind promoting scrum 3.0 as the state of the art with lots of hashtags, links etc. Not to mention twitter etc.

This is all so ignorant and sneaky, it kinda makes me mad.

Enjoy their definition of Scrum 3.0 and keep in mind that the people behind this kind of things are actual scrum trainers...

The Scrum 3.0 lexicon unifies the numerous divergent scrum lexicons found in common industry use. The divergent lexicons are the result of multiple, often conflicting, descriptions of Scrum. The Scrum 3.0 lexicon is an inventory of terms (words of art) from The Scrum 3.0 Model , a description of Scrum that both unifies and extends older descriptions of Scrum and is easier to relate to real world scenarios. Learn more about The Scrum 3.0 Model at Scrum30.org.

This is why I'm really tempted to release Scrum 4.0 because it's one higher.  I wonder if someone will make one that goes to 11?

Enjoy their definition of Scrum 3.0 and keep in mind that the people behind this kind of things are actual scrum trainers...

If I'm reading their web site correctly, they are certified as Scrum Trainers through their own company (i.e. - their own warped view of Scrum).

if true, the level of sneakiness just got deeper...

Well, I tried to respond to your questions, but my blog was rejected because it was deemed "self-promoting and solicitory." So, I'll just respond to one question I see: "who are these guys?"

Well, Doug Shimp and I are very early CSTs (friends of Ken). I'm CST #8 and I think Doug is #11. Between us we have trained 15,000+ CSMs and hundreds of CSPOs. I was a reviewer of the first Scrum Guide in 2009, and Jeff provided a forward to our book, along with Jeff McKenna, Ron Jeffries, and Johanna Rothman. Between the two of us we have over 40 years "doing Scrum".

So, we believe we have some game...

In this post, I'll describe what Scrum 3.0 is...

It's basically a refactoring of the Scrum found in the Scrum Guide to eliminate the schizophrenic objects we see (PO, SM, Stakeholders, and the Sprint Review), and replace them with entities with intention-revealing names. This is why we say it is consistent with the 2016 Scrum Guide.

In addition, we brought back the Abnormal Termination, require the Team to choose a Kaizen every Sprint, and state a preference for continuous planning. This is what makes it more agile...

And, if you really want to know more about Scrum 3.0, download our whitepaper and/or come to one of our conferences. 

The Scrum Guide says:

“Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum”.

@Dan

It's basically a refactoring of the Scrum found in the Scrum Guide

The Scrum found in the Scrum Guide is the only Scrum there is. As mentioned by Ian, it is not Scrum anymore if you refactor it in the way you did. Shimp and you should consider calling it Rawimp or something, as it for sure is not Scrum.

Steven said: "The Scrum found in the Scrum Guide is the only Scrum there is." Yes, Scrum is Scrum, but the Scrum Guide is not its only description... Refactoring the Scrum Guide does not change Scrum, it merely changes its description to make it more understandable (definition of refactoring, remember?).

Scrum is Scrum, and Scrum has many descriptions. This was one main topics of conversation amongst the Trainers (including Ken) back in 2005. One of Ken's favorite saying was: "Scrum is Scrum", and he, himself, has described it in 4-5 fundamentally different ways over the years. Scrum is a living thing that "inspects and adapts" itself as the world (and Scrum's applications in the world) change. Some things that were "hard and fast" years ago aren't anymore...

In fact, Doug and I wrote a whole book that looked into what Ken had written and tried to determine what was actually going on in Scrum. Questions like:

• Is the Product Owner on the Team or not? Ken has said both...
• Is the Sprint Backlog immutable or changeable? Ken has said both...

are fun to discuss, and their answer seems to be "do what's gonna work for you"...

So, Scrum is Scrum, and the Scrum that Scrum 3.0 describes is the same Scrum that is described in the 2016 SG. However, it is described in two different contexts. The Scrum Guide describes a Scrum that involves a single Team, producing a Single Product, treated as an island in its Organization. Scrum 3.0 describes a Scrum that involves a single Team, working on multiple Products, integrated into its Organization. 

This changes the way you talk about it, it doesn't change the Scrum...

Let me give an example, let's talk about what the SG says about Product Ownership, which is what the Product Owner does... follow along...

1. The Product Owner is a member of the self-organizing Scrum Team, so the Product Ownership responsibilities are a subset of the Scrum Team's responsibilities (definition of team as a collection of People... so the team's responsibilities are the sum of the people's responsibilities, which they inherit from the roles they play...)
2. The Product Owner has three big responsibilities:
   1. responsible for maximizing the value of the Product
   2. responsible for maximizing the value of the Development Team's work
   3. responsible for predicting delivery dates for the Product
3. So, the Scrum Team's responsibilities include these three things, as well... and the Scrum Team will self-organize to do them...
4. Now, suppose we have dozens (or hundreds) of Scrum Teams working on the same Product. 

Questions:

1. Is each of those Scrum Teams responsible for maximizing the value of the Product?
2. Is each of these Scrum Teams responsible for predicting delivery dates for the Product?

Or, is there some part of Product Ownership that's done by someone outside the Scrum Teams?

Well, I don't know about you, but most people have decided that the answers to these question is "No"... that Scrum requires somebody outside the Scrum Teams doing some Product Ownership stuff, and some people call this person a Chief Product Owner, or Business Owner, or something...

This is a new Scrum role... and its existence is implied by the Scrum Guide itself. Just sayin'...

I suspect Ken and Jeff are aware of Scrum being described in different ways over the years. That is why we have been given the Scrum Guide to provide the definition of Scrum. The Guide is improved over time, but at any one time there is only ever the one definition. This clarity enables transparency. Anything else we provide is a commentary upon Scrum, and as Scrum professionals we need to be careful not to obfuscate such matters.

Ian, that's half of it. We also need to be transparent about the deficiencies of the current Scrum Guide as it pertains to the situation we are trying to help. The Scrum Guide is merely a model, and our Organizations live in Reality. We need to favor reality over models (I'm sure you can tease that out of the Agile Manifesto if you try).

For example, if the Organization needs a Scrum Team to work on several Products at once, what do we do? Option 1 is to say: "no, each Scrum Team works on only one Product Backlog..." or Option 2: "So, you have two Product Backlogs. We need to zipper them together to make one Results Backlog the Scrum Team can pull from... Your Product Managers will own the Product Backlogs, and your Program Manager overseeing both Products will manage the zippering together to provide the Results Backlog... and you'll need to have a Team Product Owner to manage the tactical details..." 

Which do you choose?

We can be transparent about any concerns we have regarding the Scrum Guide without pretending to replace or upgrade the definition of Scrum it contains. This forum, for example, may be used for such purposes.

I suggest you post the various concerns you have about the Guide, such as scaling matters, as separate threads for focused discussion.

You didn't answer my question, Ian, but I'd guess from your answer you would tell that Organization:"Sorry, Scrum can't help you; Scrum Teams can only work on one Product..."

But, Option 2 in my previous post does not replace the definition of Scrum. The end result is that you have a Scrum Team and a fairly complex set of Stakeholders. The only thing I had to do is change the words to give them more intention-revealing names in the context of the Organization I am coachin - which does not change the Scrum. My job is not to teach Scrum, but to help Organization get better by using Scrum. The easier I make it to understand, the better off I am. And, as you know, the words often get in the way of that understanding...

And, likewise, Scrum 3.0 does not provide a new definition of Scrum; it provides a new description of Scrum that I have found quite useful... Scrum is Scrum, and it is good...

Scrum does not constrain us to either of the options you describe. If an organization needs a Scrum Team to work on several products at once, then team members may perform this work if they can do so without compromising quality or value. Scrum does not require team members to be full-time on a team, and it does not constrain a Product Owner into representing just one product. The framework merely requires that each product be represented by one Product Backlog and have exactly one Product Owner. If a team does agree to work on several products at once, then team members would be expected to frame their commitments and to plan their Sprint Backlogs accordingly. None of this requires an evolution of the Scrum Framework into a purported Scrum 3.0 variant.

That's a very interesting answer, Ian. So, we have two Products, two Product Backlogs, and thus two Product Owners... and you'd have the team members work from both Product Backlogs and "frame their commitments and plan their Sprint Backlogs accordingly."

Wow! What are the team members committing to, exactly?

Scrum makes no prescription about what team members should commit to, other than that it ought to be the goals of the Scrum Team. If team members undertake to perform work on more than one product, irrespective of whether that work is done by the same team or a different one, then the commitments made should be commensurate with those goals. If a team member is working on multiple products, for each of which a Sprint Goal is agreed, then he or she must be satisfied that their commitments to those goals are adequate and can be honored. No team goal can be agreed without such commitment.

So, here's where I have a problem. We are working with a self-organized team where the Team commits to a Sprint Goal, and the Team does work. When you talk about Team Members, I have a problem. The Team is working on two products, not the Team Member. The Team Member is simply member of the Team, swarming on Items... I do not expect to hear the term "Team Member" used in this way when we're talking Scrum...

Now, maybe you're trying to say that there are actually two Teams here, and the Team Members are jumping back and forth, but I hope not. 

Now, here's what I would say. The Team is working out of one Backlog, which combines the two original Product Backlogs. This combines Backlog has an owner, which is the Team's Product Owner. The original Product Managers are Stakeholders, and the Portfolio Manager is who the PO is accountable to for the value of the Team's Results (which consist of working on two different Products). All three of the PMs are SMEs that help in the refinement of the combined Backlog.

There are other ways to see this, of course. Scrum really doesn't tell you how to use it. But that would be the easiest story for the Organization to understand and implement, I think. And if the two Product Managers insisted that they be called Product Owners (as many of them will), then ok, I'd call the Team's Product Owner the Team Captain and drive on...

Whatever you gotta do to get the Scrum to work...

You could view the situation as either one Scrum Team working on multiple products, or as two separate teams which contain the same team members in whole or in part. Scrum makes no prescription either way.

Strictly speaking, a team crafts a Sprint Goal but does not commit to it. Commitments are made by individual team members. The Scrum Guide says "People personally commit to achieving the goals of the Scrum Team". It does not mention anything about a team commitment to goals, and hence there is no rationale for satisfying any such commitment by attempting to combine Product Backlogs for different products.

That's interesting, and I'll give you that one. The new inserted section on Values does say that everybody should live the values... As you know, the values were completely left out of the Scrum guide until recently... none of the words actually appear in the SG (except focus, which appears in the retro section). 

But that quote is not about the Sprint Goal, which is a specific, named thing. I like the following, which is about the Sprint Goal: "The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint." which talks about both the objective (given to the team) and the Sprint Goal (created by the Team).

And, you're right. The Team does not commit to the Sprint Goal. They don't need to. According to the SG: "The Sprint Goal is an objective that will be met within the Sprint." Interesting wording, don't you think? They don't need to commit to it, because it 'will be met'... I think that could be more artfully written...

To me, the SG is quite clear that 'it's the Team, stupid!" It's always the Team in Scrum. Team Member isn't even a role, though I think it should be... LOL.

And, I would certainly go for a single team working on multiple products. I'm not a fan of being non-full-time on a Team, except in certain, specific circumstanced, like being a SME assisting multiple teams...

And, I think the reason we have to combine Product Backlogs for a team is that the Team only has one Backlog, so it only has one #1 thing at a time. 

Anyway, thanks for the chat. This was fun...

I personally don't see anything wrong with Scrum 3.0, or at least not the Scrum 3.0 I found at www.scrum30.com. Scrum 4.0 doesn't seem all that bad either.

Jokes aside, I was a bit intrigued when I first came across Scrum 3.0 on 3Back's website earlier this year while compiling some records about Scrum's history. I had read all of Ken's and Jeff's books and was in the process of gathering all the online historical material I could find about Scrum, including the original "Scrum Development Process" paper from 1995. The historical account on 3Back's website didn't quite line up with other records I had found, and it also wasn't the first site I had found that was attempting to gain credibility by versioning Scrum. 

I think the difference in opinions in this thread comes down to different understandings of what Scrum is. At its core, Scrum is a framework. And Scrum is minimal - it's just enough framework to have clear accountabilities, a cadence to synchronize around, and adequate inspection and adaptation points. There's no rule that says you can't add practices to Scrum when applying it. Scrum actually expects practices and processes to be plugged into Scrum (after all, it is a process framework). However, Scrum doesn't define those practices as it would make Scrum too prescriptive for many contexts. 

Dan, your Scrum 3.0 white paper states, "The more prescriptive a framework becomes, the less adaptable it is. Scrum is the most agile version of Scrum ever." I agree wholeheartedly that the more prescriptive a framework becomes, the less adaptable it is. Unfortunately, 'Scrum 3.0' seems to be quite a bit more prescriptive than Scrum, and therefore less agile.

Your example of a Scrum team having to support multiple products is a problem I've personally experienced as a member of a development team. The company I was working with had an IT staff of less than 15 people, and we had numerous products to support. We used Scrum (as described in the Scrum Guide), and we tried solutions that we thought would work in our context (for example, working on one product for one month and then switching to another product the next month). We weren't 'breaking' Scrum by doing that. Scrum is adaptable enough to work great in those contexts. 

All of the situations you've listed in this thread are quite common and can be handled by Scrum. But the more you add to Scrum to handle those specific situations, the less adaptable Scrum becomes.

Updated links (they were broken in my last post): http://scrum30.com and http://scrum40.org

If Scrum 3.0 is about coaching organisations, I see no benefit in calling it Scrum 3.0, I really don't. I still think it's incredibly misleading, especially because it refers to the Scrum Guide as Scrum 2.0. Scrum 3.0 implies some sort of "official" succession, as if the Scrum Guide was now obsolete and Jeff and Ken had handed over the continued development of the framework to Dan and Doug. That clearly hasn't happened, seeing as another Scrum Guide Update is imminent.

Organisations will believe that Scrum 3.0 is the 'current version' of Scrum if you hand them that whitepaper. Personally, I feel that's incredibly dishonest.

Absolutely, Julian. 

@Dan:

Don't get me wrong: I don't see a problem with people coming up with their own ideas. That's totally fine. What bothers me is the fact that you promote Scrum 3.0 as just another big step in the change history of the Scrum definition. But it's not the next version of Scrum. It's a fork/branch you did. And it should clearly be promoted as what it is.

The inventors of LeSS, Nexus Framework, SAFe and all those approaches extending Scrum providing defined solutions for challenges not explicitly handled by Scrum als didn't just announced "This is the next version of Scrum, because we offer answers to questions not answered by Scrum". They clearly started something new, some extending Scrum, some altering Scrum, some creating something totally different. And that is what you did. You took the definition of Scrum and created a different approach, while simply promoting it as the next version of Scrum.

Implementing "Scrum 3.0" as it is described in 3Back's paper would probably be a change inhibitor, a needless complication and a regression in most of the organizations I've worked in.

As a Scrum Master, I've spent hours trying to find and cultivate invested, empowered Product Owners and showing to (often reluctant) management that a product fueled by constant input from the business fared much better.

I've never seen dedicated Product Owners being overwhelmed. I've known Product Owners who found it hard juggling the 10 other things they were responsible for besides owning a particular software product, but that's because they were not fully dedicated, because management didn't deem the project and/or software in general important enough to give them the time they needed. Not because owning just one product was more than a person could handle.

In these environments, splitting the Product Owner role into two and cutting the decision-making part off of the team is like telling the rare people who have the power to make business decisions : "It's okay if you're too busy to be involved. You don't need to be part of the team any more, your continuous input is not that important, you're above that." Looking at the slide titles and pictures p.8 and 9 of the paper is enough to tell that many people will take it as license for the Product Owner to be less involved than before and go back to doing ten things wrong across ten projects instead of a couple right.

It's the opposite of the kind of change Scrum has been trying to bring to organizations, i.e. agility along the whole chain and success through management endorsement. If "Scrum 3.0" gets picked up, it might well be for the wrong reasons - because it is so much easier to relegate most of the work to a team and their captain and just have an overlooking glance once in a while than taking ownership and responsibility for it.

Equally importantly, many will be tempted to see the Team Captain role as an opportunity to go back to the good old days of micro management and PMs. "Work with the team to ensure the right stuff gets done" is a dangerously vague role description. It could imply anything from checking every screen matches what they assume the Business Owner is thinking to assigning tasks or specific backlog items to team members. "The formal leader of the Scrum Team" also suggests that they are the person who can officially speak in the name of the team and/or is administratively their boss.

This, and... as others have said, was it really necessary to hijack the Scrum roadmap by adding a made-up number to it? As far as I'm concerned, you can call it Type C Scrum. You can call it 3Back Scrum, or « Scrum for busy PO’s » or whatever. Reusing the « trademark » doesn’t bother me. But passing it off as the official next version of the framework, an absolute improvement, something you should apply no matter your context, is just an incredibly dishonest and catastrophic signal to send to newcomers and all organizations who are not in the same situation as the one 3Back assumes as a starting point (and doesn't expand on that much, by the way).

Now that we have a new Scrum Guide, it's even more clear to me that Scrum 3.0 really is a simple refactoring of the Scrum Guide. The 2017 Scrum guide makes it clear that the Product Owner is on the Scrum Team, and is maximizing the product of the Scrum Team's work -- this is the product referred to in the SG.

It has clarified that the outside-the-team PO-like person making business-level decisions is not the Team's Product Owner -- unless this person is also on the Scrum Team. In other words, there are two different roles involved in (what we think of as) Product Ownership -- the on-the-team Product Owner and the outside-the-team Business Owner. Of course, these two roles can be played by the same person, but that person must be on the self-organized Scrum Team. 

This is precisely where Scrum 3.0 starts, by defining the Business Owner and Team Captain roles (we feel it it is quite confusing the call one, or both, of these roles the 'Product Owner'). This changing of the words does not change the Scrum - it is still the Scrum Guide's Scrum - as the word changes don't change the framework...

Understanding that parts of Product Ownership and Scrum Mastering are outside the Scrum Team, and other parts are inside the Scrum Team, is not new. Scrum 3.0 puts names of the parts/facets/sub-roles, which we find makes it much easier to discuss Scrum with people serious about understanding how Scrum fits into an Organization of any size or complexity. It makes sense to them that each Team has a Team Captain and that the Organization can have one or more Business Owners representing the wants and needs of different Stakeholder groups.

As I said before, Scrum 3.0 is a simple refactoring of the Scrum Guide (giving names to the sub-roles we find described in the Scrum Guide), with two simple extensions: a preference for continuous planning, a la kanban, and a bringing-back of the Abnormal Termination to go along with Sprint Cancellation. 

So, right now, there are many different descriptions of Scrum; the Scrum Primer, various Scrum Guides, Scrum 3.0, and others. Most of them are valid descriptions of Scrum, as long as they have DevTeams that are well-formed teams, Product Ownership, Scrum Mastering, and both tactical and strategic feedback loops. Scrum is Scrum, and it has many different implementations, and many different descriptions. Scrum 3.0 is the most flexible and agile, but is also the hardest to understand and implement. Like I said, it's for people that are really serious about understanding how Scrum can help a substantial Organization.

Dan, your post is incredibly self-serving.

Scrum 3.0 is not more flexible and agile than the Scrum Guide, nevermind your inaccurate statement that your proposed Scrum 3.0 is the most flexible and agile.   As stated in this thread, adding roles/process/structure does not enhance agility.

The inaccuracies in your post continue.   The Product Owner was always a member of the Scrum Team - nothing changed with the new Scrum guide revision.   And there are not various Scrum Guides out there.

As stated numerous times in this thread, there is no Scrum 3.0.   Use of that term is incredibly misleading and borderline dishonest, and if you continue to adhere to this naming convention, good luck engaging others around your offshoot Scrum ideas.

I will end by taking offense to your repeated claim that your scrum approach (not Scrum 3.0) is only for "serious" Scrum people.   Unsure why you feel any of your ideas will be well-received while you simultaneously insult your audience.   I am a serious Scrum practitioner, and I find little value in your offshoot Scrum approach.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupery

Quite. If “Scrum 3.0 is a simple refactoring”, I’d dread to see what any code looks like.

Tim, I don't respond to ad hominem attacks, but I will respond to one obvious inaccuracy. I reviewed Ken's first Scrum Guide in 2009, and I have copies of at least 5 versions since then. Ken has published many different descriptions of Scrum, with the main ones being the 2002 book, the 2004 book, the 2007 book, and the various Scrum Guides. Doug Shimp and I wrote a book: Exploring Scrum: the Fundamentals, which analyzed these sources to try to figure out what Scrum actually was. I think the 2017 Scrum Guide is very good, which is why we made sure Scrum 3.0 was consistent with it. 

Like I said, it adds one thing (the Abnormal Termination), subtracts another (preferring continuous planning to 2-phase planning), and is a refactoring of the rest. That's the single-team stuff. The multi-team stuff, which we call Scaling Scrum with Scrum (and we first started talking about in 2006) is basically an extension of the NEXUS.

Like I said, I like Ken's stuff. 

Dan, you may want to familiarize yourself with the definition of Ad Hominem.   

There was nothing personal in my response to you - it was all based on your post and terminology, and the associated inaccuracies in them.

FYI - I like Ken Schwaber too.   I am especially fond of one of his quotes:

"Scrum is not implemented or rolled-out as a process; it is used to foment change."

"Like I said, I like Ken's stuff."

I would sure hope so!..(Considering your efforts to use Ken's work and its namesake for personal profit).