The Benefits of Agile Development

Note: If you are completely new to the Agile Development methodology, I suggest you read up on it first as I will use quite a bit of terminology particular to the methodology.

While I think Agile Development is a better approach to web development when compared to the waterfall approach, and loosely practice it in my personal projects, we only just recently implemented it at work. We finished our first sprint this week, and completed a block of work in 9 days that I thought would take months with our old process. To be fair, we doubled our team from 3 developers to 6. While we did greatly increase the size of our team, the biggest factors were having a concrete set of tasks for the sprint, and not wasting hours per week in status meetings like we had in the past.

The best thing about the switch to the Agile Development process was that fact that everyone is happier. We are a large publishing/media company with limited web development resources. The business units are constantly fighting to get their work done. Now, they get to pick what gets done within a given sprint. In the end, there’s no reason for them not to be happy anymore, and they are much happier now. I have been working on this project for 9+ months, and only recently have started to receive praise from the business units for our hard work. On the other side of things, developers are equally as happy, if not more. We are not being constantly pulled in every direction, our highest priorities no longer change on a day-to-day basis. We are able to concentrate on a specific set of tasks during the sprint, and are able to see those tasks completed. We can see the fruits of our labor. And, if there are interruptions, it is understood that a change in priorities will affect the time of completion for our tasks.

Another great thing about this methodology is that it is understood that no one get 8 hours of work done in an 8-hour day. There are interruptions, meetings, time is taken to help team member solve their tasks, and etc. Currently, it is assumed that we can complete 6 hours of work in an 8-hour day, and we plan the work items in the sprint accordingly. If at the end of the sprint, it is determined that we can complete more or less work in a given day, we plan accordingly for the next sprint.

It has only been a couple weeks since we started implementing Agile Development, and there will be plenty of kinks to work out, but it has already made a tremendous difference. The business units are happier, and are in more control of their products. The developers are happier and in more control of their code and how things get done. Realistic expectations are set, and goals can finally be met.