warning: this post contains higher then normal sarcasm levels

Over the last couple weeks and months I've had a number of people share what seems to be a common Agile misconception.  I've never heard anyone say this first hand but my impression is that it goes something like this.

Agile lets programmers do whatever they want, they never have to ship, they don't have to follow anyone's rules, and they can be as sloppy as they want.  Cowboy coders of the world unite....oh and sign this here agile manifesto while you're at it! 

Having worked in an agile shop for the last 3 years, as well as advocating and making small inroads at my previous employer for a couple years prior, I feel like I'm reasonably qualified to speak to whether that statement is true or not.

To be honest with you....it's completely true!  I am proud to say that over the last 3 years we've created some of the crappiest code known to mankind.  We haven't shipped anything to anyone since we get to decide when the software is done, and well, we've had much better things to be doing.  We make all our own rules, which we've found best to make up on the fly.  It's really a great setup.

There is just one thing.  For one, we do this thing called pair programming.  If you haven't tried it, it's where two programmers sit at a single computer and write code together.  We do it close to 85% of the day, and the vast majority of our production code has been written in this fashion.

There is something strange about pair programming.  You see when you program alone it's very easy to be tempted.  Tempted by the internet, by your email, by your shinny new iPhone.  It can also be tempting to take shortcuts in your code, do things the "easy" way instead of the "simple" way.  As long as it works and nobody else has to look at the code again, who could it hurt if it's mostly unreadable?  As long as that bar goes green we're good, right?  Actually, if we get rid of the green bar, we don't have to worry about wasting our time making it turn back green when it suddenly decides it wants to be red.

Pair programming doesn't allow you to be sloppy.  Actually that's a lie, it does, but it makes it twice as hard.  Not only do you have to be a slack ass, but your pair also has to be a slack ass.  And you and your pair both need to not care about the fact that you both know you're being slack asses.  And you and your pair need to also not care that when the next pair comes along and picks up  your code they're going to know you're slack asses.  Maybe that makes it more then twice as hard?  The point is, pair programming is really good at reducing the amount of slop that you let into your code.  So come to think of it, maybe that being slopping part isn't really true about agile.  But, at least we still don't have to ever ship anything.

Hrm, but we do have those weekly iterations (that's another lie our iterations aren't weekly at the moment).  The thing about weekly or biweekly iterations is that they force you to be able to "ship" something at the end of every iteration.  I say "ship" with quotes around it because we all know that you're not really able to physically ship every iterations set of work to a client.  There is a boat load of stuff that needs to be done in order to actually ship.  You need to make a branch/tag in your source control provider.  You need to package up the software, burn it to a CD/DVD, prepare release notes, and a bunch of other stuff.  But you could ship something to somebody, even if at the very least it's to the QA department.  On non agile, or more correctly, non iterative projects that doesn't happen.  Come to think of it this iteration thing seems to put a lot of restrictions on the development team.  Let's outline a few of the things that are popping into my head:

- Forces development team to continually stay focused on meeting delivery dates, as in every week or two
- Forces development to communicate with one another constantly about the status of the iteration
- Puts a pretty rigid schedule in place for the development team
- Focuses the entire team on the work at hand, and what needs to be done to get it done by the end date
- Allows the product team to have visibility into what the development team is working on every day and what progress is being made

I'm not sure if everyone's agile process is like ours but it's probably the furthest thing from "cowboy coding", "sloppy", and it most certainly doesn't allow the development team do whatever the heck they want.  On the many non agile projects that I've been on in my career I had a lot more flexibility with how I spent my day.  As long as when that date hit down the line everything was done, I was good.  In many regards I had free reign to do whatever I wanted, I could code the thing however I wanted, and could have made a complete mess if I wanted. 

Working in an agile environment is much more rigorous and disciplined.  We have a very strict set of principles and practices that we follow.  We pair program, which means we have two people working on most production code, which leads to much less slop code, much less just get it done code, much less we're never going to look at this again code, much less who cares what it looks like the test passes code.  Our agile process defines a very rigid schedule for us that defines when, and in many cases how, we do everything we do.  

If anyone ever tells you that Agile is easy, that it's sloppy, that it lets the development team do whatever they want, they haven't been on an agile team doing it day in and day out.  It's hard.  It takes discipline.  It's draining.  It can be monotonous, invigorating, scary, frustrating, annoying, enjoyable, puzzling.  If you're doing it and it's "sloppy" you're not doing it.