Good Agile, Bad Agile (and other things)

That picture of Britney Spears bears this very very slight resemblance to my sister in law. If she were some sort of panty-less, drunk crack-ho. That's sort of creepy. And if I apologize for that comment, it's to my sister in law, not to Britney Spears - bring it on Chris Crocker (your namesake bought me a sweater in high school - so I'm not scared of you).

Mr. Mustard...the fallacy bit was on purpose. It just seemed so obvious. And Kyle...it took Jeff Sanderson three years to figure out that whenever he had a headache, and someone said, "go sit on a piece of soap" they were referring to "ass burn". Given that attention to detail, no one in the locker room would have noticed my webbed, retracted, prehensile, glittery, tattooed, musical wang, particularly as I attached a tail to it and called it a weasel. But don't think about my wang - think about fashion models in white blouses. Serenity now.

Fimoculous said everyone had seen "I Ran So Far" on Saturday Night Live. Um...not me. Not my friend, Mr. Mustard. Not my friend the Swede. Not anyone I know. But it's funny - damn funny. The Jake Gyllenhaal cameo is extremely funny.

Speaking of videos - both of these Daily Show videos linked by Crooks and Liars are hilarious.

Finally - the title piece. Chris Crowhurst, who is related to a coworker I really like who started the same job I do at the same time, who I was interviewing for my old group on the same day I was interviewing with him to work with his group, which I couldn't work with, because he was going to work with my old group, which I was trying to escape, and whose said relation dated an evangelist (tech kind) who I sat in meetings with because I was on one of the early Biztalk 2004 projects in the Twin Cities, always has some great posts up on Agile development (that was a lot of work for a topic, eh? I'm just trying to point out how my workplace is crazy small sometimes despite the 6500 or so coworkers) and this time is no exception. I was enthralled with his link to Stevey's Blog Rants on Good Agile, Bad Agile (via The Art of Programming with .NET). Why did I find it so interesting? Because on some level, Agile has always bothered me for precisely the reason Steve Yegge says - there are people who are just so damn evangelical about it. And I'm someone who thinks there's something to be gained from almost everything - some small suite of skills that can either benefit a developer, or show them what not to do. And I'm definitely a bit too excited about it now and then. I think the same thing about Agile - I just think people always take it too far. Like Grady Booch said in his talk last week - you can take everything too far, like Microsoft does with their one day builds, and then everyone is scrambling to get something done every day, instead of thinking through what's best. Development is a pendulum, and you have to keep it near the middle. Then again, Grady said Google is a company in need of some sort of serious adult supervision, so I imagine he and Steve have their issues.

So what do I like and not like about Agile? I dislike the idea that all Agile ideas are good for a project to the extent they're sometimes taken to extremes. And by extreme, I mean there are even instances when they're imposed upon groups that already working and producing appropriately. There seems to be this idea that if you have a group (like Stevey claims exists at Google) that functions, and produces, and produces effectively, and makes clients happy, that Agile will still create some sort of benefit over the current state even if it has to be rammed down a throat or two. Automated builds, unit testing - those create benefit. But they're not just Agile - Agile just tends to leverage them and then occasionally insists that they created them. I've seen a number of Agile projects and my personal take on it is that Agile works great when there's a great team who likes to work together. When it's being driven by someone who could care less about the developers and only cares about the code and the end product, I see the same issues that plague any project. Bottom line: if you have an effective team (go read The Five Dysfunctions of a Team by Patrick Pencioni), Agile works, it just further binds a team that's already close and knows each other. If you have an ineffective team that doesn't care about each other, then it doesn't matter - scrum and stories be damned, people will scrape to get by with what they can in the daily meeting and sprints, just like they were doing before. Chris' experiences with Agile always sound so positive - but from what I know of him, he's a great guy, he's excited about technology and his projects, and he hires great people. Agile gives his team a structure, but the core is a culture. From some of the recent posts on his blog, I get the impression that his team may have run headfirst into the wall that is CMMI (or the equivalent in some of our other groups) - and that's got to be a tough spot. I've done both Agile and CMMI (which I've come to think of, in some respects, as waterfall development - not model - in that there's the BDUF and then a bunch of people who may or may not know what the hell is going on pushing toward the same goal, a bunch of them splashing onto the rocks, but the thrust of the damn thing is basically an unstoppable force), and I've seen the benefit to both, but the idea of getting the two to integrate when led by different teams is a frightening prospect.

I tried very ineffectively to explain my programming style to a VP once upon a time while interviewing to be an architect. He said, and this is tight paraphrasing, "You can't be an architect, you walk away from projects." Ouch. I replied that projects matter to me in as much as the people who staff those projects matter to me. In any project I'm on (was in) I know everyone. I know their motivation, I know their skillset, I know their long term goals, I know the politics, I know who's in the way (usually me), and I know how those things interplay with the project to make it succeed or fail. To me, people matter, and when you genuinely care about them (and here I make an important qualification - when you care about the people who want to learn and create successful software), then they come to see that the project matters - not as deadlined, gantted events, but as exciting events with their own momentum and camaraderie. And to take it a step further, when you care about the people you work with, particularly at a large company, then you generate a sort of social-aspect-oriented programming that cuts across projects as people become excited to work with you and the projects you're excited about. They know you're going to get rid of the impediments that keep them from being successful and that you're going to do what it takes to make the project and the people successful. I know, because this is the way I work, and in most of my projects, there's a time to leave, to pick up and move to the next project, no matter how much management wants you to stay in one place and keep things smooth. Because informed change creates opportunity for the developers you want to succeed, because it creates new intellectual and development pathways in the project, and because it's simply the right thing to do to move skills and technologies around the company. I get the impression that when management sees this behavior, and it's not sanctioned, it's "bailing". If they thought of it and approved it as a rotation program, it gets an official acronym.

I think what I'm getting to, bottom line, is that Steve has a very serious point - a company that has a great culture can generate something that puts Agile to shame, hands down. When people really like each other, and like their company, and understand the motivation, and understand the incentives, and have access to the tools they need to succeed (i.e. software, training and people/mentors), they are going to create, and create in a manner that's innovative and inherently agile. That is so cool. I think my favorite example is consulting teams that evaluate the difficulty of a project by basically playing rock-paper-scissors. That's not an Agile methodology - that's developers who have a culture that's allowed them to step up and put their best fist forward. When those things aren't there - Agile can smooth some of the bumps and provide a framework that allows for some great software development, but it's not the silver bullet. It's just another tool in a box that's been evolving for years.