AGILE
‘Agile’ is an English word that means to move quickly and easily[1]. By virtue of this definition, it is clear what the aim of agile is. Agile methodology(Agile) is a way of doing things by making them agile. Agile is employed in management (project or product) to ensure that the process moves quickly and seamlessly.
Since I work in the IT industry, this article will focus more on implementing Agile methodology in that space.
let’s go back to the beginning…
Before Agile methodology became popular, waterfall methodology was the standard in software development. Waterfall usually starts with the business analyst who writes a comprehensive document usually called the Business Requirement Document (BRD). A BRD usually contains the objectives and requirements for a business solution. It explains the business needs and expectations of the business solution that is, the metrics against which the business solution will be measured. It describes a business need or objective along with what is expected as the project proceeds. The BRD provides clarity whilst keeping a focus on the business needs.
After the BRD has been approved, then a Functional Requirements Document (FRD) is created. In some organizations, the same team creates both documents, or just one comprehensive document is created that covers both the BRD and FRD functionalities. An FRD contains the “how-to”. It is usually written by a solutions architect and contains the technical aspects of the implementation of the business solution. It takes into account the existing IT infrastructure, tools, languages and processes. The FRD documents the process flow and interactions that will lead to fulfilling the business needs as described in the BRD. Overall, the BRD and FRD work together to achieve the same goal — meeting business needs; with the former focusing on the business and the latter focusing on the technical aspect.
These two documents are passed to the software development team where developers are assigned to work on the project following the steps and processes described in the FRD. After the developers are done, the newly developed application goes to the Quality Assurance team for testing and the development cycle continues from there till its eventual release to the production environment.
Let’s imagine the business user decides to add a few more things to the specifications in-line with customers’ demand, it would be such a gruesome and time-consuming process. This is a reality of the process; things change swiftly in line with demand therefore communication should be seamless. However, communication is a flaw of the waterfall. Another problem with Waterfall is that it is time-consuming. Oftentimes, the tasks are based on skills so, for each requirement, if the resource is not available, the work will be kept pending till further notice. These two factors affect the Development lifecycle so much that by the time the project is done, it might no longer meet the needs or requirements of the market asides from being late.
In order to combat the woes of the waterfall, more software development projects started to ditch the waterfall for agile.
My next write-up will be about agile and how it compares to Waterfall. As someone who has practiced both methodologies across different organizations, I will also be writing about how I have seen agile adopted across these organizations, the merits and demerits.
I am always available for a quick chat via LinkedIn mostly, currently on a mini-sabbatical from Twitter. Watch out for my next write-up.
Thank you for reading.
