Or…when I waded into age-old debates, and made no substantive contribution. Fail fast, I guess.

Note: While reading this post, please keep the following Scrum Guide quote in mind. You’ll understood why it is important soon.

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.OK. Let’s jump right in. First, I am going to cover some common implementation paths for Agile ways (including Scrum) using a funny diagram. And then I am going to talk about Scrum.

Descent From Mount Scrum

Here is a team that started with “Scrum exactly by the book” (the Scrum Guide, at least), but things don’t really improve. Over time they start to triage roles, rituals, and artifacts because they don’t seem to make sense. There could be many problems at play here, but basically things stall. They started by doing Scrum, but aren’t doing Scrum now.

#### Crap Shipped Fast Is Crap (Even When the PO Approves It)

Aka: Fast is table-stakes.

Here’s another pattern. This is the dream Scrum implementation. It’s 2x the work in 0.5x the time, with one small problem. The UX and Product craft isn’t up to snuff. They’re shipping crap no one wants. Fit for purpose improves slightly, but not as much as you might expect. By the way, this is official Scrum (remember the quote).

Kanban Method

In this example, we see the dream Kanban Method implementation. The team starts “where they are now”, and steadily improves…drawing from practices/tools when they make sense (including from Scrum). Of course this can stall for various reasons as well. This is NOT SCRUM.

Technical Practices Matter

One thing I’m reasonably sure of, is that this scenario will never get you far. The technical practices are essential. In fact, your speed will become your Achilles heel as features and complexity pile up. This is Scrum.

Legally Scrum

This would be considered Scrum (despite the poor improvements). Why? The team is has adopted the roles, events, artifacts, and rules. Therefore, this is Scrum.

#### Works Great (Not Scrum)

And this would NOT be Scrum (per the quote above):

Apparently there is something called Aggressive Scrum (or “True Scrum”) out there now, but I don’t know much about it other than the hunch that Jeff Sutherland coined it

. Side note, I think most of the people in that cycling photo turned out to be dopers, but I digress.

I’m not going to bore you with yet another chart. You can guess how this might look.

OK. So what?

None of the takeaways below are all that original. That I find them still relevant is disturbing.

First, Scrum needs to come with a warning label:

This is REALLY hard. You will spend years as an organization trying to master this. It will require a wholesale shift of thinking in your organization. Going through the motions is not enough. Two day certifications are not enough. Scrum can be weaponized. You will need to draw from many, many other practices to make this work. Adopting potentially new technical practices is a prerequisite. Be prepared to clear the blockers that plague multiple teams. Do not simply graft this onto your current project culture. Etc.Second, “Scrum is not enough” (from the way back machine care of Mike Cohn circa 2010):

Again, none of this is new. Go back and check out this video by Uncle Bob in 2011 to hear about Fowler’s Flacid Scrum and Scrum without technical practices resembling a tractor pull

.

To the Scrum Community … you have to make Scrum more usable for the general public. You think it is easy, but the messages the Scrum community sends are often conflicting:

It is 2017, and you have to make some decisions to future-proof your way. I fully understand the rationale of an “open” framework, but you need to realize that what you consider an open framework, does not feel terribly open in 2017. In 2009 it felt like this to Tobias Mayer:

It consists of a few core rules and practices, which although very simple are utterly essential. Each rule and practice is part of a synergistic whole, and to drop one part is to destroy that synergy. Half measures avail nothing. When the rules of Scrum are rigorously followed a process will emerge that is suited to your own context.And…

What Scrum can give you is a space to be human, to try, to fail, to reflect and to try again. Putting the simple Scrum framework in place at your organization will be the first step towards creating an environment of safety and trust, an environment of empowerment and ultimately of innovation and success.Wow. That sounds amazing. It makes perfect sense why folks like Tobias can be so passionate these days when someone criticizes Scrum for being mechanistic, damaging, or inflexible.

But perhaps both sides are right. Tobias was part of the original, hopeful, and empowering era of Scrum. And people experiencing Scrum today are more likely to be experiencing the Scrum Industrial Complex. The good stuff still happens. But sadly, due to the numbers game I guess (and that organizations adopting Scrum for the first now are late adopters), the good stuff happens in a small percentage of situations.

Datapoint: the “kids” these days are much more leery about all the rituals, rules, roles, and “accumulated baggage” (things that aren’t prescribed Scrum, but seem to come along for the ride).

I’m sure they’d feel different if Tobias made the introduction (or any of the amazingly skilled folks I know who are CSTs and Scrum Masters). But they didn’t. The biggest Scrum defenders I know are the sage first guard.

Another example from my little bubble: In a year of talking to ~100 product managers in a biased sample of startup SaaS companies, few of them considered themselves as doing the “product owner” role, and few of them worked with Scrum Masters. Most teams had partially adopted Scrum and Agile practices. And most were struggling with issues like DevOps, continuous delivery, fully incorporating/embedding UX, Data Science, experimentation, Lean Startup, etc. This is admittedly not the mainstream, but it will be eventually.

Other experiences. This year I followed the 2017 DevOps Enterprise Summit, and it was amazing. I especially loved the CTOs of F100 companies getting up there and talking about meaningful change in highly complex environments. The culture talks were great as well. But most inspiring was seeing the front-line folks in attendance (not coaches, not insiders) Tweet their learnings enthusiastically. I sensed that incredible energy you feel when developers see a way to contribute to the bottom line of the business, while also getting super excited about their craft. Side note: I loved Jez Humble tweeting about XP.

Does Scrum generate that energy? Does SaFE? Does the “scaled Agile track” at AgileConf do that? Or…

Anyway. Back to Scrum. When I go to the Scrum Alliance, the key call to action is to buy a course:

Behold, what’s above the fold here:

More courses.

Hmmmm.

In closing, the Scrum community needs to figure out what it really wants to be, how it wants to design its services/framework, and who it wants to treat as its customers/users. Is “Scrum not enough”? Are your customers the Scrum Masters and their Trainers, or the teams they service? What does self service look like? I know the resources are there, but it isn’t front and center.

Should you be more directive and prescriptive when it comes to linking to important non-Scrum tools/practices? How about warning labels? How do you maintain the quality of your service to your customers/users? How do you bridge to other area of craft that can be beneficial to users of Scrum (as Cohn alluded to above)? How should you spend your money?

How do you capture that energy and excitement Tobias alluded to in 2009?

It’s kind of up to you. This is not an Anti-Scrum post. Just a bit of an outsiders perspective that may / may not / probably isn’t all that helpful.