Ok, i’ve attended the on campus Introduction to Scrum class, gotten the briefing, asked a LOT of questions, been a huge pain in the ass to the instructors, and have learned a lot about Scrum functionality.
i’ve learned that my initial feelings are exactly the same.
The issue that Scrum faces is not technical. Far from it. In fact, most of it is stuff that every successful team already does. Most of it is common sense (which is never as “common” as you’d like). The problem that Scrum faces is marketing, to be frank, they’re using the wrong terms.
Let’s be quite clear. A “scrum” is not a way for a team to pass a ball quickly to all the members. It’s a bunch of guys from opposing teams kicking like hell at everything until a ball pops out, preferably toward a member of their team. The term “Scrum” is about as appropriate as calling it a “dog pile”.
If you have to have something that is team based, consider “Bucket Brigade”. There, you’ve got a cooperative group of individuals working quickly to accomplish a very directed goal, get water from well (A) to fire (B) and empty buckets from B back to A. Each member of the brigade has a critical role to play (don’t drop the f*king buckets) and they work like hell.
That gets to the next term, “Sprint”. Ask anyone who runs, you don’t “Sprint” constantly. Well, you do, but then you get CO2 poisoning and either pass out or die. If you’re a horse, your liver explodes. Either way, constantly sprinting is bad. A Sprint in Joe Average terms means “run like sweet hell”. You don’t jog from a man eating lion. You don’t walk from a collapsing building. You seldom mosey to break the ribbon. You Sprint. You push yourself as long and hard as possible for a short period. Sprinters generally do things like “collapse” afterwards.
What you want to call it is “Heartbeat” or “Cycle”. That’s what it is. If anything, consider it like an engine where you’ve got preparation (mix gas and air in the chamber), work (ignition and thrust of the explosion), recovery (vent the waste gases and prepare for the next intake). Rudolph Diesel worked that one out in 1898 and considering his engine still operates in the Smithsonian, i’m willing to say it’s got a lot more life to it than a Sprinter.
Next up, this whole “Project Backlog” business. They’re requirements. Granted, the way they’re specified is via “User Stories” (also known as case studies) and unlike most projects, there are actual requirements listed. Calling them Backlog items is silly since it doesn’t help identify what a Backlog is and probably is a cause for folks being confused about what should go into it. (Ok, that’s a minor nit.)
And finally, so long as you’re going for “X-Treem” terms like “agile” and “scrum” let’s call some other spades. You don’t need a “Project Manager”, you need a “Benevolent Dictator”. You need someone with a clear idea of where he or she wants the project to be in a year. You need someone who is not only willing to say what lives and what dies, but is able to do it with so much authority that if there is an objection, it’s for a DAMN good reason (“It’s my favorite thing” is NOT a good reason.) Likewise, you don’t need a “Scrum Master”, you need a “Referee”. That persons role is to be the one that makes sure folks are playing fair and well. Hell, give them yellow and red cards or a whistle if need be because that’s the position they generally are in. They’re arbitrators and governors who are there to prevent conflicts and ensure that things keep moving. (i’d actually call them Engineers in the train sense, since that’s the non-technical position they have the most in common with, but that’s confusing.)
Finally, They’re not “Stakeholders”, they’re “Customers”. Yes, it’s more than conceivable that you’ve got multiple “Customers”. It’s also possible that said “customers” never give you a dime. These are the folks for whom you’re doing this, right? They’re the ones that are going to benefit in some way. Naming them after the disinterested individuals who hold the dollars your poker chips represent is far from accurate. These folks are HIGHLY interested in what you’re doing, and much like your other customers, will ultimately decide if your project is a success or failure.
Ok, those terms aside, i don’t see why one should or shouldn’t use Scrum for development. i’m actually fairly ambivalent about it. i think that having a defined process (ANY process) in place is a HUGE win, and Scrum is currently the one in favor. Having worked on only three, true “Waterfall” process in the past, i can tell you that they work equally well. It’s not so much what the process is, as having one to begin with. i’m going to be working with a group using Scrum and i’ll do my best to ensure that i and others follow it. i’d do the same with any developmental process. (i might just use different “wordages” for things.)
And now, let the hate mail roll in…
