Going Agile

By Ritika Taondwal on November 29, 2010

Many of us have heard about or been a part of the new, faster, result-oriented way of creating successful products – Agile Product Development. ‘Lengthy business requirement documents going through multiple levels of approvals’ or ‘a development plan where the end product can be seen only after months’ are certain things that you would not hear in an agile world at all. We all know about the standups, scrum masters, sprint reviews, etc., but what is the core principle of agile?

In many organizations, in the name of implementing agile methodology, managers merely change the name of the waterfall model to agile. Essentially, they still go through the phases of Requirement, Design, Implement and Test. While with some other organizations, people are delivering daily builds to customers in the name of agile development. With so many extreme adaptations of agile possible in the industry, what could be the set standards for a process to be really agile? Or is there a term like an agile process? In my experience with agile management, I have observed that it isn’t really about the Sprints or the review meetings. The heartbeat of agile development is ‘people’. If you want to ‘agilize’ your projects, this is the foremost consideration to be kept in mind. Agile is supposed to give your team a sense of ownership and responsibility and makes them capable of thinking outside the age-old written down requirements. Instead of spending huge amount of time planning something, agile focuses on getting it done, thinking about the present and the future and not what was decided months ago.

I have not seen a time tested/recommended formula of agile development. I feel it is best to drive it according to what you and your employees do:

  1. Understand the current loop holes in your process. Talk to your team – from top-level positions on down. Best ideas come from the least expected resources. Also, it is easier for people to adapt to a process that comes from them instead of something that is forced upon without reason.
  2. Instead of spending time on formulating and approving, start using it in one of the smaller projects and keep providing feedback into the system. Usually after 2/3 sprints, you will understand the problems and the solutions.
  3. Critically analyze the project outputs. You will know whether to go ahead with it or not.
  4. You get your agile process at the end, but remember to keep an open mind to any changes that can knock at your door any day.  All that said, everyone needs to exercise some level of control and method to the team. Agile should not necessarily mean chaos.

An agile method should not be chosen based on the size of the project, rather on what kind of end product this project will be delivering. A customer facing organization, like Winshuttle, will almost always prefer an agile-based environment as they want to be equipped to handle any enhancement that can make their customers’ life easier in a shorter yet reasonable time period. We just need to remember that it is the people who make the process for themselves; it should never be the other way around!

Questions or comments about this article?

Tweet @Winshuttle to continue the conversation!