Nowadays every development team is “Agile” 😛. But in reality they don’t follow most of it and most of them don’t even know what is Actually “Agile”. Today I will not talk mostly from the book but from my experience working in several types of development team, both remote and onsite.

So, To understand Agile first let us learn what “Agile” actually is. Agile is more than just a framework. It is way of dealing uncertainty and ambiguity of present software development process. In the modern era, people have ground breaking ideas but they don’t have proper requirements to build the idea into a product. So, as from software engineers they require something to build from their vague idea. But how the hell the coders will read your mind? And there comes “Agile” to give the idea experts support and give them a workable product with iteration and changes as it needs in minimal time and effort.

From this we can understand what Agile is. There are 4 pillars of Agile in general.

Individuals and Interactions over processes and tools
Working software over comprehensive documents
Customer collaboration over contract negotiation
Responding a change over following a plan

From the four pillars you can get that easily it is a general workflow of software development. For practicing agility your project must need to have some basis, after which you can take the decision of following Agile. And it is not crime to not following it everytime. Yes I mean it, Not everytime you require to follow agile. Now let’s discuss when to follow from real life experience:

Suppose you have a client who is building a product where the client has an idea of changing the whole country with his unique supply chain application will be built based on blockchain and web3 technologies. But he doesn’t know totally what he wants to build. Now you have been assigned to develop it. Now at first you and the client will fix a base idea of what the product will be and create minimum viable product which we call “MVP”. After then the client will taste it to the market and with the feedback given by the users he will move towards the next feature one by one. So in this case you don’t any actual requirements. But you have few stories. That is actually “User Story”. From that you create an prototype (might be figma or XD or any other platform) and test it and then you design some sprints and of course some functional deliveries after each sprint. Your client test with a fixed group of internal users and give feedback and in the starting of each sprint you work with the feedbacks and furnish the product to the next stage. That’s how you build the final and successful one.

Okay. Sorry I used a term “Sprint”. What is it? In lamen language it is a period of time when you will give a chunk of functional deliveries to your clients. In Agile environment you must fix the duration of the sprint by sitting with your team and assessing their speed of a functional delivery. In ideal environment it is 2 weeks. But it might be 1 week or 1 month as well.

So yes, in reality this is what Agile is. So we need make sure the below statements:

Your requirement is not clear and will change frequently
You must provide chunk of functional delivery after a fixed period time
Rather than budget user experience and frequency of delivery is important
No fixed deadline to finish the final product (As it might change many times depending on the user feedback)

So, before taking Agile into Action you must assess if your team ready for these changes. So finally I must say:

“Agile is not a method, rather it’s the mentality”

Thank you everyone. Follow my profile to learn more on project and product management.

References: