The case for an agile methodology

I have recently decided to implement an agile methodology for the development of a mid-size project.

The following dot points outline a few of the reasons for which I decided to use the agile methodology.

• Focus on people rather than on the methodology.
• Reduce the bureaucracy and increase efficiency in the development process.
• Address my observation that users generally don't understand what a software solution will men to the business until they actually get to use the product.
• Changing business requirements due to a highly competitive market.
• Have a flexible, yet effective development team.
• Increase the level of communication between IT and business stakeholders
• Lower the software time to market.

In this methodology the software is built on iterations which are made up of the following stages:

1. Gather the requirements that will be implemented in the short term.
2. Document the requirements.
3. Design and code the solution.
4. Present the solution to the users.

*Testing is done all the way through the development process and more specifically before step 4.

Please note that the purpose of this blog is not to explain how to implement the agile methodology, the purpose is to describe my implementation of the methodology in order to support others in their journey towards implementing an agile methodology for the development of software.

The rest of this document describes each step that makes up an iteration.


(1) Gather the requirements that will be implemented in the short term (iteration)

Today's business environment is very competitive and dynamic. Companies need to able to address a changing external environment in order to remain competitive. The purpose of software is to support the business in its operation, therefore software needs to be flexible to support a highly dynamic environment. The agile methodology addresses this issue by building and delivering software in small increments and only gathering requirements that will be built in the short term. If the requirements, or the priorities, change there is little or no waste of time and effort because the software planning and development is done in small increments.

Although all requirements are not gathered at the beginning of the project,business analysts or solution architects need to work with business stakeholders to get a high level view of the software and to enable a basic architectural model to be built. This process is important and should focus on gathering just enough information, not to compose an encyclopedia. The idea is that even the architecture can change during the development of the project.

(2) Document the requirement

This topic is often included in the previous section, the reason I separated it is because of the issue of agility. Traditional development methodologies require that a significant amount of time be spent early on the project, gathering and documenting all of the business requirements for the entire project. This can be an often long and tedious part of the project.

The documentation gathered should be just enough to enable the developers to code. It is important to keep in mind that for a agile methodology to work, the development team needs to have business representatives available throughout the development process to answer any questions that arise. This is positive because it increases interaction with business and addresses the traditional scenario where developers and architects discover details about the system that nobody has previously considered. Business representatives need to be prepared to discuss those topics quickly in order to enable the development process to continue.

The agile methodology emphasizes the importance of verbal, face-to-face communication as opposed to written documentation, which is often ambiguous and open for interpretation. Increasing verbal communication will in turn reduce the need to have overly detailed written documentation.

Another important item to consider is the purpose of the written documentation. When there is a bug or someone needs to find out how the software works, developers and business users very rarely rely on written documentation, they go directly to the software. Therefore working code is the best documentation available about a software.

The only item topic that should be well documented, and by well I mean just enough information, is the architectural design. This enables the development team to understand the reason for and how the various parts o the system are glued together. Without documentation this is a difficult topic to discuss. It is important to emphasize that only just enough information should be committed to paper.

(3) Design and code the solution

The solution design should not be a long, detailed and exhaustive exercise. Enough should be done to enable the developers to get on with the work at hand instead of focusing on the entire system. The team can hold stand-up meetings every morning and discuss what will be developed on that particular day, specific challenges should be discussed and the developers should move on with the work.

(4) Present the solution to the users

Once there is enough functionality to show to business users, the team should organise a meeting to present the work achieved and start the whole cycle again. This step may or may not occur depending upon you environment and specific business needs.

The steps above make up an iteration. The length of an iteration can vary from 2 weeks to a few months, this is another aspect of the agile methodology that can be changed to suit your business or the specific project.

The methodology described above is working well in an environment where business stakeholders are available to interact with the development team in a semi-formal way, enabling the business to communicate changing business requirements and giving IT an opportunity to ask questions during the course of the project.