Those of you who've worked with me know I don't take most of this crap that infests our cube farms too seriously. When applicants announce their Six Sigma belt colors, or their MBA focus in MIS, or their affinity for a particular process improvement methodology before even sitting down to learn thing 1 about a project, it pretty much assures that they will not be hired (or simply thrown out the nearest window).
But why am I so negative, you may ask? As someone that always touts open-minded behavior, why the constant judgement and dismissal? Oh well! I'm human! And I also happen to be damn good at my job, really at all the jobs I've held. Some things really help with this - no fear of getting down and dirty with the details, or diving in and figuring things out from scratch; a constant willingness to learn and improve; and facing the big problems head-on, instead of tiptoeing around them like so many pussyfoot managers do today. That's why I excel, and will continue to excel; I'm doing the job, and as simple as that is, it somehow catapults you to the top of the IT ladder.
Does that mean a lot of IT analysts, project managers, and management teams are somewhat useless, and browse the web or goof off or inflate themselves with seminars and certifications when they can barely do the equivalent of wipe their rear-end at their current job? Not my place to say, Jack. I've worked with some great ones, and some dumb useless ones too. And for the record, I browse the web at work, but manage to get my stuff done without issue.
I have issues with Six Sigma (cult?) because it's a broad-spectrum process improvement methodology that has been gobbled up by a lot of people, without first taking into account its applications in their particular environment. By itself, it's a crisp, clear, fantastic methodology. One potential way of helping companies obtain better standards and efficiencies.
The problem is intellectual laziness; just because using vats of acid works great in the waste disposal industry, does not mean you can apply it in, say, a bakery. Six Sigma leans heavily upon an assembly-line architecture, which suits it perfectly to manufacturing, and some other straight line, repeatable tasks, where job duties are clearly segmented into crisp, clean roles, and nothing ever needs to take a seperate route or becomes an exception.
Before implementing it, or deciding to jump wholly on board like some scientology freak giving all his money to the church on Day 1, managers really need to examine if their model will benefits from taking the Six Sigma trip, and hiring the requisite expensive Black-Belt Samurai Overlord, and getting your whole team expensive little Yellow Belt and Green Belt plaques, and sending everyone to classes to eat up their normally productive days like some kindergarten field trip. Six Sigma is not a sudden free pass to operational excellence, jackasses; it's a tool that can be utilized effectively, assuming you know how the hell your company works.
The main thing to remember is everything in moderation. When you go from a normal operating procedure one day, to a complete 180 into some new idea/methodology/development process, things are going to break, and employees are going to stress. Do it slow, do it smart, and take what you need from these tools - don't go head over heels every time a new term comes around the IT bend, or you'll find yourself with a solution that was tugged in 8 different ways over 3 years, and a constantly revolving workforce as the Term-Of-The-Month takes its toll on employees that crave stability and good decisions from management.
Agile Development was another one of these. Right after I left my last job (thankfully), they went nuts in adopting Agile, redesigning their whole software development lifecycle and IT team structure and meetings and coffee pots and whatever else to align to this new, interesting idea. One of my buddies had to take the title of ScrumMaster, and had to organize sprints and name certain folks as gazelles or whatever this new silliness involved. I wanted to make his life tougher, so I got all his co-workers to start wiping their chin immediately after saying the word ScrumMaster. It already sounds like something right out of South Park, so giving it that extra kick really helps drive home the immaturity and silliness of the new titles.
Again, by itself, Agile is something of a decent idea (albeit the silliness of the names really kills it for me). But these things are like Communism; great ideals, but holy hell can they be implemented all kinds of wrong.
I just had a 2-hour conference call with a new healthcare client...me and 1 developer on our side. They had about 10 people on their side, going around and introducing whoever was the scrummaster, pig herder, dungeon master, fruitcake, and whatever other silly names they made up. Maybe it's just my overwhelming disdain for hot-term development methodologies, but doesn't this feel to anyone like a combination of trying to make your job seem exciting, and losers who desperately want to relive high-school role playing? Yes, I will be ScrumLord! And you, you will be the CodeMonger! I thought I left this stuff behind after 9th grade, guys. You know, when it became more interesting to touch girls.
Part of my new process improvement methodology, 28 Lambda, will involve tossing out all these ridiculous terms, because...just to let you know, when you're on the phone with a small company, and you start using these made-up words - Scrum, sprint, stories - like they are OK to use...it just makes us shake our heads and feel bad for you. It makes me want to go work construction or something, where there aren't any ass-clowns constantly redefining my title/role as a Welding Specialist and Steel Rod Master and Bolt Finagler. These bullshit terms that spread like some contagious technological STD should be called out for what they are - ridiculous, demeaning, inappropriate, and in most cases not even well suited for the environment in which they are being applied.
That is all.
-The Future C(EO)