It is important to me only as far as not getting in the way of the common sense that we hope most professionals would have.
When we talk about version control, there is the argument that
any version control beats not having anything at all, this isn't the case with development methods. Methods mean rules, and rules are sometimes broken. I've worked for companies that have been doing really goofy things for as long as anyone can remember, whatever problem the goofy procedure happened to cure went away a long time ago.
I want the following out of a company:
Clearly documented procedures that fit on a few pages. If I have to read a dissertation or (worse) a novel in order to get up to speed, I'll be lost for a long time.
Evidence that the company is open to changing procedures for the better. I need to be able to go to someone and say "I realize why you're doing [xyz], but there's a tool out that does most of that for you now. Can we use it?"
A little competition can be good and is often unavoidable. But, I'll avoid any shop where competition is used as a primary means to motivate people. If you have codified something that sends the # of lines committed per day by developer to the laser printer at 5 PM, I don't want to work for you.
If you have not prevented builds in blessed repositories from receiving changes that break said build, I run like heck. The last thing I want to do at 5:00 is pull in changes from the master repo to test my local build, only to find myself fixing someone else's semicolon.
I prefer jumping into methods that resemble an established method that fell from the agile tree. It's not mandatory, but a sense of familiarity helps to overcome the initial hump of trying to be productive while not making a procedural mistake.
If I see that I'll spend more time resenting procedures than being thankful that they exist, I'll probably pass on the job.
The other resounding "oh no, never again!" is "We're hoping you'll also set up best practices for us. We have six million lines of code and 21 telecommuters, should we be using an SVN or something?".
Someone could have some fun sorting that out. I'm not that guy :)