Loading ...
Sorry, an error occurred while loading the content.

Re: Elevator Speech to the CEO - reframing the jargon

Expand Messages
  • xenomino
    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
    Message 1 of 13 , Nov 30, 2004
    • 0 Attachment
      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
      methods.

      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 scrumdevelopment@yahoogroups.com, Daniel Gackle <gackle@s...>
      wrote:
      > One term I avoid when talking with business people
      is "refactoring". Though
      > this concept wouldn't likely appear in an elevator speech, it does
      come up
      > pretty quickly if one is asked /how/ "frequent delivery of business
      value"
      > is achieved, or simply what the differences are between agile and
      non-agile
      > methods.
      >
      > The definition of "refactoring" (improving design without changing
      behavior)
      > is like fingernails on a chalkboard to a business person. It sounds
      like the
      > very thing they /don't/ want to pay for: programmers making their
      code more
      > elegant instead of adding features. Talk about not adding value!
      >
      > Thankfully, Ward Cunningham's concept of "technical debt" or design
      debt is
      > as brilliantly successful a way to explain the value of this
      practice as
      > "refactoring" is disastrous.
      >
      > Daniel
    Your message has been successfully submitted and would be delivered to recipients shortly.