If you have the right culture and a "can do" attitude in your organistion (hands up, anybody?), then there's no reason why XP projects can't be driven by a process of AgileBusinessDevelopment. The customer team is formed from key business stakeholders who have the necessary expertise (and the management support to make timely business decisions) to improve on existing business processes in rapid increments of 4-6 weeks. Within these improved processes there may well be "chunks" of workflow that might involve a software system of some kind. These "chunks" represent user stories that can drive software development.

At the end of each business development iteration, the customer team delivers working (and in some way improved) business processes into the business development equivalent of a test harness - the ModelOffice. Simulated execution of BusinessStories help the customer validate the system in the context of the improved business processes to check that:

	1. They satisfy their functional goals (eg, you can create the monthly sales report using the system)
	2. They meet their performance & quality targets (eg, you can create the monthly sales report in less than an hour, and it will be 100% up-to-date)

The tools and techniques of AgileBusinessModeling can be borrowed from techniques like AgileModeling, The BalancedScoreCard, ExtremeProgramming and a variety of other good sources - as long as it works, it's lightweight and easy to learn then it's in!

To start an AgileBusinessDevelopment project, work with the business to define high level objectives for the project (and by that I don't mean "the system must be available 24/7"...), design good performance measures to test progress with, and then break these goals down until they can be expressed as ExecutableGoals - that is, goals that are essentially actions or initiatives that can be fed into business development iterations. The customer prioritises (and maybe cherry picks) goals based on their relative business value and the effort required to achieve them, and builds a work queue very similar to that used in other agile/iterative methods.

The business development team does not make technical decisions, and the purpose of AgileBusinessDevelopment is NOT to come up with system requirements - it is to improve the performance of the business. The fact that system requirements - both functional and non-functional - can fall directly out of AgileBusinessDevelopment is a useful side effect.

Naturally, AgileBusinessDevelopment and AgileBusinessModeling must embrace the values of other agile processes, especially in being open to changes to business objectives.

--- JasonGorman

''Can this be applied at the executive level ie CEO, CFO and immediate staff taking an Agile approach to developing BusinessPlans? (that then drives lower level processes such as Sales and IT projects, presumably those departments taking an Agile approach also to implement their mandates)''

-----
CategoryAgileMethodology