Agile is a business thing - not just an IT thing

Business people think that agile is an IT thing. But really, it is a business thing.

Because the decision to "do agile" cannot be made at the point where IT takes over. The decision must be made when the project is conceived, in terms of its business goals.

Project inception generally has two phases in a large organization: when the business case is made, and when the project work starts. To make the business case, you have to estimate the timeline and the costs. To do the cost estimate, you have to do some up front requirements analysis. To do the timeline, you have to make assumptions about the delivery process. Agile changes both of these. Thus, agile must be considered during preparation of the business case.

When project work begins, the business sponsor often contracts for a detailed requirements analysis to be performed. The theory is that this can then be used to solicit bids on building to the requirements; but that theory is deeply flawed, and the horrible track record of IT projects bears witness to this. This up-front detailed requirements is a root cause of failure, because these up-front requirements are usually wrong on many levels. That is where agile comes in: agile allows requirements to evolve.

This means that if you perform an up-front detailed requirements process, you have killed the project from the outset: if done in a waterfall manner, you can be sure that the requirements will be wrong, and if done in an agile manner, you have locked in the requirements so they cannot change, and so agile cannot work.

This is why agile is not just an IT thing: it is a business thing. Project sponsors need to learn and understand how agile processes work so that they can think in terms of the agile cycle from the outset - even when they are making the case.