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.

ScrumMaster Project Manager = oxymoron?

Recently I stumbled a few times across job ads asking for "ScrumMaster Project Manager", or something along these lines.
I have to admit, this combination sounds inherently controversial to me.

In my view, there is quite a clear conflict of interests between the two.

The PM is expected to put the project's interests first and foremost, and push to the quickest possible delivery of as many product features as can be delivered. PMs also would often operate under some deadlines / milestones dictated by the business, and as a result will have to push towards getting a certain feature set completed by a specific date.

The SM, on the other hand, should put the team's interests to the top of his/her priorities, while actively shielding the team members from any external pressure, and allowing them to operate in "clean environment", so that they can fully utilize their ability to professionally deliver products, without compromising on the quality and the definition of done just to meet some deadlines (that ideally should not even be in a Scrum team's lexicon).
Among the rest, this means that the team of professional Agile craftsmen should be able to push back on any such pressure, and SM should be their bullhorn for that.

So, are these 2 extremes really expected to be balanced by a single person? Can they? Should they?

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".

Uncle Bob's precious piece of wisdom

http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot
...
How do you keep a Scrum Team from losing productivity?  

How do you make sure that hyper-productivity doesn’t veer headlong into a quagmire?  

You make sure that the team is not hyper-productively making a mess! 

You make sure they are practicing the disciplines that produce data that can be measured. 

You use that data to measure the quality of the code they are producing; and you provide incentives for keeping that code clean.

Having fun? That's a must-have! ;-)

Harry Long has raised a question of whether anyone has fun when working with a Scrum team (here; LinkedIn "Scrum Practitioners" group membership is needed to see the page). Few thoughts on the subject...

I believe having fun is one of the cornerstones of a successful Scrum implementation.
So, I'd go ahead and say: "Scrum team MUST have fun". Oh, wait... I would even go further and say that this should be added to the official Scrum Guide!

With the way Scrum expects people to interact all day long, make collective decisions, and take the collective ownership over the product - it's an absolute must for the team to become THE TEAM ;-)
And that is hardly possible without having fun together...

IMO, not every developer can be a Scrum developer, and not every team may be turned into a successful Scrum team. Not because of lacking some technical knowledge. And not even because of the willingness (or lack thereof) to adopt the methodology. It's just about the personalities involved...
If a person is an introvert, aloof, unsociable human being - she/he may be an excellent developer delivering top-of-the-notch code... But probably not as a part of a Scrum team :-)
I would even state that I'd prefer hiring a person that will fit well socially into the team while lacking some acquirable technical skills, to hiring a misanthrope guru! ;-)