Agile Development: why it rocks, who it helps, and why it's failing

The Agile method was the best thing that happened to me in my career as a developer. Before I came across Agile, one of my biggest frustrations was the difficulty I had with getting large assignments and breaking them down in little pieces. Usually, in the beginning, I'd be at full steam, really motivated, really excited, and rearing to go. This would last for a little while then the chunky middle part of the project came, some of the more boring parts, and before you know it I'm at a crawl. Then, when things are due in a week, full panic mode would commence and there would be ridiculously late nights followed by incredibly sleepy mornings, then sleepless nights all because I thought I had a handle on the scope and how long it would take to complete.

 

Agile was a new awakening for me. For those of us who aren't aware the concept is to plan your software development X amount of weeks in advance then break up that time into still smaller sections before you get started. The reason for this change is that seeing how dynamic and fickle the world of software and software development is it just isn't prudent to plan that far ahead. You go with the brightest and best new tools and concepts and three years later when your plan is complete it's mostly obsolete. Planning only small parts at a time allows for the ever changing industry. The unit of weeks that you choose to use is called an iteration. Each iteration you plan out exactly what your team will deliver when it is complete. Then as a group you break down your plan into projects. Then personally you break down your projects into tasks that are anywhere between .5 and 3 days long. You then have daily stand up meetings to discuss how you are doing on your tasks, if you are ahead, or possibly running into issues you can cut them off at the pass. There are all kinds of permutations like Scrum and XP, but you get the drift.

 

I myself took to this like a fish to water. No longer did it feel like I was sitting in front of a ton of unpeeled potatoes, I had something to accomplish today. Just one thing. Then tomorrow I have something else that will take me two days, then after that another day on something else. Honestly, I haven't looked back since, I could never go back to the old way of doing things.

 

Frankly, the industry hasn't been the same. Agile development lends itself to huge wins for well designed, awesomely developed software. However, nothing has surprised me more then the rumblings I've been hearing lately about how “Agile sucks, everyone said it was so cool and it just doesn't work.” “We have an Agile shop and they are four months behind and no one gets anything done ever.”To me, that's like saying “Water is a solid” or “Aaron Heilman is a dependable reliever,” it just doesn't make any sense.

 

So, I've done a little investigating of my own. An insightful email from a reader who goes by the name Abhishek Parolkar really got my brain churning. I asked myself what was consistent about the complaints I have been hearing. I had my Eureka moment a few moments later (sans bathtub)

 

See, what was making these Agile shops so successful and productive was not purely Agile at all it's a combination of some very key traits that allow for unfettered growth in technology and development. What the initial adopters of Agile had in common was that it was a “start up” type of idea. In other words, it was the small companies adopting this methodology, not the bigger firms. And this makes sense, because it's a lot easier for 5 guys to make a process change then 150 people of varying skills and specialties. We see this everytime a new software or tool that is popular among industry professionals. Like, right now it's Git and RoR the majority of the shops you will see focusing on these things are the progressive, smaller companies.

 

So, what else did these smaller companies have in common then the fact they were using Agile? Well, the time from approx 2003 on I think we will grow to view that as the re-awakening of the start-up. A little of the sting of the “bubble burst” had passed, people got some of their money back, and had some new ideas. The perks and the relaxed atmosphere and the focus on employee satisfaction retuurned. The developer as a species appreciates these type of places, it's our natural environment and the condition in which we thrive. Where our ideas are welcomed, where there is no pre-approval paper work, where there aren't 2 week long QA processes, where the hard part of implementing a great idea together is walking from the big white board to your desk without getting another one.

 

See, what's happened lately is the bigger IT departments have attributed this success and prosperity to the Agile process, when really they need to look at the minds that recognized this process as a great idea and what other things they think are important. Making a process change as big as a new methodology is huge, so most places with > 50 people are either slowly switching over or seriously considering it now. The kind of complaints I've been hearing are followed by statements like “Plus, my boss is such a dick he makes me subtract out my cigarette breaks when I bill” or “I just can't stand it everything they ask me to do just makes no sense and there is nothing I can do about it.” That's where the larger companies are loosing it, being an Agile shop isn't good enough. When your employee dreads Mondays no methodology is going to make them want to work hard for you, and therein you get no similar productivity boost as the other Agile shops, you may have better architected software, but the huge measurable profitability successes just aren't there.

 

What about Google you say? Well, they are the perfect example of how you do it correctly when you have a lot of people. They are a large company, however they run their development teams as a bunch of smaller more intimate groups. They take the time to make sure every employee loves being there, that their immediate needs are met and all their individual ideas are considered and encouraged.

 

So what's the moral of the story? Implementing the newest ideas  is simply not going to get you the incredible department you have been waiting for. Sometimes, you can get caught up in pomp and circumstance about your “sophisticated and professional” team. However, your “sophisticated and professional” team of developers is hating every second, so you get behind, and you miss deadlines, and you get stuck in backlogs. Not because Agile doesn't work, but because when people aren't happy they don't care if your company succeeds or not. They care about their Saturday nights, or where they are going after work, or if they remembered to TiVo Heroes. So it's simple: when you care about your developers, they care about you and that ALONG with the best practices and tools are the keys to success.