The more i think the Scrum Methodology, the less i think of it.
That’s not to say that there aren’t certain things that are useful, but let’s get rid of some of the crap.
1. Nobody uses the “waterfall” method.
Alright, that’s not literally true. In the past 20+ years of programming, i’ve worked on two programs that used it. They were both large, monolithic efforts that resulted in systems that needed to be both highly reliable and highly secure. They were designed according to the venerable MILSPEC-25, which detailed literally every function, action, input and output of the system. The requirements were huge (as in “stored in a warehouse” kinda huge), the QA steps took weeks and the overall development cycle took years.
No other business i’ve worked at does that.
Every other business works reactively. They have a general idea of what needs to be done, work towards that goal and alter as the competition and technology advance.
Sounds oddly familiar, don’t it? That’s because
2. Scrum is nothing more than lots of little “waterfalls”.
Yep, think about it. Even large User Stories tasks are nothing more than generally specified requirements. The only difference is that the requirements aren’t thought out before-hand.
You know, that always makes me laugh out loud. Other than those MILSPEC-25 projects, guess what document was always the last one delivered, if at all? Yep, the requirements.
What was important in all of these were the marching orders. Actually, that’s a pretty darn accurate description of it. If you’ve got an army that you want to get from A to B, you’d better know from the start that you want to get to B. How you get there, how you get around obstacles you encounter, and how you deal with issues are all things you generally consider on the march. Bridge missing? Go elsewhere. Find some abandoned but working trucks? Whoo-hoo, everyone gets a ride! The important thing is that your team stays focused on reaching the goal.
The same is true with any project. If you don’t have a clear understanding of what the hell you want to do, it doesn’t matter what new design methodology you use, you’re not going to reach it.
So, what does this say about this latest technique?
3. Scrum isn’t new or innovative, it’s the same thing you’ve been doing. Seriously, this is generally the way that engineers have been writing code for the past 20 years. Some might even say that is the strength of scrum. It should be incredibly familiar to anyone who’s been in the industry for more than a year or two.
Anyone who actually pays attention during those staff meetings should recognize the pattern. They should also see the biggest problem.
4. Scrum doesn’t address The Enemy.
What’s the enemy? Well, there are two of them. The first is the Calendar. Commercial projects have calendars. They have hard dates. That’s because commercial projects have external commitments they have to achieve. It may be that you have to meet some big expo. It may be that some partner gave you $30 Million dollars and is expecting to be live in the first quarter. It may be that some other team needs to have your product working so they can use it.
These are real, hard dates that are generally outside of your control. “So we slip features” i hear the scrum folks say. Well, no, see, that’s the problem. While it’s certainly possible to do that, quite often the number of real non-necessary features are pretty darn few and nearly impossible to categorize. Plus, since you’re now “agile” the product folks expect you to stay up-to-date with competitors, meaning that you pretty much have to work on new, highly required features.
Yep, features. That’d be feature creep to those familiar with pre-scrum life, the other half of The Enemy. These features are absolutely required because your product has to be the leading edge, best of breed system otherwise it’ll languish. Oh yeah, and we need it live in two months because otherwise we’ll lose 140K a day in revenues. Kthxbi!
What’s even worse is the fact that this decision making process is hard to nail down. Why?
5. Designing by committee vs. dictatorships
Yeah, see, it’s easy to toss tasks into a pool, particularly when they’re not being overseen. Yes, i know, there’s supposed to be a scrum leader (heh, obviously these folks don’t play rugby) who’s job it is to oversee that, but unless that person is the project manager, they’re outnumbered and outgunned.
This, again draws back to my point that a successful project needs to be run like a kingdom. One person needs to be in clear control, have the focus and drive the idea. That person with that control is what makes the product a success, the method they use is irrelevant.
This kinda touches on another aspect that scrum glosses over.
5. No ownership.
This is one thing that always kind of bugged me. i’m weird, i admit that. i do less than glamorous tasks because, frankly, nobody else will. If i see that someone needs to write a script that pushes data into a bucket, i’ll step up and do it. If there’s a pile of digital hay that has a needle stuck in it, i’m the one going through that. i’m the guy that deals with getting the customer content because it’s almost always crap.
i’m usually not the guy that writes the amazing front end that gets the oohs and aahs, although i can and have done that. Those ooh-ahh products are a heck of a lot of fun to work on and they get you lots of attention.
A lot more attention than reworking a filter for the fortieth time because someone screwed up the spec’ again.
Scrum doesn’t encourage ownership. It wants to give people the freedom to pick whatever they’d like to work on. That means that whoever the sorry sod is that inherits that particular turdblossom later doesn’t really get a lot of help, and woe be it if they underestimate the amount of time required to make the change.
This is not to say that Scrum isn’t without it’s benefits, but i’ll counter that the benefits are not for the engineers.
What scrum does right (provided it works that way) is to force the decision makers to see the impact of their changes. You want to do X? It costs this much. Granted, that communication already happens. The problem is that the decision maker does what they will do in the future. They’ll blow it off or pressure engineering to meet the hard date regardless.
A good engineer knows this, and is more proactive about things. They talk with their customers (that would be the product managers) very early and often to see what they’re thinking. Nothing formal, just a quick weekly email or a lunch or something so that you know what they’re thinking. Simple communications do wonders.
The other thing that Scrum kinda gets right is that it mandates that sort of communication… sort of. Poorly, by my standards. See, scrum requires that you give a daily status report to your fellow engineers who you are competing with. Yes, competing. If you appear to be doing less for whatever reason, your value is reduced. It may be that the reason you’re doing less is because of operational issues, or things outside of your control. Doesn’t matter. When Bob reels off the fact that he completed 20 tasks and you’re still working on one who gets the gold star?
Now, granted Bob’s 20 tasks involved changing the color of a bunch of buttons where you need to create a wireless interprocess communications layer between a Mac and a VAX 720, but that’s beside the point. He’s still 19 up on you! SLACKER!
i’d rather have engineers spend parts of their day talking with their customers and dependants to get a feel for what the demands and schedule issues are. And if you’re not smart enough to ask for help if your stuck, you need to stop thinking so damn highly of yourself.
i’m sure Scrum will go away, just like every other methodology did. i’m sure that there will be some that praise it as the wondrous saviour of the generations. i just wish folks would be freaking honest about it and stop pushing the propaganda.
And seriously, Scrum?
Did you ever even WATCH a rugby game?
