The Changing Face of Software Development and Becoming More Agile

With many software projects historically running over budget, missing delivery dates or both, the software development process (or software development life cycle) has constantly been scrutinized and refined in order to improve productivity and quality.

Several models have existed in order to guide the development process with more traditional approaches favouring a strict order of activities to be completed in turn until the project end date. 

A widely accepted example of this approach is the Waterfall Model.  Here, the emphasis was on determining the complete requirements and design up front which would then lead on the implementation of those requirements.

 

 

The Software development life cycle represented using the Waterfall Model

This approach had its benefits.  After all it promoted planning and good design in order to develop a robust, maintainable final product on time and to budget.

However, this process would often result in large amounts of documentation being generated between activities as different key players would normally be involved for different activities.  This was an advantage or disadvantage depending on how you looked at it but one thing was for sure, it took time.

This approach was great in theory but one important factor soon became evident to software developers and the business alike, ‘The Reality of Change’. 

After all, the customer would often not know all the requirements to a suitable level of detail up front until the project took take shape and the problem was better understood yet the Waterfall model requires that all requirements are known at the beginning of the life cycle.  Additionally, if aspects of the business changed during the development cycle then the requirements might also change. The result being that the customer received a product that no longer met the needs of the business.

Welcome the Agile Model, an approach to software development which embraces change throughout the process in order to provide a high quality solution which better meets the needs of the business/customer.

The Agile process promotes a productive team and importantly requires that the customer is an essential member of that team.  The customer works directly with the development team, reducing the knowledge gap and providing key input into how the project develops and evolves throughout the life cycle of the project.

So how does the Agile methodology work?  To fully understand the solution we must first understand the problem.  Consider this graph:

It represents the more traditional approach (e.g. waterfall model) that over time more requirements are realised as the software is developed but ultimately as the business changes and evolves the original requirements no longer meets the needs of the business.

Now consider this revised graph based on an Agile framework:

 Put simply, the Development Team with regular input from the customer fulfils a small set of requirements over a short time period.  The team can then ensure requirements are being met, modify the requirements if business needs have changed and add additional requirements in order to perform another small sprint of work.  The idea being that as the business/requirements change so the software is evolving with it and the end result is something that closer resembles the needs of the business.

In essence features can be thought about as Stories rather than a set of technical requirements, and so can be more easily envisioned by the customer.

With input from the customer, these stories can then be put in order of detail (e.g. it makes sense to start with a feature that has a high level of understanding and detail from the business, rather than one which remains vague until the project starts to take shape.) and  importance to the business.

The benefit is that Managers get an estimated cost for each feature/story rather than trying to estimate the entire project.  This makes sense when the business will re-evaluate the project after each increment/release at which point, requirements may change and features may be added or removed.  It also allows the customer to discard lower importance features if the budget runs low while still providing a solution which matches the business as closely as possible.

As a developer one of the biggest problems has always been ‘scope creep’ a term used to explain a change in requirements during the life cycle of the project.  

Scope creep is highly likely as a business will not fully understand the solution it requires until the project starts to take shape.  If not managed correctly scope creep will often lead to developers making easy code changes rather than re-designing, often due to the imposed time and budget constraints.  The result is often a difficult to maintain, low quality system, which may never get finished.  

Agile directly addresses this issue and turns it on its head, so instead of scope creep being a problem, it is welcomed and encouraged.  Developers work against a story of features before presenting iterations regularly to the customer. Alterations are addressed and new stories are refined and added which will lead to a solution which better meets the needs of the business.

Agile processes like Extreme Programming (XP) and Scrum accept that requirements will change and create opportunities for improvement and competitive advantage

Ref : www.agile-process.org – Manage your goals instead of activities

Agile processes are employed here at DSCallards by the development team on some of our more complex projects in an effort to be more productive and provide quality solutions which meet the needs of our customers.  This article gives a glimpse into the idea of Agile Development.  In my next article I will talk about some of the frameworks e.g. SCRUM, which are used to develop complex projects within the Agile methodology.

Written by:  John Langley, Senior Developer, DSCallards