Sunday, March 15, 2009

Greedy agile, waterfall and local minima

Everyone in the agile world can't contain their words about waterfall inadaptation to real world software projects. I have to admit, I am a fan of XP, scrum and most of agile approaches in general but I feel that people are loosing the big picture provided by the waterfall framework. Agile is kind of a greedy approach that lead you to local minimum where you are stuck too often. I would like to see someone creating value and velocity cost trade off of short term decisions. Those decisions are ofter push through agile methodology without questioning. Currently, at pivotalpayments, we are stuck in a huge local minimum created by such an approach and it will take such an effort to get out of it. The velocity created by a design choice taken long time ago was emazing at firt but it is slowing us doing now so much now. A major refactoring is required and we will stop development for some iterations. At least Agile adapts and give you the illusion of the optimal path...but everyone should know that the greedy approach isn't the optimal one and that looking at your feet won't help much going to your destination.


  1. The particular problem that we are facing right now has little to do with agile and a lot to do with poor design. If your system is built in waterfall mode by architects with little sense of scale, it will still be unscalable. Take a look at Zope 2 for an example of a system built in waterfall mode that ended up requiring massive rewrite to achieve the bare minimum scalability required by a popular web application.

  2. My point was that Agile lead some architects to take the shortess path which is now in our new context considered a bad design choice. With the initial team, a better design will have taken longer to implement and postpone any deliverables which doesn't suit the rapid development need at the begining of the project. Scalibility wasn't an issue at the begining and was representing no buisness benefits....which lead to the no ressource allocation.

    On the other hand, the Zodb of zope has been design by anti-sql guys and everyone knows that object related db doesn't scale.

    As mentioned implicitly by your comment, a good waterfall project manager will consider a scalable design a critical condition of success even if it leads to slower
    development. Every good architect knows that the lately you integrate major architect changes, the more energy will required to achieve it. It is a trade off of short-term/long-term benefits.