I’ve come to believe there are three different meanings of the term “Scrum” - well, three inside the software development community at least, if we consider sport we can probably add a fourth.
Even if nobody else does I differentiate between:
Scrum as a synonym of Agile
“Scrum” means “Agile” like “Hoover” means “Vaccum Cleaner” in English English, or like “QTips” means “Cotton Bugs” in American English, or increasingly “Google” means “Internet Search” whether you are using Google, Bing, Yahoo or some other search engine.
This is the way I believe a lot of software people use the term Scrum. Although Agile is more than Scrum alone often (mostly?) when people say Scrum they mean some a general form of Agile, something with iterations, stand-up meetings, perhaps User Stories, perhaps some technical practices, etc. etc.
Hard Core Scrum, ScrumTM
This is Scrum without Project Manager or Architects, maybe even without Testers. This is Scrum of Commitment and Abnormal Termination of Sprints.
I once heard Craig Larman say “If you have a project manager on a Scrum team you aren’t doing Scrum.” Only last week Christin Gorman Tweeted saying: “If you want to use managers and architects, you won't be doing scrum. And that's ok.”
I’ve written before about how this hard-core Scrum might actually conflict with Scrum (When did Scrum start loving Project Managers) and XP (Two ways to fill an iteration).
This view sees Scrum as a kind of Communist Manifesto but with Managers as the Bourgeoisie. It would be funny if this weren’t so serious. I believe that if you take this interpretation you will soon run into opposition from a layer of managers. The paradox is that Scrum is as popular as it is because those manager don’t like Extreme Programming and saw Scrum as the management friendly alternative (The Three Advantages of Scrum).
Common-Scrum or Scrum-Lite
This is Scrum but without the anti-manager zeal. Of course for many people this strips Scrum of its primary asset - and they might be right. It might be that if you neuter Scrum you get a less effective result.
In this form of Scrum Project Managers still exist - assuming you had them to start with, a lot of places don’t. However they have been renamed Scrum Masters - see my example from 2008.
In Scrum-lite the word commitment really means “agreement” because the team are probably using velocity to judge how much work they can do. Architects and other ranks, sorry, roles, still exists. And companies still kill teams - corporate psychiatry is rampant.
In other words: it is full of compromises. It works for some companies, it doesn’t work for others and ScrumTM purists will hate it.
Anyway, I find it useful to distinguish between these three uses of the term “Scrum”. If you know any more please add them to the list.
Well there is "Just Scrum", as defined by Ken and Jeff, in http://www.scrum.org/Scrum-Guides.
ReplyDeleteIt is not trademarked, nor copyrighted. It does not use the concept of commitment, nor does it use chickens to denote some people in an organization.
The description is 15 pages though, so I can understand that most people feel it is too much work trying to grasp its intent ;-)
I did write a longer rant, but you only allow 4096 characters, so here is the last few bits:
ReplyDeleteArchitects have always been allowed to exist, according to Scrum at least.
"In other words: it is full of compromises. It works for some companies, it doesn’t work for others and ScrumTM purists will hate it."
This betrays a poor understanding of Scrum. There are a few simple rules and things you have to do, and a wide amount of scope to decide things for yourself. Most things you have discussed as compromises are simply things that Scrum never explicitly required or banned.
And a Scrum "purist" knows this. Some may hate it when their process is not completely Scrum conform. Some probably get annoyed when something is called Scrum when it isn't. Most probably recognize that it is seldom a matter of "it not working for some companies" but the case of "some companies not being prepared to make that changes required to work best with Scrum". Most hopefully recognize that there are situations where Scrum is really ideal (the development of complex products), and some where it isn't. (Like when you aren't developing complex products). Most probably find their own position somewhere on the "anti-management" spectrum, and are careful about what they mean by it.
So generally I don't like your post that much. The main idea seems to be that people's perception of Scrum are centered around two (ignoring your first meaning for now) opposing clusters based on how anti-management they are, which seems to be a fairly arbitrary criteria. If anything these two extreme poles exist only as an abstract model, and most people kind of fit somewhere in the middle.
You could just as easily say there are two types of Scrum according to certifying body: "Scrum Alliance Scrum" and "Scrum.org" Scrum. (This might actually qualify as two separate types. I believe there are some differences in the way the two describe some details of Scrum)
Or there are three types of Scrum according to estimation and planning details: 1. "Split PBIs into tasks first, estimate tasks in "ideal" hours, add up hours to determine Story estimate in hours. Velocity is expressed as something like how many ideal hours achieved per sprint".
2. "Estimate PBIs in story points, then split into tasks, estimating tasks is optional" and 3. "Don't estimate or split, just plan the PBIs the team thinks they can do in the sprint".
But all three actually fall within the flexibility that Scrum provides, so are in fact just three equally valid (but maybe not equally good) descriptions of how a team may work with Scrum. But it is the same Scrum, just used in 3 different ways.
(Or there is also Scrum-but, Scrum, and Scrum-and. But here too it is not different types of Scrum. The first is not Scrum, and the second and third are the same Scrum, the third just has some optional extras as well)
In fact, if we are prepared to divide Scrum into types according to arbitrary criteria, of which there are many, then I would claim there are as many meanings for "Scrum" as there are teams doing it (or claiming to do it providing we permit the inclusion of things that aren't Scrum at all, or are false meanings of the term).
So something is either Scrum or it isn't. There is no risk of something being Scrum according to one meaning but not another.
But even then, it isn't important if it is Scrum or not, as long as it works, makes sense, and you aren't calling it something it isn't.
Kurt,
ReplyDeleteThanks for your comments, nice to know people consider this important.
(It is Google's Blogger platform that limits comments not me.)
I don't intend to reply to all your points, I find it interesting that you find the world so different to the world I find. In this blog I tried to describe what I find.
One theme that is emerging is that 'hard core Scrum' isn't, which makes me wonder why some people,e say Project Managers and Architects aren't allowed in Scrum.
Now that I read my comment, I see I did a poor job of choosing which bits to trim, oh well.
ReplyDeleteAnyway, 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"?
I don't wonder why people say it though. Scrum is essentially a completely different way of doing what project managers did in traditional world of software development. Scrum was inspired by a culture that saw projects as a poor concept for structuring the development of complex products. That culture surrounding Scrum sees management so dominated by a set of values and approaches (roughly called "taylorist" or "command and control" by some) that the term management itself becomes justifiably suspicious. The existence of architects on a team may be an indication of a split between thinking and doing on the team. And may indicate or encourage the false belief that programming is nothing more than typing in the "design decisions" made by an architect, where in fact programming is in fact mostly just a sequence of design decisions.
Does Scrum expressly forbid the roles? No. Does Scrum represent a culture that reacts against and presents an alternative to what most people understand "project management" to be? Absolutely.
Does Scrum represent a culture that reacts against and presents an alternative to the traditional software architect, as most people understand the role? No, not really. One could however argue that the existence of such a role may not be in complete conformance with the spirit behind Agile software development.
So no, I don't wonder why some people might say that. They are rightfully being critical of roles that fit less well to the world of modern agile product development and knowledge work. Their suspicions are justified, but they are incorrect in declaring that Scrum explicitly bans the roles.
Are you sure they aren't saying "when I teach or implement a software development process using Scrum, I do not see a need for, or allow project managers or architects on the team"?
That is probably what they mean, and it would be a perfectly righteous statement to make, but unfortunately it sounds like they simplify it to the extent that they turn it into a false statement.
Kurt - thanks for comming back, I find your second set of comments much clearer. In fact I agree with much of what you are saying.
ReplyDeleteIn order to give a full answer I've written a follow up blog entry, please let me know what you think. I've taken time to address you point about Scrum and Project Managers.
http://allankelly.blogspot.co.uk/2012/11/hard-core-scrum-common-scrum-and-scrum.html
Thanks again