Method Schmethod. Get to Work.
A lot of us in the “business technology products and services” industry think of ourselves as “hard-nosed, can-do, delivery-focused professionals”.
Sometimes, we react negatively when we encounter a colleague who asserts that formal methodologies and frameworks have value in improving our work process and outcomes.
“Jeeze, Fred, that’s all ivory tower stuff — we use the ‘just do it’ methodology here. Get to work and stop banging on about viewpoints and meta models. No one cares about that nonsense.”
Unfortunately — sometimes — our condescension is justified. There are people in this world who are obsessed with methods and frameworks — as ends in themselves. They’d rather argue about semantic definitions of methodology concepts than test their knowledge in designing and delivering products and services better, faster, cheaper.
In the old days, we used to call people like this “fuzzy-headed academic loafers”. Can’t say that these days.
Sometimes, the world of methodologies is like a warm, fuzzy refuge from the cruel world of getting stuff done. We can spend too much time worrying about methodology and lose sight of the goal. Like the crew of Eastern Air Lines Flight 401. How embarrassment that was.
However, for many of us, our interest in the value of “defined professional methods” comes after years of failure with the “just do it” method. We’ve adopted formal, consistent, repeatable methods and frameworks. Because we’re drowning. We’re sick of failing and wasting time and money, time and time again.
You get what I’m saying? I often find younger professionals tend to favour the “just do it” approach. Older professionals — who have suffered the indignity of wasting years of our lives on failed business transformation programs — are the ones prone to think “there’s gotta be a better way”.
But learning how to integrate methods and frameworks into our daily work is hard. In the beginning, it slows us down. Anything worth doing doesn’t come cheap.
The “just do it” people get impatient with the iterative “try-fail-learn-repeat” learning curve for adopting repeatable, defined process and techniques. So they get frustrated and go back to “just do it”.
Of course, the “just do it” model works fine — if you’re always doing pretty much the same thing, over and over again, day after day. And if all you’re responsible for is your work, and the work of the people in your immediate team. What about the other 400 programs and projects in your large company?
But these days, things are complex. Everything’s changing. Life comes at you fast. Not many of us work on assembly lines.
I got interested in methodologies when I was a “technical architect” back in the ’90s. I became aware of “architecture patterns”. I found them useful. I realised developers worked more efficiently when — as a team — they used consistent, repeatable, work techniques and tools. That led to an interest in systems development life cycle methods (SDLCs), which led me to things like TOGAF, SAFe, ArchiMate, Design Thinking, and all the frameworks from DAMA, IIBA, Business Architecture Guild. That’s my excuse.
Here’s an analogy:
I’ve been learning jazz guitar for 50 years. All my guitars are ugly. I don’t clean them. I replace original parts with better after-market parts, which reduces the value of the instrument because it’s not “all original”. My attitude is “it’s a tool, not a collector’s item.”
I’m the same with methods and frameworks. If it works, keep it. If it doesn’t, throw it out and keep looking for something better.
Finding the “Goldilocks Point” with methods can be challenging. Not too much. Not too little. Just enough and no more. Perfection isn’t the goal. Perfection is the enemy of fit-for-purpose.
And if you’ve read this far:
There’s another paradox with methodologies and frameworks: the people and the organisations that create methodologies and frameworks tend to be a bit odd. A lot odd, actually. Not naming names. One sometimes finds oneself thinking:
“Guys. Do you ever use this stuff? Why don’t you apply your own method to what you’re doing when you’re creating the next version of the methodology? You’re all over the place. It’s taking forever to progress this. You’re spending all your time arguing and changing your minds and reworking things you said you agreed on months ago.”
Extra credit to anyone who can give me another music-related analogy that applies to what we do.
Any opera singers out there?
