S. King is an Agilist? ;-)

"The scariest moment is always just before you start. After that, things can only get better."
Stephen King

This can be easily seen as an aphoristic formulation of one of the principles advocated by Agile: before you start, you may fear that your massive upfront planning will go wrong; after you start, just make sure to inspect and adapt...

On methodologies' being two-dimensional

Agile Manifesto signatories' reunion to celebrate its 10th anniversary was... Educational?
It was encouraging to hear them saying that they won;t change anything in the Manifesto, 10 years later.
Not too many cultural artifacts can boast of retaining their relevance for so long.

But it was even more thought-provoking to hear what they think we've done wrong during these years.
And for me, one of the most important lessons was that the Agile methodologies like Scrum or Kanban define rhythms and processes, but not craftsmanship techniques.
That is to say, the team may have backlogs, sprints and reviews, as mandated by Scrum definitions - but they'll never be truly Agile, nor will they be professional craftsmen if they don't follow the XP techniques (CI, TDD, clean code).

So, my tiny epiphany on this subject was that these parameters (methodology and techniques) are orthogonal.
Next time I'm asked what is it we're doing, my answer will be: Scrumban with XP.

Individuals and interactions over processes and tools

"Individuals and interactions over processes and tools"

This is the first principle of the Agile Manifesto. And very justifiably so.
Every Agile adept will readily and undoubtedly quote this principle, even being woken up at the wee hours of the night.
This is our "2+2".
And yet... Somehow the industry fails to make the "4" out of it, or at least to call it by its name.
We're still bogged down in endless discussions on... yes, our tools and processes. Even though these tools are to support Scrum, and the processes are very Agile. And that is OK, these discussions are needed. But not only these discussions.

My point?

Management of Agile craftsmanship is neither about methodology, nor about - God forbid! - technology.
It is about psychology!

All (well, just for not to fall into the sin of generalization, most of) the Agile coaches, ScrumMasters et al come from the Software Engineering background; whether programming, or project management - not so important. The important thing being that they, naturally, possess a vast knowledge of tools; and processes too, of course, let's not forget the processes.

But one would ask: what background should they be coming from to be more knowledgeable about individuals and interactions?
Why, isn't this obvious? Psychology; social sciences. These are the disciplines that teach us how to understand and modify human behavior. And among the rest - touché! - individuals and interactions.

I would risk to suggest that the most successful and revered Agile coaches and gurus actually are spontaneous, elemental psychologists, with either inborn psychological abilities, or accumulated lifetime experience.

So, I wonder when we will see first ScrumMasters with PhD in psychology???

Should we apologize for Scrumbut?

Important disclaimer: all the aforementioned applies, of course, only to the cases where the core Agile principles are preserved, honed and cherished. I am by no means advocating getting rid of "inconvenient" core values just because you were unable to make them work.

I can't help but get the impression that the term "Scrumbut" (or "Scrum-but") is mostly used in derogatory sense.

There is a certain aura of "bad smell" when someone is pointed out that their Scrum implementation - or what they so far naively considered to be a one - actually is a "Scrumbut". A filthy half-blood. A mildly contagious poor neighbor with some not so decent bacterial disease. Not to be completely ignored, but to be talked down to, from a safe distance.
"Ah, this is not Scrum, what you're doing. It's Scrumbut!" (= "Get your ways right, and then come back to talk to me")

As a discerning reader would probably have realized by now, I am not a big fan - to say the least - of such an approach.
You see, Agile is all about... Being agile. How shocking, eh?
However beautiful is the concept one is a captive of - he's still a captive.
If you build high fences of dogma (others would say - an ivory tower) around your practice, and wouldn't allow anyone to cross outside - this is not Agile. This is anti-Agile. Even if inside that guarded perimeter you'll find a perfect implementation of purest of Scrums.

Any Agile methodology - be it Scrum, or any of its countless, nameless, and shameless(!) modifications - should be a living being. Constantly changing through retrospective and adaptation.
Because no two organizations, products, projects - or even the same project at two points in time! - are the same. Each one is unique, and the admirable power of Agile is in its ability to adopt to these real, unique needs.
No "one size fits all", no silver bullets. Take the core principles, live by them, and build your own methodology. Just try not to get too attached to it, as you'll have to change it again very soon :-)

Hence I would say: be proud to carry "Scrumbut" on your banners! And beware of anyone clinging to "the pure Scrum".