You are here: Home › About › Agile Software Development

Agile Software Development

“Software development methodology” refers to the framework that is used to structure, plan, and control the process of creating a software application - web or otherwise. There are numerous methodologies, such as waterfall, iterative, spiral, and others. We strongly recommend using an agile methodology for development of any substantial website or web application.

What Is Agile?

Agile methodologies break development into small increments called iterations - short "timeboxes" of typically one to four weeks. This incremental approach lets the project adapt to changes quickly, and is ideal in situations where the precise system features are unclear at the outset - which is true for the vast majority of software development projects.

In an agile project, the system features - called “user stories” - are defined as usable bits of functionality. Features start minimal and are improved in small steps. Each iteration includes planning, design, coding, and testing of a set of user stories, and at the end a working product is demonstrated to stakeholders. Developers and customers jointly decide how to bundle the user stories into iterations based on their priority and difficulty. Teamwork and frequent communication between developers and customers is another characteristic of agile methodologies.

Why Agile?

It is a truism that software projects can have only 2 of the following 3 characteristics: delivered on time, delivered on budget, and delivered according to specifications. Agile projects fix budget and time and allow specifications to evolve. At the outset of a project, we won’t know what features will work well for users, and we have only a rough idea of what will be hard or easy to develop. After a few iterations we have a much clearer idea. Agile methodologies allow projects to take advantage of this learning curve and adapt as they go along.

The following quote from the book The Art of Agile Development, by James Shore and Shane Warden (O’Reilly) nicely summarizes this point.

"The beginning of every software project is when you know the least about what will make the software valuable. You might know a lot about its value, but you will always know more after you talk with stakeholders, show them demos, and conduct actual releases. As you continue, you will discover that some of your initial opinions about value were incorrect. No plan is perfect, but if you change your plan to reflect what you’ve learned - if you adapt - you create more value."