I recently saw a technically-focused manager, who was talking to a marketing person, point to an early version (sprint 1) of an application and say:
You see, agile means you don't get everything you wanted.The remark surprised me since this manager had been heavily involved in the planning of the application, including prioritising which functionality got built every sprint.
This got me to thinking once more how I often have to describe agile in 30 second "
elevator pitches" to non-technical people. In the past I've tried to describe agile using terms like "hyper-productive environments" and "delivering increments of functionality", but that never seemed to convey the meaning behind agile. More and more agile seems to me to be all about risk, so I think my elevator pitch is evolving into something like:
Agile is a set of low risk practices for delivering working software within the usual constraints of project management (scope, resources, time and quality).What do I mean by low risk? The opposite of high risk :) High risk practices include spending too much time on analysis, not recognising that requirements will change as people get a chance to interact with the application, trying to build a complex solution based on possible future requirements instead of just what you need for now, putting people in strict roles instead of allowing them to freely interact with each other, and many more. Of course a project may still succeed using high risk practices, it just has a lower probability of doing so.
So back to the remark that started this train of thought. How would I respond to "agile means you don't get everything you want"? Simply: Regardless of whatever practices or methodologies you use you are still constrained by the usual project management variables (scope, resources, time and quality). Agile or not you will have to make choices.