For many years, business stakeholders have seen or been involved with building products using the so-called ‘waterfall’ model; business stakeholders are intensely involved at the beginning of the development to specify the detailed requirements and do not get involved again until just before deployment to do User Acceptance Testing (UAT).

People get USED to a way of working even if they experience problems with it; it is human nature to ‘get on with it’ and/or develop personal ways of mitigating the problems that they experience.

Many business stakeholders are sceptical about ‘wholesale’ changes to the way that they are being asked to work especially as, superficially, their involvement with the product development is significantly increased.

Also, many senior business managers are risk averse and require predictability from the product development process.

The reasons why the waterfall development model evolved are beyond the scope of this question; to explain Agile to a business stakeholder, you need to know the major elements of the waterfall model that can cause ‘problems’ for the business:

• Gathering detailed requirements takes a significant amount of time where money is being spent for no additional income
• Detailed requirements change over time:

• If there is little or no business involvement during development, capturing required changes is difficult
• If the changes are not implemented, the business get the ‘wrong’ product
• If the changes are implemented, it leads to extra cost and delays in deployment

• The project plan, CREATED just after requirements gathering, is based on estimates but is taken as a quote by many which leads to ‘recriminations’ if the development costs more and/or takes longer

Each business stakeholder will have had frustrations based on one or more of potential waterfall problems; before trying to explain the whole of Agile, it is recommended to start by discovering which areas of the waterfall development process is causing the frustrations and explaining the aspects of Agile that will HELP overcome them.

One model of product development to base your explanations around is ‘The Iron Triangle’ 

Waterfall sets out to define all the detailed requirements and plan how they will be implemented; the resulting ‘contract’ assumes that features, time and cost are all fixed.

However, as already said, it can take a long time to capture the detailed requirements and plan their implementation; however, things never go ACCORDING to plan (requirement changes, staff changes) and so, when trying to implement a ‘fixed’ requirements list, the result will probably be time and cost overruns.

An Agile product development approach turns the ‘iron triangle’ upside-down:

You can see from Figure 4 that with an Agile product development process:

• The business fixes the time for the product development; this time is based on business imperatives such as market or legislation imperatives
• The development costs, which are mainly made up of developer costs, are fixed by having a fixed, cross-functional team
• What is delivered in terms of the requirements is variable

The requirements variability is based on ‘high-level’ requirements and needs some rules to give the business some confidence; the main rule is the Minimum Viable Product (MVP).

One of the major advantages of an Agile product development process over a waterfall one is that the product is delivered incrementally allowing some return on investment before the product is ‘completed’.  Incremental delivery can also help with experimentation when the product details are unclear; parts of the potential final product can be deployed early to get ‘customer’ feedback that will help produce a better product.

One of the important factors when explaining Agile to a business stakeholder is to make SURE that they understand the major differences in output that they can expect compared with waterfall and the differences expected of them:

• Documentation will be minimal focusing on what is needed not what might be needed
• Probable participation throughout the development for discovering detailed requirements, planning and reviewing

Another approach to answering this question can be found at How to Explain Agile to Your Stakeholders.