Hi Mike,

How do you align your message with other people who say, for example, Scrum is like chess, it has rules and you do not break them?

Thanks, Jamie.

In my experience, Scrum *is* like chess and you get in trouble when you start breaking the rules.  They are meant to check and balance the other rules in the system.  At least, don’t change the rules until after you’ve mastered the current rules.

that said, my interpretation is that Mike is primarily refering to agile.

Hi Jamie & Brent—
I think it’s perfectly appropriate to compare Scrum (or agile, in general) to Chess. So did some of the very first articles on Scrum—e.g., see “The Chaos Strategy” by LBS Raccoon in ACM Sigsoft Software Engineering Notes from August 1995. In that paper, though, Raccoon ultimately decided that it is more like the Oriental game of Go than Chess.

I don’t have a problem with there being some rules—my post listed some. I’m sure I missed a few but probably not many. Even Chess doesn’t have very many rules but some are a bit arcane (e.g., en passant). Go has even fewer rules yet is a more complex game. So, it’s not that we can’t have rules, it’s that we shouldn’t have many. For example, why in the world would there be a rule that the daily Scrum starts with the person to the left of the ScrumMaster and progresses clockwise around the room? Yet, that has been written in a prominent Scrum book as, effectively, a rule.

The best rules are generative rules—rules that generate the right behavior, something that Highsmith and Cockburn wrote about years ago. Beyond the generative rules, agile and Scrum teams benefit more from guidelines than more additional, prescriptive rules.

Thx for this article, its very interessting to read your impressions. Its correspondig to my experiances of the last time. I am told: “If you don’t do this.. you are only a >>scrum but<<..
And it is more impressive to me that you have linked to Jims and Alistairs more then ten year old article, as I like read/consume this articles and books out of the agile manifesto time again and its very interessting to find "new" details I had not "see" the years before.
Thx Werner

Thanks, Werner. I’m glad you liked the post. The whole idea of ScrumBut has gone too far. It was a cute article the first time I saw it but has become more of a club to hit people with since then.

If we think about it, improvement comes from being a “ScrumBut”. Imagine some Scrum team long ago deciding, “30 days is too long; let’s do a two-week sprint.” Someone would have laughed at them and called them “ScrumBut.” Yet, they were onto something and two weeks is by far the most common sprint length today.

Hi Mike,

I have to agree. I also hear / see a lot of people trying to refer to rules and make them into “Best Practices”. I really don’t like this idea since it tends to stop people from thinking about what they’re doing in their current situation. I much prefer the idea of a “good practice for the given situation” as it tends to make people stop and think about the applicability of the “rules” in their current circumstances. Since we’re in the business of producing intellectual property, I believe that we owe it to our customers to continually stop and think about what we are doing, how we are doing it and why - and then see if we can do better.

Cheers,
Daniel

Hi Daniel—
I completely agree. I try to rarely use the term “best practice.” Like you, I’ve got a variation on it. I use “Good practices in context.”

Hi Mike,

Thanks for a very good post. There is a tendency to view Agile practitioners as ”religious” so having recommendations rather than rules is good. But I agree on the rules that you mention as the basic rules – without them you’re not doing Scrum. The rest is just recommendations that experienced Scrum practitioners are practicing to increase performance.

Cheers,
Klaus

Hi Mike,

Thanks for this article !
I agree that every concrete ideas made must be recommendations instead of rules.
But I still think that there abstract ideas that are really needed.
For example, if you want to succeed with agile, you need feedback, and as frequent as possible. You also need to communicate efficiently, to provide auto-organization, and so on.
These can’t be only recommendations I think.

But what is really specific to a context is HOW get feedback, how to communicate, how to auto-organize, etc.

Thanks, Klaus. I’m glad you agree.

Hi Jérôme—
I don’t disagree that there are some things that are so important or fundamental that we can elevate them to the level of rules. For example, you mention feedback. I wouldn’t object to saying that a rule of agile is “Get feedback frequently and act on it.” Something like that was included in my very rough list of rules in the initial post. I said use short iterations and get feedback from stakeholders at the end of each iteration. So, I’ve said getting feedback is a rule.

But you’re right that *how* that is done is generally best left to the team. We can provide teams with good advice about what other teams find helpful for getting feedback but each team needs to find what is best for them.

Mike,

Thanks for another great post, and your leadership on this point!

I agree that there are far too many folks out there (many of them prominent and respected) going a bit overboard in terms of establishing “rules”. I think a few causes for this may be that training and folks writing books and blogs often (with the best of intentions) make lots of distinctions about “This is Scrum” and “That is not”.  After all—these are people being paid to be “authoritative” on a subject. There is a natural tendency to want to establish clear answers. I also think that in a basic training course (like CSM), there is a good reason to tell people “do it this way before you start tinkering with the framework,” which often communicates “these are unbreakable commandments.”

I think you hit it on the head with “Improvement comes from being a ScrumBut”. Scrum *should* be a meta-level framework that helps a team identify, execute and improve its approach over time (rather than a set-in-stone approach in its own right). But people tend to want to know “what to do” rather than “how to approach determining for myself what to do”.

I think we just need constant reminders about this to keep us from becoming complacent. Thanks again!

Thanks, Michael. Your point about CSM (or any similar) training is very appropriate. In my Certified ScrumMaster courses, I advise people to “start by the book,” meaning I want them to do it exactly the way I’m describing in class or exactly the way they can read in a book. But I also tell them soemthing like, “A year from now I don’t want to find you doing it by the book. A year from now you should have found variations and improvements that fit your situation better than any book or course could describe.” 

So starting “by the book” can be great—you’re at least starting in a proven way—but we don’t want to get stuck there and never find improvements.

Hi Mike!

Thanks for the post. I completely agree.

I think there is a kind of symbiosis: someone rules about something and many people likes/accept to be ruled about that. To brake this, imo, we need to emphasize that TEAM is responsible for the process they use. Point. Team must take the risks/opportunities to fail/improve their process.

I have a long post on the subject (sorry, it is in portuguese: https://desenvolvimentodesoftware.wordpress.com/2011/12/12/franchising-de-metodologia-poderemos-ser-escravos-de-algum/), basically to say that:

  . methodologies are not franchising,
  . we must care about not being a kind of methodology/process/tools slave.

I loved the reference to Highsmith and Cockburn about generative rules: very appropriate.

Cheers,

Arisio

Hi Arisio-
I’m glad you agree. You are absolutely right that we do not want to become slaves to a process or tool.

Happy New Year Mike.

Great post.

I agree that trying to prescriptively codify system-software development is against the grain of “being” agile.

The what, why, who, when and how of agile product (system-software) development and delivery is not one person’s vision alone and cast in stone; to become reality it needs to be a “shared” vision through negotiation and compromise between individuals, the team and the organization.

What is important to understand and come to grips with is as you, your team and your organization evolve and adapt to being and doing agile it is about each existing role in your organization complementing each other’s responsibilities while working towards the iterative and incremental delivery of the product. As an individual, team and organization work through the redefinition of organizational roles and responsibilities negotiation and compromise is key. As time goes on, the team members should reflect and refine their roles to meet the goal and needs of the team and organization.

Hi Mike,

Great article. Totally in agreement that non mandatory best practices should come as recommendations and not rules. It helps a great deal in my experience where the team organically starts to adopt the best practices and starts believing in it when they are presented as some recommendations to try out in future instead of some corporate rules or policies etc.

Thanks for a post on a very important topic. I have lately run into discussions if Scrum Guide is an ultimate bible and do recent changes need to be adopted by every team. And there are a lot of discussions on how this and that must be done in Scrum. I think many people are forgetting the empirical process and are too much focused on rules rather than evaluating what they are doing and what would work for them. On my CSM course the trainer asked that if you had to choose one of Scrum’s meetings as the most important one to have, what would it be. Most answered the daily, the second most popular was the planning, a few answered review. After a short discussion about why each meeting is there the whole class agreed that the most important meeting is actually the retro. And to this day I agree with that.

There is no “ultimate Bible” to Scrum. That era passed in about 2001. No team should feel compelled to change because of something in any book or PDF.

The exercise of picking the most important Scrum meeting is an interesting one. To me, though, it’s kind of like asking which of my lungs is more important. Or perhaps better, which chamber of my heart is more important. I need them both.

I totally agree no team should feel compelled to change because of something in any book or PDF.

One way to look at the current Scrum Guide is it defines the immutability of what is and is not Scrum.

Deviating from the Scrum Guide may in any given real-life situation be acceptable and absolutely the right thing to do. What is a good practice though when you do so is to not label what you are doing Scrum.

BTW: Daily Scrum, Sprint Review, and Sprint Retrospective are now referred to as “events”. Being asked which Scrum meeting is more important is a great exercise to make sure everyone has the same understanding about each meeting (event) and then better understands the consequences of not conducting the meeting (event).

Hi Russell—
That is perhaps one way to look at the scrum guide but I don’t think it’s the right way. It’s one (or two) people’s view on what is immutable about Scrum. And their view is very different than what it was years ago. Where are synchsteps for example? Where are the Planning and Closure phases of Scrum that were described in the 1995 OOPSlA paper?

What about the idea that one of the ScrumMaster’s duties is to make sure there are enough chairs at the daily scrum so that each person can sit down? Yep, that’s in the Agile Development with Scrum book. Or what about the idea that the Product Owner estimates the product backlog? (Same book.)

Scrum evolves. It evolves because lots of people use it. It is defined by the collective of people who use it, not by any one person. If you don’t believe me, you may want to look at Ken Schwaber’s view on this:

I’ve talked to God about this and he/she refuses to make me the sole source of knowledge regarding Scrum, if you can imagine that. Direct communication with the disciple is still used.

This was from a post to the scrumdevelopment list back in 2006. So, I’ll continue to follow that belief that there is “no sole source of knowledge regarding Scrum.”

Hi Mike,
As I wrote in my first comment to this particular blog topic I agree the what, why, who, when and how of agile product (system-software) development and delivery is not one person’s vision alone and cast in stone; to become reality it needs to be a “shared” vision through negotiation and compromise between individuals, the team and the organization.

Agree. You’ll see in our recent blog post on “5 Do’s and Don’ts for Managing Distributed Teams - A Tech Lead Speaks” - http://blog.assembla.com/assemblablog/tabid/12618/bid/75793/5-Do-s-and-Don-ts-for-Managing-Distributed-Teams-A-Tech-Lead-Speaks.aspx

The last point under Don’ts is “Don’t Have Rules”

Great blog. Keep up the good work.

Thanks, Adam. I’ll check out your post.

I shall print this post and hand it out to 50%+ of agile coaches I meet. They will be surprised.

But being serious, I believe this is what we were asking for. On one hand way too much orthodoxy among agile thought-leaders, on the other going into mainstream where many organizations just need another badge (yup, we are agile - see this cert) and that’s the result. We end up hard-coding rules which makes the approach less and less applicable, as feasibility of applying any solution is always driven by its flexibility.

No wonder that we see more and more agile adoption failures.

Yet still, I believe that what you’ve written is very important. Not that it’s so fresh and new - with a bit of good will it can be called common sense. It is because it still may save a bunch of transitions which are, say, challenged.

Hi Pawel—
Thanks for your comments. Too many people are too pedantic about agile—it’s a set of principles that lead to an ever-evolving set of good practices in different contexts. And, yep, it leads to failure too often.

I think you’re spot on here.  However, I would be tempted not to even limit it to those rules.  The problem with a bunch of rules, is that there’s nearly always an exceptional edge case where they can be broken.  the whole working in iterations idea, is all well and good, but do I have to use iterations to be agile?  I don’t think so.

For me the problem is a lack of understanding in application of agile process theory.  I agree that too many books published provide too many hard and fast rules around how to “do” agile rather than say, in this situation our team did this and here’s the result, this is what we went on to improve.

You are right that people are getting too bogged down in trying to define Agile with an ‘A’ as opposed to an ‘a’, writing books and cashing in is all very well, but if you’re being prescriptive, then the risk is that you harm the craft and reduce overall progress in software development process improvement.

Hi Oliver—Thanks for your comments. I didn’t think very hard about the short list I provided. I’m sure there are many other rules we could say are valid. Perhaps, “Don’t stick just to your job title. Work beyond that to help the team.” And, yes there can always be extenuating circumstances for even obvious rules—-“Drive on the right side of the road” is one I follow. But a better rule might be “Drive on the right side of the road until a semi truck is headed for you in that lane.”  But then we could also add, “unless there’s a massive pothole in that side of the road and you need to safely go around it on the left.”

As for getting rid of iterations, that’s something we’ll have to save for another debate. I think there is something very important about iterations and I’m not willing to give that up. Building software iteratively has been a best practice for decades. I understand Kanban is willing to give it up, but that’s one of many reasons why I don’t think Kanban is a broadly applicable process. It has it’s uses, but too many projects benefit from iterations for me to give them up very often. But, again, something for another blog post and debate.

Great post Mike! I had emailed to my boss who wanted to apply rules, and more and more of them. It seems to me that wanting more rules could be an indication than management does not trust the teams to become disciplined and self-organised. In other words, if you TRUSTED the teams, you would not really feel any urge to add rules to the ones you have mentioned below?

Cheers
Ch

Thanks, Christophe. I think you’re largely right that a trusting environment will have fewer rules. But that doesn’t mean that every boss’s attempt to add rules to an environment is ill-intentioned. Sometimes bosses add a rule because they think it will help the team (“fill out this Database Impact Report for every change”) so their intent may be good. But teams fill usually take it (and rightfully so) as a loss of a degree of freedom.

Completely 100% agree.

I’ve noticed a growing number of articles and books defining and insisting on rules that MUST be followed (otherwise doom and gloom). One of the main reasons why I went down the Scrum route was because the methodology is making recommendations for how to improve but also supports evolution of the methodology so you achieve the ‘best fit for the team’, unlike the more rigid methodologies.

A lot of Agile books are moving in a direction to satisfy the management of larger corporations; words such as consistency, standardisation, etc.. are being applied to processes, ceremonies and other aspects of Agile / Scrum. I normally find that management that wants standardised teams are often too fearful of letting go, having faith in their teams and genuinely empowering the teams to deliver. Micro management fears??

Another factor is also because the books also have to find a unique selling point in a crowded topic space.

I constantly preach to all the teams I’ve worked with that ‘one size does not fit all’ and that teams should look towards evolving their model through continuous improvement (kaizen’s are a wonderful thing, as long as its ran and owed by the team and not the management). One of the best take-aways from my CSM with Mike was that you should evolve your Scrum model.

Thanks, Carl. And yes, you’re right, there does seem to be a growing trend toward prescriptiveness—“experts” saying “you must do it exactly this way” and forgetting that a tremendous amount of agility comes from adapting to the culture and project. One of the things I love about Scrum, for example, is that it is deliberately incomplete, allowing (requiring) teams to complete it as appropriate for their contexts.

Mike, I’ve noticed that you tend to discount “some PDF” or “that PDF” (referring to the Scrum Guide it seems, but you never say that)(maybe you’re also referring to the Scrum Primer?) in your postings. 

It seems to me that you have a vested interest in discounting the Scrum Guide as it is owned and created by Scrum.org, which is a direct competitor to you and the Scrum Alliance (of which you are the Chairman of the Board), at least for the hearts and minds of the Scrum community.

One the one hand, we have Ken Schwaber of Scrum.org saying that the Scrum Guide as a whole is the “Rules of the game”, and on the other hand, we have Mike Cohn of the SA saying “There are only a couple of rules, and the rest is just recommendations.”

I respect both leaders and both organizations immensely, but I think it’s time that we admit that the two orgs are in co-opetition with each other, or maybe just straight up competition.

I also respect both views(Lots of rules/Few rules) quite highly.

Hi Charles—
I don’t think anyone has ever denied that the Scrum Alliance and Ken’s org are competitors. Ken left the SA to start a competing certification so, of course, the two are competitors. To my knowledge, both are succeeding.

As for the Scrum Guide, I have a number of issues with it: first some silly syntactic changes such as “prioritized” to “ordered”. These are clearly synonyms since “prioritize” means “to put in order.” Second, I find it curious that Ken tries to position it as the single authoritative definition of Scrum when he previously acknowledged that there was no “sole source of knowledge regarding Scrum”:

I’ve talked to God about this and he/she refuses to make me the sole source of knowledge regarding Scrum, if you can imagine that. Direct communication with the disciple is still used.

Reference: http://tech.groups.yahoo.com/group/scrumdevelopment/message/15039

Also, anything I post here is my opinion and has nothing to do with my role on the Scrum Alliance Board. If I ever speak for the Scrum Alliance, it will be on that site.

Returning now to the specific issue of this blog post, I’ll say this about viewing the Scrum Guide or any other source as the “main source of rules.”

1.  To my mind, the Scrum Guide is far and above the most credible source for what Scrum is and isn’t, and how to do it correctly.  As such, I pay very little attention to all other sources insofar as defining Scrum.  By association, whether people like to hear this message or not, if you’re doing it incorrectly, it’s probably because you have broken one of the rules or principles in the guide.  I thought at one time I had heard that the SA was on a quest to have a similar “highly credible document/collection” of information.  If one were ever to be published, I’d probably at least put it close to the Scrum Guide in terms of credibility, but that has not yet happened.

2.  To my mind, your _Agile Estimating…_ and _Succeeding with Scrum_ books are far and above the most credible sources for how to do Scrum *well*.  As such, I pay less attention to all other sources insofar as doing Scrum well. 

3.  You mention above that you recommend students new to Scrum to do it “by the book.”  First, which book do you speak of? (is it metaphorical, possibly?  Are you really referring to what you teach in your training as “the book” ?)  Second, you want them to be deviating from the book after one year.  Many of what I call the “software anarchists” will read this to mean that so long as you start by the book in Sprint 1, it’s perfectly fine to begin breaking rules in Sprint 2 and returning to old bad habits.  If said team is being shepherded by a highly knowledgeable coach like yourself, then this is fine because the team will be shepherded well, but if they are weak in software process knowledge, this is probably not a good thing, and it won’t be long before their Scrum implementation crashes and burns and we see yet another blog post on the internet on how Scrum didn’t work at an org.

4.  In the cases where we argue for flexibility, rule breaking, deviating from the book, and also in the “Scrum didn’t work here” cases, we as coaches are self serving when we encourage these routes that really require good coaching shepherds.  That bothers me some, though I don’t have a lot of answers either.  The one thing I would like for us(The Scrum thought leadership community/coaches/trainers) to remember is that out there on some team there is a “little guy/gal” trying to do Scrum well by following credible sources like the Scrum Guide and your books, but because his team members have been given explicit permission to break most of the rules by you and other coaches, it’s not working out very well, and Scrum is getting a bed reputation in those orgs.

On the one hand, I truly believe that Scrum is much more successful with a good coach, but on the other hand, it pains me as someone who has spent my life in software development to say that you really need a Scrum coach/shepherd to do Scrum well.  It speaks to the weakness of the Scrum movement, IMO, and I think we need to do better on this front.

Hi Charles—
I won’t debate which book or PDF is the most credible as I suspect that will be a matter of opinion. A number of other good books came out in the past year or are coming out that attempt to do this. Certainly, though, the guide has to be considered among the top in any such list.

I tell classes to “do Scrum by the book,” and point out that this can mean any credible book, or what I teach in that class, or what a credible coach is telling them personally. “By the book” is, of course, a general purpose saying that does not always refer to a book. What I want is for people to start in a proven way. Follow some guide exactly before starting to make any changes. But eventually a team must make changes to the process in order to own it. Cockburn has written about the need to own a process a “critical success factor.” I fully believe that. Of course that does not mean a team changes the essentials (that becomes ScrumBut). At some point (I just say “a year”) a team is capable of figuring out what they can safely and should change to continue improving.

Mike,

I appreciate your honesty and clarification regarding the competition between the SA and the S.O.  I think you are right in that they are both succeeding and I personally think the competition is very good for the Scrum community in the long run.  I have a ton of appreciate for both, but for different reasons that are off topic from our discussion.

I already saw the previous quote from Ken in the above comment, but since you brought it up again… Of course he and the Scrum Guide aren’t the single source.. I agree…But like I said in my post just now, it’s probably the most *credible* source insofar as *defining* the Scrum approach(and “rules”), so I don’t mind when people use it to help understand whether they are doing Scrum correctly or not.  I definitely caution them when they are making major deviations that could have negative consequences, as I think any good Scrum “shepherd” would, and even then let them experiment if they think the caution is unwarranted, etc etc etc

As for the terminology changes in the guide, I would think you might be more appreciative of them.  Your statement in this original blog past was:

> “at the end of the iteration, reflect on how well you did during the iteration”

I believe that Ken finally realized(and I don’t speak for him of course), after reflecting on the previous “iteration” of the Scrum Guide, that improvements needed to be made.  S.Org has fully explained the change in terms like “prioritized->ordered” and “commit->forecast”. 

Are we really referring to someone’s attempt at “inspect and adapt” the Scrum approach to be “silly?” 

That just doesn’t seem right.

> At some point (I just say “a year”) a team is capable of figuring out what they can safely and should change to continue improving.

I have personally observed a team who did exactly that and it didn’t work out so well.  They begin putting things in the backlog like “Testing”... i.e. they began using the product backlog as a “task list” instead of a “change in the system” list.  They even put “Sprint Planning” on the product backlog and gave it an estimate!  They thought there was nothing incorrect about that.

However, I’m sure that it does work out well for some teams, so extraordinarily well that those teams’ feedback is incorporated into the next revision of the Scrum Guide.  For instance, we’re no longer required to do burndown charts—we can use any Sprint progress monitor that still fulfills the same criteria (now outlined as part of the Scrum Guide).

I don’t want to harp on the Scrum Guide too much here, as again, I think there is some personal discomfort for you on that subject in the many hats that you wear.

I appreciate your time and thoughtfulness in your replies, and most of all, I appreciate all of your contributions to the Scrum community.  This is my personal opinion here, but I think you and Ken are the best shepherds that Scrum has right now, and I’m thrilled that the two of you are heading these two orgs.  (I was very concerned with the SA in it’s previous… “iteration”)

Thanks, Charles. I appreciate your kind words. I have no discomfort with the Scrum Guide. I’ve read it. I was Ken’s editor on the first version. I just don’t hold it as some holy tablet. There are many people who can all teach us a great deal about how to successfully apply Scrum.

Ok, so if we agree that the Scrum Guide nor any other source is the holy tablet of Scrum… In essence, I think what you were saying in your original post was about being to “rules oriented” or doing it “by the book(or holy tablet)” for too long. 

How do we send the converse message to the people on the front lines in their orgs that, tinkering too much with “generally accepted Scrum” is something that should be done with a lot of care and caution, due to the possible big negative consequences of doing so? 

It just seems like to me (and based on my experiences) that the “try and it and retrospect” approach doesn’t really work well if you don’t have a “process wonk”(coach or other highly knowledgeable process person) on your team, because the lay person often doesn’t see the consequences of deviating from the generally accepted approach.

My comment:

> because the lay person often doesn’t see the consequences of deviating from the generally accepted approach.

(That lay person is often the newbie SM, who may think that deviating from “the book” is fine so long as you wait until Sprint 2 to do it)

Hi Charles—
I think a lot of ink has been spilled on the subject of “don’t deviate too much.” There are all the posts, blogs, webinars, etc on “Scrum But” (“We do Scrum, but we don’t have get anything potentially shippable at the end of our sprints,” etc.). I think those who will hear that message have plenty of opportunities to have heard it. Some people will not hear a message no matter how many times it is repeated.

I agree that much ink has been spilled on that topic, but your article above appears to describe that ink as non-credible.  Was that intended? Or am I interpreting your message incorrectly?

I mean, I think we want both, right?  We’d like people to be cautious when deviating, but we’d also like them to deviate in order to innovate and adapt.  I just find it very difficult to send both messages simultaneously AND do it in a way that is not leading the message receivers off of a cliff.  Maybe our focus should be on a “healthy balance.”  Too much deviation can be bad, but too much adherence to the rules can also be bad.

When considering deviations, I always return back to the 4 value statements and 12 principles of the Agile Manifesto, which is neither a PDF nor a blog or book, I might add.  :-)

I have a prediction.  Some people in the future(besides me) will now refer to your post(and minimal rules) above, as something akin to the “Mike Manifesto”.

You are interpreting me completely incorrectly—I have no intention of telling people “just go change what you want and call it Scrum still.” I’d hardly want this to be a Manifesto. We’ve got one and that’s enough. All I was trying to do in this post is make it clear that there are very few rules about being agile. There are principles to follow (as you suggest in reference to the Manifesto) but no guru, author, trainer, etc. gets to dictate what is best for a given company. That’s why most people in agile try to avoid the phrase “best practices.” There are good practices in given contexts but very little that is so far and away above other possible practices that they should be elevated to “best” with the implication everyone should do them.

Well, I don’t shy away from the term “Best Practice” because I think all humans understand that there is no such thing as a Best Practice in any industry that dictates what is best for a given company.  I also define “Best Practice” on my web site so that people understand what I mean when I say it.  The notion of a “Best Practice” in any industry or context is a Unicorn because there is no such thing.  IMO, it is not a term that should ever be taken literally because “Best” is in the eye of the beholder anyways, and I don’t think many people take it literally.

I do like your term of “Generally Accepted Scrum Practice”, and I also like that it somewhat parallels the similar term of Generally Accepted Accounting Principle in the Accounting industry.  Well done, there!

So, I do return to my question though…How do we communicate that there is some sort of “Goldilocks Balance” when implementing Scrum?  How do we as Scrum community leaders convey that message?  I submit to you that if we can figure out a way to do *that*, then all this ink being spilled on “feel free to break the rules” vs. “minimal rules, but the rest is recommendations” vs. “look to the rules first, and deviate carefully” vs. “stick to the holy tablet” will begin to decline in a major way.

Scrum is crossing the chasm or may have already, but until we as a community can figure out how to convey some *practical* “Goldilocks Balance” advice, I submit that the “rule wars” will continue.

Charles—At this point this is probably a discussion best continued in person. I’ll be at the Scrum Gathering in Atlanta and that’s a possibility for continuing it further.

Mike, I very much appreciate the offer to meet up at the Scrum Gathering, but my sense is that you’ll be busier than a bride on her wedding day there, so I’ll throw out a better option…

I live in Denver, just a short drive from where you live, so I’ll offer to come to your town and buy you lunch or dinner at the place of your choice.  I know you travel extensively, so you can name the date and time too… You have to come home eventually, right?? I know that you are married because I have met your wife at one of your presentations in Denver! (She can come to—tell her I’m buying!)  It’s the very least I can do for someone who has done so much for our industry as you have.  Maybe we can find a way to communicate the Goldilock’s Balance (and maybe we can find a better way of expressing/naming it than that!).

We’re connected on LinkedIn, so I just sent you my contact info.

Hi Charles—Thanks for the generous offer but on the rare occasions I am in Colorado (10 days between now and June 27; I just checked) I don’t schedule any work meetings so I can enjoy the time with my family. It’ll have to be at a conference. I am at the Scrum Gathering on Monday and Tuesday with absolutely nothing planned other than hanging around the hallways.

Mike,

My friend, I think we’re going to be two ships passing in the night on this one.  I already have 3 other conferences on my schedule this year, so the Scrum Gathering didn’t make my list of conferences to attend this year.  My hope in trying to come your direction was to make it as easy as possible on you, but I respect your desire to spend time with your family, as I have a similar policy that carves out time for my family.  It is indeed important, and much more important than Scrum.

I guess we’ll just have to keep crossing paths on the interwebs, and I will continue to look for ways to communicate the Goldilocks Balance, because it is one of the biggest impediments to Scrum success right now, in my opinion.  I see so many teams struggle with it.

Mike,

As I reflect on our conversation, a team I observed once comes to mind.  The team did most of the major Scrum things(Backlog Grooming, Sprints, Sprint Planning, Retros, Daily Scrum, Sprint Backlog, Burndown, even a Release Burndown, fair amount of self organization,etc) but they never did Sprint reviews.  They never even attempted them, and they knew both the purpose of them and that they were a Scrum “staple.”  They were a component team, so I’m sure they solicited feedback in a very very informal and infrequent way, and I know they would have “heard about it” if something they delivered wasn’t cool with the component users or other stakeholders.

My question is this. In your view, were they doing Scrum?

If we assume they were getting the feedback they needed yes. If I were coaching them and they were getting all the needed feedback in an informal way (e.g., they just happened to talk enough to their users and customers that they got this feedback) I would encourage them to formalize the acquisition of that feedback. I don’t mean a meeting (sprint review meeting) but I do mean putting into their sprint backlog specific tasks of “run this by users.” Those meetings can be informal but it should be formally planned (by a task or just by team discussion that ‘we always do this’).

Interesting advice Mike, and it’s helpful too, as I never would have thought about the sprint backlog idea that you mentioned. 

This was one of those weird cases where they were not doing the ritual, but they did somehow seem to get at least the minimum of what the ritual provides in another format.  I mean, I think they would have gotten more out of something more formal (but still fairly informal - sprint review 30 minutes or less each sprint), but they did seem to get the minimum of what they needed (from a Scrum perspective) from what they were doing.

This is why it’s so hard to nail down/codify that Goldilocks balance thing—corner cases like this.  It’s all about context I guess.

“That lay person is often the newbie SM, who may think that deviating from the book is fine so long as you wait until Sprint 2 to do it”

How else does he keep his job and survive these monsters? http://www.mountaingoatsoftware.com/blog/please-help-me-list-the-problems-with-using-agile-or-scrum