Sunday, November 11, 2012

Hard-Core Scrum, Common Scrum and Scrum (continued)

Since I published Scrum, Scrum and Scrum on this blog last week the piece has received a lot of attention and I’ve had a lot of feedback: comments on the blog, comments on Twitter and comments to me in person at Oredev last week.

On the whole these comments have been in agreement. My impression is that people find the posting a useful distinction between Synonym-Scrum, Hard-Core-Scrum (or ScrumTM as I’ve also called it) and Scrum-Lite (or Common-Scrum as it might better be called). In this blog entry I’d like to clear a few things up and reply to one particular comment from Kurt Häusler which I think deserves more attention.

Just to be clear: I’m not attacking Scrum here. I’m discussing difference in how it is perceived, what people call Scrum, and where I think “Scrum” is inconsistent (OK, that might be criticism.)

First terminology.

In using the term ScrumTM I am being sarcastic. Nobody owns a trade-mark on Scrum, anyone can use the term Scrum and the ideas in it. So lets stick with Hard-Core Scrum.

Scrum-Lite also seems to upset people, this name was meant to designate a form of Scrum which is not Hard-Core-Scrum. Lets use the term Common-Scrum because this is the way I most typically see the Scrum ideas implemented.

Next the issue of Project Managers, and to a lesser degree Architects and other specific roles on Scrum. Kurt wrote:

‘Anyway, anyone saying project managers and architects are not allowed in Scrum is simply wrong. Are they really saying that though? And are people saying that really representing a different meaning of the term "Scrum”?’

Taking it in reverse order: I am the one who says there are two-forms of Scrum. I think this makes a useful distinction which helps me, and I think others, understand the world we live in.

Kurt’s first question is the more interesting one, if the answer was “No”, if the world did have a homogenous view of what Scrum is the second question, and the distinction would be unnecessary.

So Kurt, the answer to the first question is a most definite Yes. I think the point is well made by Christin Gorman in her 10 minute video on Vimeo from the Roots conference - “Putting an architect in a Scrum team is like putting mayonnaise in a cake.”

Let me say straight away I’m not picking on Christin here, I actually agree with much of what she says and she is not alone in this view. There are other - better known - names who say the same thing:

  • In The Scrum Primer Deemer, Benefield and Larman say “there is no role of project manager in Scrum.” These words are in version 1.1, there is a Version 2.0 on the Scrum Foundation website which adds Bas Vodde to the author list and contains the same words. I haven’t read v2 in detail so maybe in contains more advice for project managers.
  • The Scrum Handbook on Jeff Sutherland’s website contains the same words - in fact the biggest difference to The Scrum Primer seems to be the author list.
  • I personally heard, several years ago, Craig Larman answer the question “What does a project manager do in Scrum?” by saying “If you have a project manager in a Scrum Team you are not doing Scrum.”
The important point is: Christin understands Scrum to mean “No project managers” and Kurt understands Scrum to allow project managers.

I sympathise deeply Christin’s point at the end of the video, if I may paraphrase: “lets save Scrum to mean what it was meant to mean”. I just happen to think this particular cat is out of the bag. Rather than trying to “save” or “reclaim” the name “Scrum” I prefer to differentiate.

Interestingly, as I have commented before (“When did Scrum start loving project managers?”) Ken Schwaber hasn’t always shared this point of view:

  • In Agile Software Development with Scrum Schwaber says “The Scrum Master is a new management role introduced by Scrum” and a little later “The team leader, project leader or project manager often assume the Scrum Master role.”
  • In Agile Project Management with Scrum Schwaber says “The Scrum Master fills the position normally occupied by the project manager. I’ve taken the liberty of redefining the role.”
Now perhaps I’m guilty of not checking my facts. I haven’t e-mailed any of these people to ask where they stand on Project Managers and perhaps I should have. (If any of you are reading this please feel free to comment.)

However, I don’t believe a definitive statement would make much difference. What if I had a statement from one of these people saying “Project Managers are in” (or out) ? There would still be people out there interpreting Scrum the other way. It is too late to change this now.

Personally I believe that overtime those who define what Scrum is - those named here plus a wider community - have changed their position on Project Managers. I suspect that in the beginning there was no anti-Project Manager bias. Then is crept in, and now it is less, or perhaps gone altogether.

The points I want to make are:

  • there is are different understandings of what Scrum is
  • I, and I think others people, find it useful to make a distinction
I really don’t care if you want to say “Common Scrum is not Scrum because…” or “Hard-Core Scrum because…” is not Scrum, because I’m not describing what should be, or not be. What I am describing here is how I find the world.

Comments please?


  1. Hi Allan,

    which category of Scrum do you put the Scrum described in the Scrum Guide under? I probably should have asked that in the previous comment. The Scrum Guide is what I use as the definition for what is and isn't Scrum, so for me it is simple.

    I think it just comes down to an issue of precision. There is a huge difference between saying "having a project manager on a Scrum team is a bad idea" or “there is no role of project manager in Scrum” and saying "The Scrum expressly forbids having project managers on the Scrum team".

    The first statement is an opinion, and one that generally conforms with the spirit of Scrum, but lies outside the scope of what Scrum itself directly has an opinion on. The second statement is true, and the third one is false.

    "Kurt understands Scrum to allow project managers." - Well it doesn't explicitly allow them. It only implicitly allows them by refraining from explicitly forbidding them. There is a subtle difference there that is at the heart of my issues with your blog posts.

    I don't think Scrum has ever really loved project managers.

    Ah I see. You want to know if they are absolutely in or out. Well Scrum doesn't play that game, any more than it says pair programming is in or out, or story points, or UML, or index cards or anything.

    Look you should read the Scrum Guide. It does not mention anything about project managers. It does not say they are a part of Scrum. It does not forbid them from being involved with a Scrum team.

    However it may not be completely neutral on the issue, depending on what we mean by projects, what we mean my manager, and what the role is actually expected to do in the context of Scrum.

    Generally the 3 roles in Scrum are defined in such a way that no project manager is necessary.

    I have seen some situations where a PM is outside the team, employing traditional project management across the wider value stream, leaving Scrum to cover just the software development bit in the middle. Sometimes this worked well (when Scrum was allowed to do its thing), sometime it didn't (when the PM didn't realize that Scrum replaces aspects of traditional planning etc.).

    I have also seen some situations where aspects, e.g. financial aspects were not able to be performed by any of the people assigned to the 3 Scrum roles, so a PM was employed to do it. It wasn't really classical project management though. Project planning etc was done with Scrum.

    There is a lot of subtleties here, but to try and identify different types of Scrum based on something so arbitrary as to how anti-PM people are just seems absurd, and not useful.

  2. Kurt, some people get really emotional about Project Managers and Scrum - did you watch Christin's video? - to them it is not arbitrary.

    To me the distinction isn't important, I'm concerned with what works. Sometimes a project manager is useful, sometimes a project manager gets in the way. There are questions of team size, contract arrangement, personalities, aptitudes and a lot more to be considered.

    May basic point is: I find it useful when someone says "Scrum" to enquire more deeply into what they actually mean. In general they fall into these three categories.

    Perhaps we are making more out of this than is really required.

  3. I just watched it last night. She didn't say Scrum forbids architects or managers, which would be a falsehood presented as fact, she just said she doesn't think they belong which is a perfectly valid, non-controversial, and sensible opinion.

    I suspect most people share this opinion. I know I do more or less. (There were a couple of points she made about self organizing teams or "crap" teams or something that I would need to clarify before determining if I agree or not).

    Maybe the confusion arises because in the traditional world methods and processes are more fully defined, and everything you need is listed and everything you don't need is listed and if you deviate you are not doing the process. Scrum is just a framework. It does not have any role called project manager or architect. Having a PM on a Scrum team is probably, except in certain circumstances a bad idea. Scrum does not forbid having them.

    There is no confusion there. Scrum in general has this anti-PM bias, but it is not enshrined in the definition of Scrum as a forbidden element.

    Any "type" of Scrum that claims that PMs are banned by Scrum is no Scrum at all. Any "type" of Scrum that says PMs are required by Scrum is no Scrum at all.

    One could argue the extent to which in a specific case a PM might be suitable or sensible, but that has nothing to do with Scrum itself, and it certainly doesn't indicate different types of Scrum.

    Have you read the Scrum Guide? It is not that complicated.

    Just remember, just because something isn't explicitly banned, doesn't mean it is a stupid idea. And when someone says "such and such doesn't belong" or "such and such is a terrible idea", they are expressing an opinion, not necessarily attempting to state some objective fact about how something is defined, nor are they likely to be attempting to redefine something.

  4. I like the way you try to put some names on phenomenon you have observed - thanks for sharing those, and I think especially "Hard-core Scrum" and "Common-Scrum" are useful phrases.

    On the "Project Manager or not" discussion I would like to add that there is a distinction between the role (as defined), the skill-set, and the person.

    Obviously, the role dwindles as Team, Scrum Master, and Product Owner take on parts of the responsibilities classically defined with the Project Manager.

    The skill-sets of project managers are definitely very valid in Scrum. Some of those skills are exercised by the Team, some by the Scrum Master, and some by the Product Owner. Yet, some skill-sets will dwindle, like how to compile time-sheet to resource-consumption-vs-budget-reports.

    Finally, some people (ex-project-managers) will not find it comfortable to work in an agile-type environment - whereas some will thrive in it. Actually, the best project managers I have met would in Scrum serve best as Product Owners. [I have earlier elaborated on this in a blog post: ]

  5. Intersting to me is that nobody really has a look at the project management aspect. Who initializes or ends a project like it is defined e.g. in ICB/IPMA? There are aspects in doing a project that are not defined in scrum master or product owner role (and for sure not in the developer team role) but that have to be done. In single teams this may be is not a big problem ( a lot of those can be done on department level). But in multi team contexts this is. One thing seems to be pretty clear: if we have a project manager it has to have an agile mindset and is focussed (e.g. no micro management).

  6. Rainwebs,
    You make a good point. The start and end of projects really are poorly understood. Capers Jones says in "Applied Software Metrics" that finding the end date of a project is difficult but finding a true start date is one of the most difficult pieces of information to obtain!

    Scrum, Prince2 and just about every method I've looked at fudge it. There is an assumption that something has happened before but little about what that is. Trouble is, to relax that assumption you have to extend the method back in time.

    This is something I've been meaning to write about for some time, maybe your comments will push me along!



Note: only a member of this blog may post a comment.