Fake Agile

This is discussed time and again but I still see gaps in people’s understanding. Most of them want to claim they use agile otherwise they feel inferior. When you do namesake agile implementation, what is the point in saying ‘Agile fails’!

I thought of sharing some of my observations,

What the dictionary says as a meaning for the word “Agile”? – Able to move quickly

Why do we want to move/release the software quickly? There are many reasons for this but the fundamental reason is ‘change in consumer behavior’. There are enough products in the market to solve a problem in more ways than one. Customers adopt whoever delivers first and solves their problem. No mercy for the brand value, relationship etc.,

We had times when the customer wants to automate their manual work somehow. They felt extremely happy to see some amount of automation. They had a big heart to ignore the gaps and imperfections in the software system. This is like celebrating the food which is handed to you when you are so hungry. You never bother to complain about the taste, presentation etc.,

What if you are not hungry and want to eat the best. Will you order 20 different items and wait for all to deliver at the same time. Won’t be you disappointed if all served together and most of it didn’t meet your expectations? How about having them relatively sequenced and customized based on your feedback? This is what agile recommends.

I have seen ‘bookies agile practitioners’ treat as ‘sin’ if someone deviates from the crowd. One such example is that the sprint duration. If someone says 6-8 weeks, you will see big outcry as if you committed a crime. I would say, a sprint duration is contextual and should be okay, if the predictability and the communication to the consumers is there. In the name of following principles, irrespective of the work completion, pushing the stories to backlog and continuing to work on the same in the next sprint would defeat the objective of agile. A retrospection post the sprint completion makes sense than simply pushing a delayed use case to the next sprint. You would have violated the usual sprint timeline but the retrospection post completion helps to understand the challenges and handle them better in the forthcoming cycles.

The vital element of Agile is “communication”, timely communication to the stakeholders on the progress. That solves most of the problem. This helps the stakeholder to have confidence in one another by achieving the goal. It also helps to take corrective action, if any required. How you do it purely depends on how the stakeholders want the communication to happen. Anything beyond this is your creativity. Any best practice that helps to achieve the above can be incorporated.

Some say the reason to follow agile is it allows one to include the requirement change. Yes, that’s true but what is the change at what stage and at what cost matters. I have seen crazy attempts to change requirements but a need to keep the schedule and cost unchanged ??

Some say Agile projects can ignore documentation. The need of documentation is very much contextual. Nothing is wrong in documenting anything which is required for future reference to manage your products / environments etc. The real challenge is the act of trying to standardize the documents for all projects which would lead to failure.

Amidst of all, happy innovating and improve the world thru IT. Will come back to you with some more observation in my next post…