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 mean 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

Today's business environment is very competitive and dynamic. Companies need to be 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.