Short Story:

When teams struggle with Scrum, it is my strong opinion that they should look *first* to the Scrum Guide for guidance.
(Or *look back* to the Scrum Guide, if they are an experienced team)

Long story:

A more complete way of saying this is:
When teams struggle(whether they be beginner or experienced), it is my strong opinion that they should look *first* to the Scrum Guide, and secondarily to other resources (books, articles, online, other professionals) for help. In fact, read and learn as much as you can from the Scrum Guide and the secondary resources. So long as those other resources don’t contradict the Scrum Guide, then it’s probably ok to try what they suggest. If those other resources do contradict the Scrum Guide, then think long and hard before deviating.

I have observed the following Anti-Patterns with respect to Scrum implementation.

Faux Scrum: Disinformed or Misinformed
1. Someone advocates a practice that is not consistent with the Scrum Guide.
2. The team struggles with that “something, ” often times because the “something” is not really Scrum at all, but some practice that someone inaccurately said was Scrum.
3. Rinse and Repeat until either:
a) “Scrum” is a dirty word in your organization, or b) your organization settles for mediocrity, or c) you decide to move on to some other process, or d) until someone figures out what you are doing is way out of line with the Scrum Guide vision, and tries to help you get back to basics.

Faux Scrum: Give up quickly and Deviate from the Scrum Guide
1. A team struggles mildly with implementing some practice described in the Scrum Guide.
2. Rather than retrospect and improve their implementation of the practice as the Scrum Guide would suggest, they choose a different practice that deviates from the Scrum Guide, usually with negative consequences that that team may or may not have the ability to immediately see.
3. See step 3 above.

Faux Scrum: Pretend you’re doing Scrum
1. Pretend to be doing Scrum, but instead use a bunch of your existing practices instead of what the Scrum Guide suggests. “Hey look, Mom! We’re Agile!”
2. Rename a lot of your old practices, artifacts, and roles with Scrum terms. Proceed as usual with the status quo and tell everyone in your company how Agile or how Scrummy you are.
3. See step 3 above.
(Ken Schwaber calls this the “Methodology Facade Pattern”)

Faux Scrum: Selective Scrum
1. Like you did successfully with WaterRUP processes, selectively pick a small number of Scrum practices and implement those only.
2. Enjoy the new practices, but be sure you stop progressing towards the Scrum Guide vision either because you get too complacent or too busy.
3. see step 3 above

The Power of Positive Thinking
I know what you’re thinking. Man, this guy is negative! If you spoke to people in my personal or work life, I think they would tell you that I’m generally a very positive person. I’m even hilarious at times, but that’s hard to convey in prose about intellectual topics. I think, though, that they would also tell you I’m a very detailed person, and that I’m honest and direct about serious subjects.

So, rather than call everyone “Chickens” and “Scrumbuts” and “Faux Scrumites”, what I do instead is I advocate a positive strategy.That positive strategy is : When deciding how to proceed with Scrum, look to the Scrum Guide *first*.

If you look at my blog and web site, I generally give positive advice, but I also don’t shy away from Worst Practices, Anti-Patterns, Bad Smells, and Traps. Any good tester tests happy, sad, and bad paths, usually with particular attention to the sad and bad paths. I do the same. I also make sure that I propose solutions to all of these Worst Practices, Anti-Patterns, Bad Smells, and Traps. I do want to help, but sometimes people are not Scrum knowledgeable enough to recognize the bad practices.

Sometimes, to convince people to get back to basics, I have to point out where they’ve deviated from the Scrum Guide. This usually involves quoting the Scrum Guide. Yet other times, to further convince people to get back to basics, I have to express some of the possible advantages and disadvantages of their current strategy. That’s part of being a Scrum Coach and change agent, and comes with a certain amount of resistance. I’m ok with that. The reason I’m ok with that resistance is that I do it because I passionately and honestly believe it’s the right thing to do.

My position is a little more nuanced than you suggest. My intent in this article was not really to advocate a strong always “by the book” strategy. My intention, and maybe it is not conveyed well enough, is to advocate more of a “when teams struggle, look to the Scrum Guide first, and then other outside sources.” To me, that is a best practice, meaning it is probably superior to any other practice.

For instance, another practice would be, “When teams struggle with Scrum, they should retrospect on it and decide what to do.” Or said another way, (“People should just make their own decisions without doing any real research on how to proceed with Scrum.”) While that’s an ok practice, retrospectives are meant to optimize *within* the Scrum framework, not to revise *the* Scrum framework. Teams that struggle often do the latter when they shouldn’t. As such, to me, the “retrospect” practice is an inferior practice to the best practice I describe in this article.

And yes, I’m referring to the Scrum Guide posted at Scrum.org. If you click on the “Scrum Guide” link in the article, that is where it will take you.

Thanks for the comments. I may be fighting an uphill battle since you’ve already decided that you’re not a fan of Scrum, but I’ll bite and try anyways.
“1)….Nothing in the scrum book will tell you how to fix those problem”
One solution posited by the Scrum Guide here is retrospectives. That may not be the best solution, but the Scrum Guide does propose a solution here.

“2)…Why do they have to wait til the end of a sprint to retrospect?”
I do not believe there is anything in the Scrum Guide about requiring a team to wait until the end of the Sprint to retrospect.

“3)…To me scrum is geared at relatively low level developers who don’t communicate with each other,”
I respect your opinion, and in a weird way, you hit on one of Scrum’s greatest strengths — it strongly encourages communication. Our industry is one that is plagued with a lack of communication, and it is generally seen that, in our industry, as in life, good communication can solve a lot of problems and improve efficiency.

“Would it not be more efficient overall to just hire a few senior developers, and get rid of all this overhead?”
It would, if that really solves the problem. However, my friend, I’ve been in this industry for some 14 years now, and believe me, hiring a bunch of senior developers doesn’t come any where close to solving all of these problems. I know very senior developers, for instance, who are horrible communicators. Having said that, the best senior developers I know are excellent communicators.

“At a minimum scrum has 15% and more like 25% overhead for the entire team.”
I think the amount of overhead is irrelevant. What *is* relevant, IMO, is the ROI of the Scrum overhead.

“Where in the guide does it address the issues raised above?”
I believe I’ve answered that above, and I’ll leave you with one more hint from the Scrum Guide.

“The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them while providing a framework within which complex products can be developed.”

Regarding retrospectives, the Scrum Guide (p 14) says: “After the Sprint Review and prior to the next Sprint Planning meeting,
the Scrum Team has a Sprint Retrospective meeting. This is a three
hour, time-boxed meeting for monthly Sprints (allocate proportionately
less of the total Sprint length to this meeting). At this meeting, the
ScrumMaster encourages the Scrum Team to revise, within the Scrum
process framework and practices, its development process to make it
more effective and enjoyable for the next Sprint. Many books
document techniques that are helpful to use in Retrospectives”

So, clearly they say it is at the END of the sprint, not more often. And you are suggesting a “by the book” implementation.

Interestingly they say that you cannot retrospect about SCRUM ITSELF….one can only retrospect into how to make your team fit into the scrum process.

On communication: Type and Quantity are no substitute for quality. Additionally the amount of communication truly necessary is not near the amount Scrum requires. Scrum requires so much communication because they don’t plan adequately and rely on verbal in person communication.

On ROI:

Of course the overhead matters.

If scrum has 20% overheard, one would need a 25% ROI JUST TO BREAK EVEN! (.8*1.25=1.0).

Where is the evidence that Scrum regularly returns and ROI greater than 25%? It is 20 years old at this point and no such (non biased, credible) evidence exists.

On surfacing dysfunctions: from one of my blog postings:
“4) People want to use Scrum/etc to help their product execution issues; saying that they have to “solve all their organizational problems” seems like bait and switch. The customer wants a tool and they are selling a self-help program, except, the things you need self-help on, they don’t even address. You have to do that (all important) part yourself, with essentially zero guidance.

5) Scrum itself gives no guidance on how such dysfunction should be eradicated, how long it will take, or what it will cost. Therefore organizations are being asked to leap into the unknown, based merely on faith, when even the Scrum “framework” itself covers no mechanism to solve the dysfunctions that are “surfaced” by Scrum.”

> So, clearly they say it is at the END of the sprint, not more often.

There is still no rule in the Scrum Guide that says one must not retrospect at any time other than Sprint end. For instance, a team could retrospect every day if they wanted to, without violating the Scrum Guide, so long as they also have a retrospective at the end of the Sprint as the guide describes.

> And you are suggesting a “by the book” implementation.

I’ve already stated once in this thread that I’m not suggesting a “by the book” implementation. Please see the previous comment where I explained that.

> On communication: Type and Quantity are no substitute for quality.

Agreed. I want to caution you here again on your reading of the Scrum Guide. It seems as if you’re reading the Scrum Guide to say… the team must communicate at the Sprint Planning Meeting, Daily Scrum, Retrospective, etc….and at no other time are they allowed to communicate. That’s a big logical leap you’re making there, and I would argue that is an inference you’re drawing that is not supported by the facts. I would also argue that one can read just about any Scrum book by Ken Schwaber and he will illustrate that members speak often outside of Scrum ceremony meetings.

> If scrum has 20% overheard, one would need a 25% ROI JUST TO BREAK EVEN! (.8*1.25=1.0).

I agree. There’s a ton of money to be made in software, though, so no big deal there. Also, all software development incurs overhead of the type you speak of, so again, the amount of overhead by itself is irrelevant. If you want to talk profits, then ROI is a valid comparison. You might also consider the so called overhead in other software approaches as well. Is Scrum really that much more? I also question the use of the term overhead when it comes to “knowledge work.” I’m not sure it’s an appropriate fit. Here’s one definition of overhead from an investor website:
“The ongoing administrative expenses of a business which cannot be attributed to any specific business activity, but are still necessary for the business to function. Examples include rent, utilities, and insurance.”

> Where is the evidence that Scrum regularly returns and ROI greater than 25%? It is 20 years old at this point and no such (non biased, credible) evidence exists.

Where is the evidence that any other software development process returns an ROI greater than 25%? I’ve heard Facebook uses Scrum. Surely they have an ROI on their software process costs of at least 25%. 🙂

> the things you need self-help on, they don’t even address. You have to do that (all important) part yourself, with essentially zero guidance.

Agreed. Scrum gives no direct guidance that I can think of here. OTOH, Scrum does not promise to give you guidance on it or solve those kind of problems. I don’t see the what your objection is here. Just because these “People” want something that is not solved by Scrum, is not Scrum’s fault. It might be the fault of whoever tells them that Scrum will solve all of their organization problems. I would also direct you to the bolded quote from my previous comment about what Scrum *does* try to do. Notice the word *you* in it.

> In these posts I bring out the implications of what is suggested by scrum and how they are NOT addressed by the scrum guide, even though they clearly should be.

Again, I think you are trying to say that Scrum should solve something that it clearly does not attempt to solve. I’d suggest you try to find a guide or book that helps to solve the problems you seek to have solved, instead of saying that Scrum should solve all of the problems that *you* say it should solve, or that some nebulous *they* say it should solve.

Prescribing a 3 hour meeting between specific events is overly prescriptive. You want a framework that the team calls it own, while keeping the principles and values intact. The Scrum Guide can serve as great training wheels to get you going, but to be truly agile, you must remove those training wheels as the team evolves and its own framework emerges from a self directed team. The Scrum Guide is valuable, but, should not be a hard constraint to adaptation. Patientkeeper, probably the 1st organization grown from Scrum the ground up, has transcended above the prescriptions of the Scrum Guide into a “self-actualized” agile organization (they have a true agile retro, which I infer is a continuous, so, their Reto meeting is 0 minutes. See Jeff Sutherland’s Google Talk “Self-Organization: The Secret Sauce” for Improving your Scrum team http://www.youtube.com/watch?v=M1q6b9JI2Wc
Great post and I appreciate the positive approach compared to the Scrumbut haters : )

The Scrum Guide does not prescribe a 3 hour meeting. It prescribes that a meeting/event occurs, that it achieves certain goals, and that it be held within a time-box (I’m not sure which event you were speaking of).

I’ve heard this “Use the Scrum Guide as training wheels” theory before, but, based on my experiences and knowledge of Scrum and “Agile” teams “in the field,” I do not believe it to be good advice for the large majority of Scrum teams out there. Most teams that try to roll their own Agile (whether they use the SG initially or not) eventually fail at being Agile at all. IMO, a team can only be very successful rolling their own Agile if they have an Agile process expert(Scrum Coach, etc) supervising them pretty closely and continuously. Some organizations have that kind of infrastructure, but the vast majority of them do not.

I’ve also heard the “transcend beyond Scrum” theory before as well over the years. Again, I generally don’t buy it. This is not to say that I believe it is impossible, because I do believe it is possible, but only for a very tiny percentage of teams. I have yet to actually see any credible case studies of teams that have done that, beyond teams that spawned truly Agile approaches such as XP, Crystal, etc.

In summary, let’s keep in mind my advice, which is NOT to always adhere to the Scrum Guide… My advice is, when a team is struggling, they should look first to the Scrum Guide, and only then to other sources (including themselves). I would probably even encourage people, when they do deviate from the Scrum framework, to run their deviation through the Agile Manifesto and Principles, to see if their deviation really survives the test of Agile merit.