Skip to main content

AGILE - NOT AGILE





Many people in the software industry have heard about Agile. It is ubiquitous and can't deny the fact that it is redefining the way of how software is developed.

But most of the people do not know what Agile is not. Software developers who have worked in AGILE have their own definitions. Rather, every company / organisation has their own definition for AGILE [which is good and bad at times].

Looking at the last two decades when the software industry had begun its maturity, there were few methodologies for developing softwares. These methodologies were based on Process and Principles. A lot of focus was given to documentation which led to excess and result in efforts as well as maintenance. In Agile focus is more on delivering smaller piece of software which requires very less documentation. This means AGILE is not an excuse to producing documentation. It can be in various forms such as user stories, Epics, meeting notes etc.

Software professionals often mistake Agile as a process driven method. It’s not! Agile is more of an iterative and adaptive approach as compared to the traditional waterfall where there are various stages where the software could see the light of the day after months of work without knowing if this is what customer wants.

The Waterfall method is notorious when it comes to changing requirements where as Agile is seen as the saviour, but that is not just what  Agile is. It eliminates the risk of changes in the last stages when the software is about to be delivered. It is more about collaboration with Customers and Team members

Popular posts from this blog

User Stories Simplified!

User story writing guide
When I was introduced to the world of Agile, I kept on hearing the words  “User Story”. I couldn’t apprehend what it meant and how it possibly could be a fit for requirements management. This was all due to the traditional waterfall methodology which was omnipresent in most of the software projects. Early in my career we totally relied on creating massive amount of documentation which included but not limited to *Business requirements document Software requirements document High level design document Low level design document Use cases
 You can clearly see where the problem lies if you are planning on to maintain all these documents. On top of that, if you are working on mammoth projects, good luck with that!
How does user story  might prove to be user full?
First of all, User story is not a Silver Bullet but a convenient way to represent requirements. More precisely what a user intends to do.
In my case study, I am going to use example of “loremipsum” which is a social …

Agile Workflow process for Software development

In one of my project we experienced instances of  “Push vs Pull”. Confused?  Teammates had to tell other teammates that they have done certain tasks or they had to ask for certain tasks.This creates a lot of confusion when you are working on medium to large size projects. These tasks are more like “I have pushed the code, please review it” or “You got some support tickets, and as a manager, you have to assign it to  developer”

For smaller projects “Excel/Spreadsheet” worked fine. Issues can be tracked properly and is maintainable. But on medium to large size projects there are some set processes which need to be followed. These can be Linear processes where things mostly move in 1 direction or multidirectional.

You need some basic processes to make the project successful. Well begun is half done! The way you lay down your foundation, database structures, Infrastructure, the team and the development process gives solid direction to the project . I have been using JIRA since its early day…