News & Events

Agile Development – A simple explanation from a simple person.

“Learning more whilst working at dsp, I have recently spent time in an area alien to me; our Agile Development Practice. Not being a developer, I was keen to know what Agile Development is, why we do it and why it’s used. Our Development Practice Lead, Nils Hagner, has been very patient with me outlining some key differences. I hereby try to write about what Agile is; and why people are raving about it.

Software development approaches and methodologies have been around for 70+ years. There have been many ways to deliver software. I won’t go into all of them, but just the first one, and the most common one.

Code and Fix – The original approach to development was where developers wrote code and then fixed things that were incorrect as they were found. Software Developers had to wait to see if what they developed worked; either in terms of errors in code or if the software actually did the job it was intended for. This, of course, is expensive and riddled with risk; almost completely reliant on guess work. No one in the real world uses this approach for serious software development.

Waterfall – this approach is the more traditional approach anyone involved with IT projects would be familiar with. It involves structured steps before the software is deployed. Like this:

1. Requirements
2.   Design
3.     Development
4.       Integration
5.         Testing
6.           Deployment

This approach has been around for over 50 years. Waterfall gave a structured approach to each stage of software development, ensuring the next phase doesn’t start until the previous requisite steps have been taken.

What’s wrong with that? I hear you ask… well, a number of things (so I’m told). These include:

Time to market – Any one of the above stages can result in unscheduled delay. Requirements may not be agreed, Design is dependent on requirements, development work can’t be scoped until the design is complete, and the level of testing can’t be determined until something has been developed and integrated, etc. Making delivering the end result at a given time almost guess work

Lack of Flexibility – Water only flows one way. If the requirements change, the whole process needs to be ditched and re-started – or suffer scope creep causing all ends of problems. Waterfall requires the Requirements to be locked down for this very reason. If the requirements are wrong, the end result will be wrong.

– Lack of Customer involvement – The Waterfall approach means the customer is only consulted at the beginning. If their requirements change during the project, tough luck. That’s what they’ll get.

This results in development projects often overrunning and under-delivering. So along came Agile…

The AGILE approach

Agile Software Development involves breaking down the Waterfall method so that development teams are not restricted to just testing or design or development work. Teams are organised into Scrums and each member does a bit of each job.

Secondly, Agile requires direct customer involvement; a brief is defined and in a very short space of time (sometimes days), something is developed and reviewed by the customer. If it’s close to what’s needed, they carry on. If it’s not, then requirements are further defined and they start again or tweak what’s been done. The key being is that the customer (i.e. Stakeholder) is constantly involved in the process and progress of the development – any changes to the requirements are addressed immediately, and any development delays or roadblocks are addressed.

The key difference is that Waterfall and traditional methods of software release NEEDS requirements to be set out from the start and clearly defined. Agile, by its own definition needs requirements NOT to be clearly defined.

So why now? Why is Agile now becoming so prominent?

I hear you ask. The main reason is the explosion of online applications over the past 10 odd years. Web apps and the prominence of e-commerce based organisations means that in order to have a competitive edge, organisations need to be fast to market and be adaptable to ever changing business requirements.

Now that business is so reliant on software, organisations can’t afford to be held to ransom by their software development departments.

Agile – how to do it

dsp has an Agile Development Practice that can assess your software development environment for efficiencies in using an Agile Methodology. dsp has the ability to set up Agile teams, take on Projects using Agile principles using our own near-shore or on-shore Agile teams.”

Get in touch

For more information or to schedule a demo please contact us

Contact us


dsp drives up its share of the Database MSP Market with
record contract growth and 2nd acquisition

DSP firmly established itself as one of the UK’s fastest growing proactive Database MSPs during 2016, signing £2.1m of new contracts and making its second acquisition, the Oracle DBA support division of IT Services provider ITSB.

Read more
View All


Applications on Oracle Database Appliance (ODA)

A main goal... how to future proof your applications environment through Oracle while becoming more efficient in terms of costs and productivity.

As well as the option of developing the fundamental steps you need to take to get ...

Read more
View All


How can you regularly benchmark your database and application infrastructure against real-life? Why would you want to?

In the age of big data, public cloud, private cloud it’s easy to be pushed into constantly thinking about the future... What should you optimise though and how can you be sure it’ll make a difference? Would knowing it could give you a competitive edge be worth considering?

Read more
View All