Agile development - bespoke software development - Transition

Agile development – more than buzzwords?

A

gile development has become one of the key search terms on the internet when looking for a development partner. Many people searching for it fully understand what it means and what the impact could be on their project, others are not so sure.

In 2001, only 4% of companies adopted an Agile approach. Today, the figure is 86%. The reason for this dramatic shift in usage is the ability of the Agile approach to deliver results quickly and with lower costs on projects that have ill-defined requirements or processes, or projects that are subject to regular change and modification. It achieves this through its focus on customer involvement and ability to change, coupled with the emphasis on and Return on Investment (ROI) as the highest priority. This is in complete contrast to the traditional method, which is a process-driven approach focusing on contracts, processes, documents and tools.

Types of Agile Development

The umbrella term Agile Software Development covers a number of approaches. The most often adopted of these are: dynamic software development, scrum, extreme programming, lean software and feature driven development. All of these have some common factors, and the main factors recognised as contributing to the success of Agile development are:

  • Early Client involvement in the project
  • Iterative software development
  • Self-organised teams
  • Software changes in the development

The Agile systems development life cycle (SDLC) does not adopt an all-or-nothing approach to initial information gathering. Instead, it takes into account the fact that stakeholders and users almost always cannot provide all requirements at the outset of the project. By permitting continuous interaction with the developing software, the Agile approach allows customers to acquire an understanding of the software as it develops, and apply functional enhancements as they are identified. Through this approach, the Agile philosophy allows stakeholders to make informed choices rather than guess, and to defer important decisions to when more information is available or a better technology or approach emerges. Development can also begin more quickly, as there is no necessity for all requirements to be known before this phase is started.

As the specification of the software is built iteratively, Agile development has a very high probability of delivering an end product that better meets the company’s needs. As each module is completed, it is reviewed by the client and as – at this stage – it is not fully integrated into the system, changes are usually much less costly and less likely to cause performance or integration issues. Full system integration is implemented only when all requirements are completely developed and understood.

 

The flexibility of Agile development

team-business-conceptAn Agile approach also has a major advantage in being able to iteratively tune the software to the needs of the stakeholders, the users and the business. Each iteration provides a low-cost opportunity to layer functionality and integrate changes in operational business processes, in order to maximise ROI. However, while this ability is a major benefit, the developers (in particular the project manager) have a responsibility to advise stakeholders and business owners on any technical risks and performance issues that these changes might bring.

 

Agile development in practice

Although Agile methodologies have significant advantages over traditional methodologies in many areas, their implementation can present a number of difficulties in practice. These include:

 

Documentation

One concern with the Agile methodology is the reduction in documentation concerning the system being developed. However, there is a credible body of opinion that holds that the document lies within the code itself. Experienced Agile developers typically lace much more comment into the code as a means of explaining its structure and function.

 

Junior developers

The Agile method can prove problematic for junior developers or new team members who sometimes cannot adequately review or understand the project and its goals. This means they are reliant on experienced developers. The result can be a delay in individual iterations, and ultimately a delay in the project and increased costs. On the other hand, the traditional methodology provides detailed documentation on the project, helping developers to understand the project. If junior developers are to be involved in a project, it is often pragmatic to consider a merging of methods.

 

Repeated re-working

Agile methodologies are based on client involvement and, at each iteration, the development team and client should meet to discuss progress. The development team members will review their code, while the client will provide feedback on the iteration and suggest refinements and additional features. Developers can find these constant iterations, and the typically tight time frames between iterations, difficult and tiresome, as repeated presentation often brings with it re-working and the addition of functionality, due to changes in requirements. If the module under discussion involves complicated processing algorithms, time frames become even more squeezed, delaying the delivery of each iteration. This can cause the project to fall behind the plan and lead to strains on the relationship with the customer. Delays can also cause tightening of scope and function by the development team.

These issues are less likely to occur in traditional methodologies, as a well-defined requirement is in place long before the coding process starts, providing a defined progress benchmark for the development team during the coding stage. Customers are less likely to get involved at this stage of the development life cycle. The development team will code according to the documentation provided by business analysts until the large areas of the entire system are complete, at which point the client carries out user acceptance tests on the completed software. This model provides the developers with a wider time frame for code completion, and frees them from frequent review meeting or the implementation of ad-hoc changes through the project. This can result in software which is more closely matched to specification.

 

Communications

To make the Agile approach successful, good communication between the customer and the development team is essential. Well-developed social and presentational skills are also useful, so that the team can explain each iteration to the client using appropriate language, so that they can contribute to the process. The developers also need the ability to provide clear advice with respect to improvement opportunities that the code can deliver, and explain the consequences of changes requested by the client. If the developer lacks the necessary communication skills, or relies on a third party to interpret requirements, additional work and delays are likely to result.

Despite its many benefits, Agile methodology – in all its forms – can be problematic, if not properly controlled. Design issues based around rigidity and mobility are typical results of poor process management. A significant change in a module during an iteration, for example, can cause a cascade effect across previously completed iterations and other modules. This, coupled with the difficulty in implementing reusable components across a purely Agile development, suggests a pragmatic approach to the adoption of the methodology.

 

 

Conclusion

Agile software development has evolved to deliver major benefits including; reduced development times, better ROI and less re-working and bug fixing at the end of a project. The result is often higher customer satisfaction.

However, while the Agile approach is a very powerful alternative to the traditional ‘heavyweight’ SDLC in modern software development, it is not yet perfect. In fact, there are many barriers to putting Agile methodologies into practice, including the client’s company culture, communication skills of the development team, potential client confusion and Legacy software issues, to name just a few.

In deciding which route to follow, Agile or traditional, it is important that the development team and client adopt a pragmatic approach. This means ignoring buzzwords and avoiding a ‘flavour-of-the-month’ approach, and – instead – carefully reviewing the components and issues involved, to establish which methodology best serves the objectives of the project. Issue which will be relevant to the choice of SDLC include, but are not limited to: development capability, team experience, type of project, business strategy, company culture and client preference.

Transition computing has learned, through long experience, that it is better to maintain a flexible view on methodology type, as every project and client is different. Instead, we approach each project with a fresh set of eyes, and discuss the question of the most suitable SDLC with the client team. The result can be the adoption of an Agile or traditional approach – or, if the project requires it, a combination of both methodologies. In this way, we ensure that we always deliver a successful result. One of our primary skills is the ability to use our experience to determine which methods are best suited to our client’s needs, and to fine-tune them so that they deliver the highest and quickest ROI and value. After all, at the end of the day, “Agile” is fundamentally about being flexible.