Better be Wise than Agile

I think people are getting too religious about following Agile methodologies. Agile principles and best practices are valuable for applying important lessons that have been learned in software development. However, the drawback of following methodologies is that it takes experience and wisdom to know which of their practices work best in a particular situation. Best practices and even principles that are blindly followed may do more harm than good, even if they are Agile.

To illustrate this, consider the following two Agile principles (http://agilemanifesto.org/principles.html):

Business people and developers must work together daily throughout the project.
This may sometimes be desirable but this is not common. Business people need their time to do business. Business involvement is important for software development, but the amount of time that is required from business people can vary a lot between projects. Following this Agile principle too rigorously may do more harm to the business than is justified by the increase of quality and speed in software development.

The best architectures, requirements, and designs emerge from self-organizing teams.
If you have a small team of motivated and skilled people that know about the business and the technologies that are used, this is certainly true. However, I have seen this principle fail in several projects. These projects usually scaled up too fast with people that were too randomly selected. Having a RUP elaboration phase would have helped more than hoping for something good to emerge spontaneously.

If Agile principles are not generally applicable to all projects, this is even more the case for the rules prescribed by specific Agile methodologies. I will give some XP examples. If 100 JSPs need to be developed that are technically similar, it is not be the best choice to do pair programming for all production code that is developed. If half of your project can be based on existing production code, it may not be worth the investment to refactor whenever and wherever possible because its design could have been better. It may also not be a good idea to write unit tests for all its classes.

Don't get me wrong. I think the Agile movement has resulted in many ideas that can help software development projects a lot. However, for every team and for every project, the set of Agile ideas that will work and the level in which these ideas should be applied for an optimal solution will be different.

Comments (2)

  1. Machiel Groeneveld - Reply

    March 5, 2007 at 7:12 am

    I think Agile is a very non religious way of thinking and when you want to make pragmatic and effective use of practices you don't contradict Agile.

    However, you should be careful to dismiss some of the practices just because they are not convenient; they have emerged from experience with doing projects and their underlying value of principle is important. When business people cannot work together with developers and a daily basis to explain their needs and wishes and you also throw in a random selection of developers, you will have a big problem anyway, whether you do it Agile or follow formal procedures.

    If a 100 jsps need to be developed that are similar, a pair is more likely to find a better way of doing it then just doing a the same thing a 100 times. And no one is saying you just throw out production code, refactoring is a means to remove dead code, keep things simple and increase the knowledge of the code within the team. You should be ask yourself why it's not prudent to refactor the production code. Lack of tests maybe?

  2. Marco Mulder - Reply

    March 5, 2007 at 8:22 am

    Machiel, thank you for your comment.

    I agree with you that it is not always good to dismiss best practices just because they feel inconvenient. What I meant to say is that we should not make the same mistakes with Agile methodologies that were made with other methodologies: follow them without considering the specific needs of a specific project.

    Take for example RUP. It also emerged from experience with doing projects and its underlying value of principle is also important (demonstrate value iteratively, balance stakeholder priorities etc.). However, it has gotten a bad name because people follow it as a cookbook, lacking the courage or experience to choose only what works best in a particular situation.

Add a Comment