This is the point where agile begins to falter. I’m sure some of you will have your own views of where agile falters, but here is mine. Agile is a business process, not a software development process. In other words, if the business does not understand what it means to go to market with something that is already accepted as “wrong” and that we will “adjust” as we go, you are in for a very rude set of status meetings.

If the key decision makers on the business side of the business do not understand how to do their jobs in an Agile shop, you will have the illusion of chaos, which will lead to real chaos.

To be more clear: if the CEO and the CFO and the CMO and the VP Sales do not understand what agile implies and what it feels like, then you will most likely get blown up before you get very far. You will “get it wrong” and never get the chance to re-factor.

Agile requires a certain level of trust that comes from experience. This is true of any software process that is inherently iterative, but agile seems to need it more than others. Agile works great, for example, when the CEO, the CFO, the CMO are all the same person, and this person understands technology. Otherwise, tread carefully.