In my experience I have found that agile projects can be easily presented to the Exec / Board and fit nicely within an executive evaluation model that looks at the cost and results.

Many times this is a challenge for Agile teams as Agile can be difficult for an executive to accept, if you, as an Agile professional, imply that you will work with no defined time line or target results. Remember, if you do Agile right, you will become more predictable and your applications will consistently meet the needs of the business. Your exec’s dream come true!

Here is how we make this work on our projects. First, our Agile delivery process relies on having a running application at the end of each two week iteration or sprint. Each new iteration adds to the previous one and produces an incrementally more complete application. This shows progress early and often, which greatly drives project predictability. Note, it is easy to fall in the trap of proceeding indefinitely with these iterations until someone declares a version “good enough for production. This style of Agile development makes people and most all Execs very uncomfortable.

The way to counteract this is by first predicting the cost and time of the project – set a budget. Then you fix that budget while letting the scope change for each iteration. Here the steps we follow:

1. Do a quick scoping and sizing exercise. This does not correspond to a full-blown analysis. It is just an interview process with the Business Stakeholders, resulting in a list of the major user stories and use cases of the system. Our experience is that this is a 1 to 5 days exercise, depending on size and complexity.
2. Plan your sprints based on the priorities of each user story. Assume enough budget (days x people) for all use cases listed.
3. Create an Agile Project Plan. This looks like an oxymoron (a plan? In agile?) but it is not. Agile Project Plans are just sequences of sprints that cover all the use cases. We always add an extra sprint at the end for application tuning.
4. Present your scope, budget and timeline to the Exec / Board as you now have your “dollars” and “results” ready for executive approval. Once approved, you are on the hook to deliver on time and on budget.
5. Throughout the project, constantly reprioritize each project iteration based on the most important needs as identified by the business. Implement those in the earliest iterations. Here you are trading off the less important needs for what is truly important while keeping the overall budget and timeline in balance.
6. Why does this work? If you consider the Standish Group findings that state 50% of all features are “almost or never used.” If you prioritize constantly, you will have enough budget to implement the most used features. And you will still have enough budget for some unforeseen features and extra surprises.
7. We always find that some of the initial scope will be pushed out of the project (for a second release). That is okay, by the 3rd sprint, you typically have a willing business user that has seen progress in 3 demos as is willing to trade out “nice to have” features.
8. Go live and enter one last ‘tuning’ iteration with an expanded set of business users. Use their feedback to tune your application in this last sprint. The minor changes you make will go a long way to driving adoption and guaranteeing another Agile project!

This process will lead you down an Agile path that allows you to predict a budget and a timeline, deliver new applications within that budget while providing the best end result: an application adopted by all business users. If your Exec/Board wants to understand how it is done, take them through the list above. We have done this when first introducing agile in organizations and it works. And then, after the first project, the proofing does all the talking. Your Exec / Board will be happy and Agile will become a key delivery approach within your business.

Good luck!