Here at SmartMoney, we have been using iterative development techniques for years. Even before the term was made popular in the technology field, we ditched the long drawn out style of project development. For the most part, we now employ a more cyclical style of development where individual features are coded, tested, deployed. New features are added based on lessons learned from the earlier cycle. From there we try to gauge the public’s reception to the feature through usability testing and feedback, then either work to improve that feature, or begin work on additional features within the same short cycle.

In the past we tried creating wikis for our projects and writing document specs. These are really a waste of time, and just do not work. They take weeks to create, and are often outdated as soon as they are delivered.  Better yet, even if they are not outdated, they are usually ignored. Iterative development gives you the opportunity to deploy, test, and most importantly to be wrong.  If a feature is not accepted by your users, you can easily refine or remove it.  You are more apt to admit your mistakes and remove a feature that took 2 weeks to deploy, than one that took 6 months.

The problem with getting buy in for iterative development at most companies is usually not with the technology group. Developers and technology managers usually embrace the techniques. It keeps things fresh, it involves less red tape and lets developers get to what they love – code. I find for me it keeps things moving. You feel less stale when you are always moving through these mini life cycles.

I find resistance to this style of development tends to come from the business side. Groups like marketing and sales prefer a larger “completely finished” project to sell to clients. Project managers tend to prefer larger projects to maintain their value on the project. The larger the project, the more management it will need. Finally, some people just don’t consider it a web project without a large cycle of gathering specs, creating wireframes, refining code, QA/Testing, repeat ad nauseum, then finally deploy. These are the people in your company that need to be sold on the benefits of Iterative development. I found an article today that discusses getting business people and anyone who needs it to embrace the philosophies of Iterative Development.
Embracing an Iterative Approach to Site Development. Its a quick read, and simply states some cost and time benefits you may find useful when trying to sell the idea to someone where you work.

Iterative development is practical and effective because it ensures you are keeping your projects lean and agile.  I really recommend looking into this style of development and trying to find areas where you can incorporate it into your workplace.  Even if the majority of your projects employ long spec-code-test-deploy cycles, you may be able to work with these methodologies in small ways.  Try to take a large project and see what can be broken down into manageable iterative chunks. My experience is that you will most likely have luck looking at the back-end development needed. This area of a project has the lowest visibility, as most project stakeholders care about the UI. Get familiar with breaking down the requirements to a bare minimum, coding for that minimum, then repeat the cycle if necessary. Once you have a few wins, or successful iterative projects, you may find others in your company are more willing to adapt their style as well. The benefits will speak for themselves.

Related posts:

1. deployment schedules are not effective Simply put, deploying code on a set schedule is not...
2. Knowing your users will help make effective decisions If you are reading my blog, there is a very...
3. Use Project Collaboration Software We use BaseCamp here for managing projects. It is extremely...
4. product versus project manager For years, SmartMoney had project manager(s).  This was more of...
5. Defining Roles Within a Development Team I am a big advocate of keeping teams lean and...

Related posts brought to you by Yet Another Related Posts Plugin.

Filed under:
code, experiences, philosophy by bill breen