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.”