Re: Elevator Speech to the CEO - reframing the jargon
- I suggest that if you want to reframe your elevator speech to your
CEO, try to look at what is most important to him/her: tracking and
productivity. As an example, in my organization, when I report to my
superior on the status of my project I use EVM and show how my
project's current performace stands against my estimate scope,
schedule and budget.
Lets take that all apart then, why do I set estimates, track them and
report them? Because the CEO wants to make sure that they're getting
the most amount of productivity out of the work as possible. By
setting time based goals, they can measure this. However, a high
degree of PRODUCTIVITY is the real goal, not numbers.
What does SCRUM give you? It is a framework that demands highly
productive work from group members, and makes it very easy to see
when problems arise. It doesn't guarantee high productivity, but it
has been proven to deliver it.
In the larger picture, ensuring high productivity and the fast
identification of problems is the real benefit of most Agile
Anyhow, that's my elevator speech. Works pretty good when I follow
it up with saying: "If you use a product like Scrum Works you can
then quickly see exactly how we are progressing over the entire
timeline at any given point, thus freeing the manager to work with
thier group to further ensure productivity".
Mike Van, PMP
--- In firstname.lastname@example.org, Daniel Gackle <gackle@s...>
> One term I avoid when talking with business peopleis "refactoring". Though
> this concept wouldn't likely appear in an elevator speech, it doescome up
> pretty quickly if one is asked /how/ "frequent delivery of businessvalue"
> is achieved, or simply what the differences are between agile andnon-agile
> The definition of "refactoring" (improving design without changing
> is like fingernails on a chalkboard to a business person. It soundslike the
> very thing they /don't/ want to pay for: programmers making theircode more
> elegant instead of adding features. Talk about not adding value!debt is
> Thankfully, Ward Cunningham's concept of "technical debt" or design
> as brilliantly successful a way to explain the value of thispractice as
> "refactoring" is disastrous.