Think AGILE - Part 1

During a recent group chat with my tech buds, the term AGILE popped up somehow from somewhere. Then started a long argument about AGILE and is it real or just a myth?  It was an interesting conversation with some of my buds who called it as a myth, a marketing slogan and a buzz with hype. I preferred to stay out of the chat thread and was observing the thought process around the topic. 

I let the chat comments into my mind and was trying to assess my thoughts on it. It was a pretty interesting thought process and decided to jot down my views on the topic based on my experience. When I asked myself "What's AGILE in my view ?", I came up with the following elements of AGILE which really worked with my assignments. 

The elements are of NO particular order. They are just in the order of my perception.

1. Evolutionary and Iterative

The very essence of any AGILE methodology is the abiity to build and refine repeatedly to acheive a certain goal.  This means that the various phases of software development can run in parallel which is contrary to the classical approaces. This iterative approach allows us to visualize the progress made while the software is constructed. This is comparable to the look and feel approach generally used in artistic creations. Typically iterations are designed in terms of weeks ranging from 2 weeks to 6 weeks depending on the variations of the AGILE methodology. This practice allows to easliy track the progress of the work during an iteration. The result of an iteration is either an acceptance or a scrap. The result leads to next iteration to build the next piece or rethink and reconstruct the scrapped piece. Hence the risk of a work is limited to the duration of the iterations in weeks as against months or even years in some cases. This very approach has caught up the attention of many software development projects around the world. This lean and flexible model allows the exeuction team to accomodate changes in the requirements often agile in nature.  

2. Collobrative and Inclusive

The AGILE is best suited for colloborative work. The teams participating in an AGILE method of development must understand and practice the culture of team work. The different work streams are involved in constructing different pieces of a software component. Typically the team gather for a stand up meeting to assess the progress of a particular iteration. Each standup is represented by a member of a developmemt stream, a tester, a BA / SME and an AGILE conductor. The agenda of a standup is two only answer few questions such as "What was done on the previus work day ", " What's on for the current work day ?" and "Are there any issues stopping from performing the current activity ?". The answers to these questins help the team be aware of the progress made and iron out the blocks if any. The colloborative nature is also attributed to the fact of involving the stake holder upfront in every iteration to provide a better visibility of the assignment. This is contrast to the classical approach where team meetings are stretched longer for capturing the status and involvement of the customer happens towards the end of the assignment. The AGILE conductor is responsible for driving the team forward and captture the status of the assignment. 

3. Informally Disciplined Approach

A very common perception among the traditional methods advocates is that AGILE does not have a structual, formal method of execution and does not follow any process. But the fact is that AGILE is very modular in nature and requires a very meticulus planning and tremendous amount of discipline in order to succeed. The AGILE is meant for a very seasoned and experienced teams which in turn implies that discipline is inbuilt and does not require to be taught. Another important facet of this methodology is that it places less importance on excessive docmentation and processes. In other words, the focus is less on documentation and processes and more on execution of the core tasks. This encouages the team to spend all its energy into the core activities and not get distracted and overloaded by unwanted tasks. The concept of Pair Programming is commonly applied by the developers where the peer reviews happen from the other developer. This places importantance to use the best practices during all the phases of the assignment. The best practices ensure proven benchmarks are used to assess the quality. This approach is different from the classical models where the emphasis tend to be more on excessive documentation and processes which has a direct impact on the result  and quality of the assignment.

4. Test Driven Development

This element is my favourite as a software developer. I believe that this is where the AGILE scores high in terms of meeting the requirements and enables tracking the construction towards the business requirements. The input to the developer is the test cases and scenarious as against a requirement document. The requiremnts are converted into s set of test scenarios and cases before the development can begin. This enables the Business Analyst or the Subject Matter Expert to understand and verify the business functions / tasks for a specific purpose / goal. This approach helps the project execution team better plan the construction and avoid costly mistakes of missed requirements. The test scenarious and cases are a series of elementary break-downs of each business function which is expressed ina natural human language. Another very important aspect of this method is that both the negative / exceptional  scenarios and non functional scnarios like performance, throughput etc are outlined in advance enabling the developers to develop a robust piece of software. This is quite opposite to the classical method where the negative and non functional aspects are thought of only post production and in many times post a disruption due to a software glitch.    

5. Focus on Small and Incremental Builds

I think this facet as a natural result of the Iterative Approach. The result of each iteration is a mangeable incremental piece of software packaged and deployed to the test environments. Each iteration throws out a well tested and incremental packages of application unit that strives to acheive a particular business objective. This gives the packaging and deployment teams the ability to deploy and verify the builds well in advance before moving into production environment. Once the package is deployed into the test environment, the regression tests are performed under the guidance and evidence of business users. The test results will allow the business users to ascertain if the software meets the objective or not. 

I know that there are few other important aspects like Scope, Requirement Changes, Manageability, Audit etc which is not covered as part of this post. I will try to cover them as part of another post.

Your thoughts ?