Getting things done without GTD, being agile without Agile

Or, "does the process matter more than the work?"

Maybe I've been in my isolated little work world for too long, where I've had to wear lots of hats, and for the most part, teach myself everything I've needed to know, and just get things done. But apparently that's not important these days. These days, you need to GTD. And agility in your process is not enough, you have to be Agile, and Scrum.

What's all this? Well it seems to me that the process of how work is done, especially software development work, is more important to some people than the work itself.

I've been dismissed from interviews because I couldn't describe the Scrum process, yet I've worked iteratively on software projects, delivered features on deadline, and added features over time. Hmm.

I've read job requirements that include "Must follow GTD process and be Agile". Hmm.

I've watched 'professional developers' fritter away time and money talking about their code sprints while not actually delivering any product (or even product components). Hmm.

I guess it all looks good on a resume, and I may be naive, but when did concentrating time and energy (and money!) on the process become more important than concentrating on building the product/service? When did buzzword compliance become the key criteria for evaluating employee potential?

Where do you draw the line between the effort you spend on organizing your time and the effort you spend actually moving work forward?

Flame me if you must.

Comments

It's all about trade-offs. Yeah, a semi-big project involving more than four or five developers needs some sort of organization process for how to report progress and document what needs to be done and who's responsible.

But you're spot-on when the activities of talking and documenting getting things done eclipse actually getting things done. Every methodology, programming language and framework always gets its ardent followers, and some of them take it to extremes that "The Foo project engineering/ Bar language/ Baz on Rails will heal all." But it's bullshit. Most of these things are very useful tools, and we may have personal preferences, none of them are a silver bullet. But some people you give a hammer to, every problem looks like a nail. And to toss away an otherwise good candidate who is a bright self-starter because they don't know $PREFERRED_DEVELOPMENT_METHODOLOGY_DU_JOUR is just frankly fucking stupid. If it's so damned important, give 'em a book on it and toss them in. They'll figure it out. And if they can't, that's not someone you want anyway.

You've just described the newspaper business. When I worked at the Register they formed committees to freaking decide what committees to form. When they held meetings they seemed to have thoughtful discussion about what the hell to do next. But instead of making changes they changed nothing. (lather. rinse. repeat). Not so strange that the only answers they've come up with is to cut people and resources. That's what happens when you waste years doing nothing.
Another place I worked briefly has been working on updating its web site for 2 years. Instead of spending the money initially on having someone do it right they kept cutting corners and being forced to start over again and again and in the process spend most of their time *talking* about what to do next. The new site still hasn't launched and now they are falling behind their competition.
If you are getting "hey buddy, what's a scrum?" questions, start talking about rugby then politely excuse yourself from the room. Or tell them you use the BALLS approach. When they ask what that is -- tell them you have the balls to plan and execute any project in under half the time of any other so-called agile ball-less scrums followers can do it.

Christian's picture

Absolutely. I'm not saying having a process and framework is bad, but what IS bad is when you spend so much time and energy assembling and managing a process that you don't deliver on your real goals.

And it IS bad when you can't hear any outside opinion over the sound of how awesome you (and your $PREFERRED_DEVELOPMENT_METHODOLOGY_DU_JOUR) are.

Someone needs to keep an eye on why you're doing the work in the first place. That varies by industry (academia vs non-profit vs for-profit), but I'm seeing end goals overwhelmed by process and structure and committees everywhere I look, whether that's in the running of media companies or software projects.

The gap in productivity between the software field's most productive and least productive is probably the largest of any industry. That gap is so large that whole industries can be outdone by two guys working in their basement.

There are several reasons for this, but most of those touted seem to miss the fact that software engineering is largely about inventiveness. Process is certainly involved, but while arguably nowhere near the top contributor to performance disparities it IS one of the easiest things for someone on the outside to tweak.

Which is maybe the real problem. A lot of people in the software industry don't seem to really understand the programmer's job very well. Given the chance, most small teams of good people will gravitate toward a process just to minimize communication problems and duplicated work.

But if you can't organize in small teams and get good people, imposing a process (e.g. Scrum knowledge as litmus test for group compatibility) is STILL replacing group building for machine building, and I really think software work is too organic to be caged that way.