In my previous post, I speculated that an agile approach to software development might be a better one than the traditional waterfall approach. That’s probably true with many projects, but it isn’t always the case, so I advocate that ideally an insightful decision should be made based on the context of a project.

Introducing context-driven development

The idea of context-driven development is about using whatever development methodology, techniques, and tools are applicable to a project, instead of defaulting to an established norm regardless of suitability.

Small companies are born context-driven. That’s why I love working for them. They use whatever tools and techniques are available for the task at hand, and focus on getting the job done the best way they can.

Think of a cutting-edge web startup. They are focused on the product, not documenting their processes or writing up detailed designs. Their goal is to speedily ship successive iterations, each one incrementally better than the last.

Losing the way

So where does it all go wrong?

As organisations get bigger, they begin to focus less on getting the job done, and more on the idea of ‘process maturity’. They develop procedures, manuals, and documentation, and this is where they start to slide away from a context-driven approach into the ‘one size fits all’ mentality.

To a point, this is understandable. Big companies like to be able to quickly and easily replace staff. They introduce processes to control everything their workers do so that they can (in theory) ‘drag and drop’ resources into projects as and when required.

The problem with this approach is that smaller projects that don’t need complex methodologies can become burdened with unnecessary documentation and design, slowing things down, and lengthening the development process from what might have taken a few weeks into several months.

The solution?

Context-driven development makes sense. Not all projects are born equal, so while a waterfall methodology and detailed documentation might be suitable for one, a more agile approach with minimal documentation might be suited to another.

Consider the project context before trying to shoehorn a project into a methodology just because it’s one that’s traditionally been used. Look at all aspects of the project, including the requirements of the stakeholders, and decide which methodology, techniques, and tools are applicable.