Regardless of what Agile Purists believe, many, many, MANY companies still think they know what Agile is about when they Just. Don’t. Have. A. Clue.
Clients believe they are getting what they want, being freed from the straightjackets of Waterfall methodology, to allow for flexibility in the changing business landscape.
Disreputable consulting partners use it to milk clients on an ongoing T&M model without any deliverable and commitment because “Agile Manifesto means we embrace change”.
” We are being ‘agile’ and will keep doing what the client wants (as long as they keep paying us).”
From the client’s point of view, this does not work well, especially if you have multiple systems to integrate with, and any minor changes could have ripple effects that can be quite costly to fix.
Changes in these type of environments must be
– reviewed diligently, and
– risks evaluated and mitigated.
I’ve seen so many ‘changes’ in requirements written into product backlog without due diligence, in the name of ‘Agile’.
And at the end of the project, you either end up with
1. A monstrosity: a system that has just grown organically – unchecked, in an unplanned manner due to doing a lot of ‘trial and error’ing, or
2. You end up with exactly what you want. The perfect product.
Just a whole lot more expensive than what you’d have spent if you planned and architected the implementation out in the first place.
I don’t claim to understand “Agile”, but I believe it has its place in an internal BAU or DevOps environment, or in a product company or an ISV.
But I’ve never seen it work properly in a consulting engagement.
Not unless the client truly buys into the Agile Manifesto, and understand the investment, the pros, and the cons.
If you don’t put in the effort to understand what you’re getting into in the beginning, don’t be surprised if the end result isn’t quite what you expect.