There is a lot of mystique associated with being  “agile”.  Even for developers who are usually so tech-savvy, they talk about agile in odd terms – like my grandma might ask what the web is used for.

Like:

“I guess I’m a little a bit agile, but I really like to use use cases – does agile have use cases?”

Or,

“I woudn’t want to do scheduled releases like agile because I don’t want to send the customer half-finished features.”

They really just have no idea what agile is…

I get it.  I hate buzzwords and bandwagons, too.

The difference is that I’ve been on multiple agile teams that were so incredibly successful that I am sold.

• I never have to feel that sinking feeling in the pit of my stomach just because my customer found a bug.
• I don’t have to fight with my customer over whether something is a bug or a feature request.
• No more working crazy overtime at releases.
• No more holding your breath at the big, scheduled demos that it will actually work.

So what is this magic? In the effort to spread a little knowledge and good cheer, this post is just a small tasty sip of the agile KoolAid:

1. Agile is a set of ideas, not a religion

Agile is based on a set of ideas called the Agile Manifesto. For example, value “individuals and interactions over processes and code”. I have no idea why so many agile proponents try to indoctrinate everyone into their little cult, but that is the opposite of what agile is about.

Agile doesn’t say you can’t use any process, agile doesn’t say you can’t use any up-front design, agile doesn’t say you can’t use your previous use cases!

You don’t have to worry if agile is going to destroy some precious aspect of what you do, because by definition if it’s working well for you and the project then it’s agile.

2. Agile doesn’t increase project risk, it reduces it

Agile recognizes that feature creep and unexpected bugs are going to happen. Traditional project planning basically crosses your fingers and hopes it won’t happen, or punts it to some later date (I’ll deal with feature creep when it happens, We’ll handle all bug fixes at the end).

Instead, agile puts the reins in the hands of the customer/client/PM/whatever. By allowing them to reorder the backlog however and how often they choose, we ensure that the programmers are always working on the most important thing at any given time.

If you run out of time in an agile project, by definition you have already completed the most important things. If you run out of time on a “traditional” project, you most likely have something completely unusable, like a database and middle layer but no UI.

Listen, agile doesn’t make crappy programmers write good code and it doesn’t turn useless products into good ones.  All it does is allow programmers and PMs work together on the same side the table and focus on the things that matter, like getting to done.

Google is known for its fantastic amenities including from free gourmet meals, massages, elaborate workout facilities and recreational centers.  Paying for these amenities provides Google with plenty of benefits, including increased productivity (from happier employers who stay at work longer), improved retention of their employees and a great recruiting tactic.

While they are at the far end of the spectrum, many companies have spent time and money on employee friendly workplaces.  Available amenities range from free sodas and ping pong tables to on-site gyms and hosted conferences.  And for their efforts they get also get the benefits, in proportion, for productivity, retention and recruiting.

Even with that whole coolness factor, Google and other companies are still scrambling to find top talent.  There is enough talent in the world, but there just aren’t that many people who are already located nearby or who are willing to relocate there.

Progressive companies are moving towards distributed development teams.

Distributes teams are teams where the developers work together … from home.  There may or may not be an office, but most of the developers’ collective working time is spent not there.

Probably the most well-known example of this is is 37signals.  It is based in Chicago with office space and half the team there and half the team distributed, and anyone can work from home.  They not only practice this but encourage it on their blog and recent bestseller Rework (affiliate link).  Another recent headline maker in has been Stack Overflow with a half-distributed team as well.

A few other high profile examples include DailyBurn, Gravit, Automattic and DotSpots and there are plenty of lesser known examples as well.

Elephants can dance, too

It’s not just restricted to small, very agile companies.  I’ve even seen larger companies embrace distributed teams on a team-by-team basis.  As outsourcing and global collaboration becomes more mainstream, distributed teams are much less scary.

It’s just smart business for companies to move towards distributed teams. You can reach the best talent, including people who would never ever move to where you are geographically located.

Plus, they take the place of those fancy Googleplex amenities:

• Instead of enticing people to stay at work longer, you can move work to them.  Passionate workers will naturally work more when it’s so convenient and built-in.
• Instead of having your employees go through hour-long commutes, get more working time, go green and reduce stress (also reduces need for those free massages).
• Instead of manicured lawns, give employees some breathing room by allowing employees to work in natural setting with easy access to comfortable outdoor settings.
• Instead of installing ping-pong tables and video games, avoid burnout by letting employees enjoy fun in their own homes
• Instead of hosting a childcare center so that employees can be near their children, let employees select great childcare options near their homes, see their children at home anytime if their spouse or nanny watches them there, and greet their children when they get home from school.
• Instead of filling up employees with unhealthy sodas or expensive gyms, save money while improving the health of your employees with access to their kitchens for easy homemade foods instead of fast food.

And for those companies that just want to spoil their employees rotten, you can still provide great services like paying their gym memberships or team vacations.

… why can’t everyone lavish these sort of perks, and this sort of environment, on their employees? Well, because we’re at a weird time in the history of the growth of the Internet. At this (perhaps anomalous) point, the business leverage resulting from the focused application of human intelligence is so high that all these benefits and all this freedom, considered through a pure cold profit-and-loss lens, are cheap at the price.

Tim Bray in Life at Google

Look for more smart companies hiring for their distributed team at a location not-so-near you.

This is a follow-up to the popular How to Find Crappy Programmers.  If you’re interested in having a team of crappy programmers, instead of those annoyingly bright and passionate good ones, you probably want to start there.

Despite your best efforts, some good programmers slip through the cracks – how can you get rid of them while keeping your coveted crappy programmers around?

1. Focus on Punctuality and Butt-In-Seat Time

Never mind that a good programmer can produce more valuable work in a 30-hour workweek from home than a crappy programmer can toiling 60 hours in the office.  There’s no point in getting useful software in a timely manner if you don’t get the all-important face time.

Good products are nice, but there’s nothing more fulfilling in a manager’s life than seeing a roomful of people, heads-down, typing away in tiny cubicles at 8:00 am in the morning.  Coming in at 9:30 am is wholly unacceptable – those guys are just having too much fun.

You get people on salary so that they aren’t on the clock, and that way you don’t have to pay extra when they work longer than 8 hour days.  Then again, don’t be afraid to insist that they work at least 8 hour days all the time.  Who cares if they have nothing to do, or if they have already gotten way more done than the guy next to them, surfing the internet?  It’s butt-in-seat time, baby.

2. Set Their Salary Based on Their Age or Time at the Company

Setting salary based on your age makes a lot of sense since you, the manager, are probably old.  That way you get more money.  Since that’s illegal, you should base the pay on “years of experience” which equates to age for everyone who didn’t go on a 5-year+ sabbatical.  Don’t worry, that’s pretty much only working moms, and you probably don ‘t want to pay them much either.

You might have an employee who’d rather be paid based on their productivity or the value of their work or even their skill level.  Blasphemy! Clearly, that person is just looking for a free ride, without having to pay their dues.  Say it with me people: “We care about everything except for the actual work you produce.”

3. Reduce Time Spent Coding

It’s important for developers to spend a lot of time in meetings.  That way they can get a complete understanding of the minutia in the business side of things.  And also, it’s more fun to have a big audience when you ramble on in meetings.  Don’t worry that we won’t have any time left to do actual work (ie. coding), we’ll just come in early and stay late to get that part done.

Another fun thing is having your programmers do your desktop support.  Really, anytime your Outlook or your iPhone is acting up, feel free to call them over to troubleshoot the issue.  It’s so handy having geeks around.

4. Monitor and filter their Internet usage

Developers just can’t be trusted, everyone knows that.  We are always hacking things and downloading illegal music and that sort of thing.  So, you should definitely install a program to monitor their internet usage.  You could also block sites that you deem to be a waste of time, but then that might tip your hand that you’re monitoring them.

For that matter, you ought to go ahead and dictate what development environment and tools they have to use.  After all, you picked the setup with the longest feature list (not to mention the sales guy took you to lunch) so those developers shouldn’t have anything to complain about.  Anyone who wants to use anything else is just a prima donna.

5. Make Them Build Crappy Software

This is the most important one of all.  A crappy programmer can only make crappy software.  However, a good programmer has the ability to make both good software and crappy software, right?  Wrong!

Good programmers hate writing crappy software.  They’re always yammering on about code design and trying to test everything, what a pain.

Force them to write inline queries, develop in VB on the command line and fix bugs in 1,000 line methods.  They may fight it at first, but pretty soon they either leave or become a crappy programmer also.  You’ll know that they’ve come over to the dark side when you see that empty look in their eyes and when they see a Dilbert cartoon they laugh … maniacally.

The reality is that not everyone is interested in managing good programmers. Sure they get things done and know a lot about technology … yadda yadda.   They also challenge your assumptions and push to improve the system and that’s just not going to work in your business.

The fact that it’s been done that way before and hasn’t imploded yet (or lately) is good enough for you. You can use these handy tips to keep your crappy programmers while firmly excluding the good ones.

Like this post? Subscribe to the blog or follow us on twitter for more fun updates. Code Anthem is a startup aimed to help programmers show what they can do and connect with great companies. Stay tuned.