Agile Software Development

At Dream Folk, we believe in using agile software development practices. That means we like to deliver basic working software as soon as possible so that the software is used in the real world, by real users. Experience from that real world use then feeds back into requests for improvements to the product, and those improvements are also delivered as soon as possible.

we like to deliver basic working software as soon as possible

The agile manifesto lists the following key differences between agile and traditional approaches. Agile emphasises:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Traditional approaches to software development place a large emphasis on the requirements document. That’s a document that is written before actual development of the product starts. It attempts to describe every detail of the product. The idea is to only commit resources to building the product once you know exactly what the product is going to be. The approach is inherited from engineering practices in the physical world. It makes sense when constructing a bridge, for example, to have a very good idea of what you are building before you start laying concrete. That’s because changing the design mid-project can be very expensive, since you need to undo parts of your physical construction.

Agile approaches embrace the uncertainty inherent in new product development

Software is different. It is typically no where near as expensive to undo things you’ve already done. As such it generally makes sense to use a different approach when developing a software product. Instead of specifying the details of the entire product before you start, you can actually develop an initial cut-down version of the product and release it to users. Feedback from those users actually using the product can then be used to influence the next short term release of the product.

This is in contrast to the requirements document approach, where the only way future users can influence the product is to read the requirements document, and to attempt to imagine what it will be like to use the product. That is no where near as effective as putting an initial version of the product in the hands of the users.

The traditional requirements document approach is often used in situations where a fixed price contract is being negotiated. In such situations, an almost adversarial mentality can develop between the software developer and the customer. Both are worried that if the requirements are not sufficiently detailed, then they might end up worse off. The software developer is concerned that there might be hidden requirements that the customer is expecting, but that have not been written down, but that the customer assumes are included in any quote that they receive. The customer is concerned that there might be useful features that they haven’t yet thought of.

The customer is not expected to know exactly what they want up front …

The above concerns are symptoms of the uncertainty inherent in new product development. It is very difficult to attempt to uncover every single product requirement up front. As a result traditionally some combination of the following three things happen:

A huge amount of resources are dedicated to the requirements analysis phase. All that effort is spent up front, without any tangible progress on the actual product.

Software developers add large fudge factors to project estimates in order to ensure that their fix priced quote is not too low.

Software projects are delivered well behind schedule with less functionality than originally planned.

... and the software developer is not expected to commit to a fixed price for the entire project.

Agile approaches embrace the uncertainty inherent in new product development. Instead of trying to specify every little detail up front (and signing a contract that says that’s what will be delivered), agile approaches view the relationship between developer and customer as members of a team who collaborate together on incrementally producing the desired product. The customer is not expected to know exactly what they want up front, and the software developer is not expected to commit to a fixed price for the entire project.

Is this just hacking?

Sometimes people suggest that agile software development sounds like an excuse to skip all the discipline of traditional approaches. In actual fact, agile development requires just as much discipline, but the discipline is applied to different (more useful) aspects of software development. For example:

Comprehensive regression tests. Because agile approaches embrace change, it must be possible to change software at any stage of the project without causing existing product functionality to fail. A comprehensive set of automated tests goes a long way towards allowing such change. We use test driven development to ensure that all code is well covered by automated tests.

Emphasis on code quality. For similar reasons to the above, agile processes emphasise maintaining a high quality code base with minimal levels of duplication across the code base. That means that when code does need to change, it typically only needs to be changed in a few places. Agile developers are encouraged to constantly refactor their code in order to maintain the high quality required by the agile approach.

Summary

We prefer the agile approach over the traditional fix priced contract approach, as the end results are generally better for both the customer and the software developer.

For more information on agile software development, the wikipedia page is a good place to start.

Menu

News

2008-05-20

2wayfitness.com

2-Way’s unique personal fitness training service provides clients with one-on-one access to a professional
fitness trainer who monitors their progress, provides professional advice, and helps them to set and achieve
their fitness goals.