Agile practices are becoming popular day by day. In my last post I took up the question Agile Development- What is it? But the important question for a development team or manager should be Agile development- Is it for me? Is it the right choice? Should I use it just because it is working for someone else?

Every coin has 2 sides and so does agile methodology. If there are benefits of using it, it can also hurt the development process if not used intelligently. For example, if a project does not have many UI elements and has more complexity at backend like handling of MDBs and Web Services, having a client demo every week will not be very useful as we will not have anything new to demonstrate. Similarly, if the requirements are mundane and team has already worked on similar requirements already, pair programming will cause a negative impact on productivity.

While going for the agile approach, we will need to analyze if it will work for project in hand, rather than trusting it blindly. Ideally we should be checking each agile practice in detail and see if this is something I can use, and not go for the complete package.

For Example:

Continuous Client Feedback: If my requirements are not very clear, or are prone to changes or software has heavy UI element which needs to be verified by client, I should definitely plan weekly or biweekly demos based on project complexity and requirement.

Test Driven Development: Need to analyze how much automated test scripts will be required. Black box and white box test cases needs to be analyzed. Test cases can be created in parallel of code rather than before coding starts. If requirements are prone to change it might not be useful for me to create automated test scripts beforehand.

Face to Face Communication: if we are working in a model where teams are scattered across globe, we will not be able to follow this. Conference calls might be helpful.

Pair programming: In case we are working on a cutting edge technology which is new to team and having more than one mind concentrate on a problem will help, this is definitely the way to go.

Similarly we will need to take a call on what will work for my project rather than following the herd and going agile mindlessly.