Category Archives: Agile Development

Building for the Future

If you’re building for the future, you’re doing it wrong. That isn’t to say that you should cut corners wherever possible. The key is to spend your time building what you need now. If you concentrate on building what you need now, you will be able to do a better job. You will be able to refine every subtle detail, catch most bugs (create fewer bugs in the first place), and finish on time.

Building for the future rarely ends well. Time and resources are spent on building for something that might never be used. Can you guarantee that your product will make it to the future for which you are planning? Can you guarantee that the features you are prepping your system for will make it to fruition? How often to specifications and requirements change during a product’s life cycle? There is a chance your product will fall. It is highly likely that new ideas will come about and features you planned on building are no longer wanted.

Rather than spend your time building for the future, build for what you need now, and spend the time to do it right. Making a small, but robust, set of features work properly will give your product a higher success rate than building for features you might add later.

Posted in Agile Development | Comments closed

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.

Posted in Agile Development | Comments closed