Agile Zone is brought to you in partnership with:

Hi nerds, I’m Sara and I’m a girl developer, or a “gerd” if you will. I am an ASP.NET/C#/SQL software engineer. I like to think I have lots of hats though. I’ve worked on all different sized projects, high volume and low volume sites. Different types of databases. One thing that is very unique about the project I am on right now is that I’m doing it all by myself! I am used to working with a team of awesome developers. Sara is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

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

08.27.2008
| 6681 views |
  • submit to reddit

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.

References
Published at DZone with permission of Sara Chipps, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Asif Sehzaad replied on Wed, 2008/08/27 - 7:11am

yes....

Mike Cottmeyer replied on Fri, 2008/09/05 - 9:36am

As I was reading this... I kept thinking... these shops are not successful at agile becuase they have not implemented agile. 

 Delivering in two week increments by itself is not agile.  Small independent requirements by themselves are not agile.  Whiteboards and notecards by themselves are not agile.  Agile is about creating teams, empowering people to make decisions, giving them some input and influence over their lives.  Creating self-organizing and empowered teams, that deliver small independent requirements on two week cycles starts to look agile. 

The problem right now with agile is that every one wants in but are not willing to do what it takes to make it happen.   I consult for an agile tooling company, and in my work, I come across many groups that say they are agile but have not structured themselves, or created the right environment, for agility to take hold.  

You are correct that culture takes time to change and that is harder in bigger organizations. Agile can be done in the large, but you have to stay focused on what really makes teams agile.  Saying agile failed when it was never really implemented is not fair to the methodology.  The teams that learn to do this well will kick ass and take over their market.  Teams that scoff at agile, and say it does not work, becuase they did not do it right, will soon be out of business. 

 

Josiah Hester replied on Fri, 2008/11/28 - 10:36pm

Agile can be a big change for many companies, the nature of Agile is to make large projects more manageable, but the hard part about that is that proects that are already started that are large makes it VERY difficult to change methods midstream.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.