I don't think Agile and COTS are incompatible, specifically if you are doing package extensions (hopefully in middleware rather than in the core package) then doing the extensions in an "agile" way can make sense. On the core package though I've seen it actively drive the wrong behaviours and exist where the wrong mentality is at play. If you have done COTS you are making a statement that this is an area of non-differentiation, this means that the business should be changing to fit the package. If its an area where COTS must be extended (e.g. core manufacturing) then doing Agile is also often a challenge because of the business process rigour and business change management that is required. Often people start looking at Agile as something that will magically make their configuration "simple" and mean less business rigour, the result is massive cost over-runs.
So what I would say is that SOA helps Agile work in a COTS environment by focusing it on the bits where it should be used. Using Agile for a full COTS delivery, especially where you are aiming at vanilla is (IME) suicide. I've seen tens of large scale package implementations that tried to use Agile, the only ones I've seen succeed is the ones who apply Agile only to very specific parts of the programme. Agile on core F&A? I think you'd be mad. Steve 2008/11/6 Ashley at Metamaxim <[EMAIL PROTECTED]>: > Hi Steve > >> As an example if your business service is being delivered via a >> vanilla package implementation then Agile is (IME) death while >> Waterfall (which is death everywhere else) is the right choice. > > As someone who has worked in an Agile (Scrum) environment where COTS was > being used, I would be interested in your comments on the following. > > Is your view that Agile is "death" if you are doing a vanilla COTS > implementation coupled (specific) to SOA, or do you think that COTS and > Agile are incompatible in any situation, Agile or not? > > Rgds > Ashley > >
