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

Re: [XP] Convincing the business

Expand Messages
  • igouy2
    ... Is it that data convinces very few people or that very few people require data to be convinced - the credulous can be convinced by the power of our
    Message 1 of 49 , Jul 5 8:43 AM
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "jeff_olfert"
      <jeff.olfert@...> wrote:
      >
      > --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      > <ronjeffries@> wrote:
      > >
      > > On Tuesday, June 27, 2006, at 6:48:16 PM, glbrown@ wrote:
      > >
      > > > Have you read Craig Larman's book, Agile and Iterative Development
      > - A Manager's
      > > > Guide? If that doesn't convince them, then it probably isn't
      > doing to happen.
      > >
      > > I like the book. But it's all full of data. My belief is that data
      > > convinces very few people.
      > >
      > > Ron Jeffries
      > > www.XProgramming.com
      > > If it is more than you need, it is waste. -- Andy Seidl
      > >
      >
      > How do you convice the others, who aren't convinced by data?
      >

      Is it that data convinces very few people or that very few people
      require data to be convinced - the credulous can be convinced by the
      power of our personality, our charm, our authority.
    • duane.waninger
      There doesn t seem to be much advice in these posts to really help answer your question. I think Steven got it right when he said ... ========================
      Message 49 of 49 , Jul 11 7:12 PM
      • 0 Attachment
        There doesn't seem to be much advice in these posts to really help
        answer your question. I think Steven got it right when he said ...

        ========================
        The key to winning buy-in is to:
        - discover where the discernable pain is
        - suggest a few things that might ease the pain
        - discuss the tactics and strategies and tradeoffs of trying those
        things in various ways or combinations in their context
        - get them to just try one of those things for a short while to see
        if
        it helps (5 months is too long)
        - do your best to make it work
        - repeat
        =========================

        The Serenity Prayer say "... courage to change the things I can ..."

        My suggestion is to start small, with the things you can change. If
        you have buy-in from the IT guys, then start there. Change the
        development team dynamic. Move the development team to work in
        iterations. Start asking questions regarding requirements to the
        liaisons on a daily/hourly basis. Try to increase team
        productivity. Once you have some control on the things you can
        change, start talking about what you're doing to the liaisons. Drop
        Agile key words and phrases along the way. Nothing you try to say
        will convince anyone faster than proven results.

        When trying to change the organization you have to take a long-term
        view. Changing a organization, especially a large organization
        won't happen overnight. It might not even happen in your tenure
        with the organization. The best you can do is to teach the IT folks
        to use the methodology and let nature take its course.


        --- In extremeprogramming@yahoogroups.com, Bil Simser <bsimser@...>
        wrote:
        >
        > I guess this is probably the biggest question that gets asked
        around here.
        >
        > Does anyone have a good summary or set of tips on how to convince
        the business that xp/scrum/iterative is a good thing and why they
        should invest. I can't win the scenario if they're not going to bite
        the apple.
        >
        > The setup is something like this. The business provides a liason
        who works with the BA to resolve questions about the problem domain
        and will do acceptance testing of the solution. The problem is that
        they dedicate say a week to testing at the end of the system. This
        is obviously too late so I'm looking to propose an iterative cycle
        of one month for each release where they spend a day. Over a 5 month
        project, this amounts to the same (and hopefully shorter) investment
        of time. What I want is to convince them not only to breakup their
        commitment like this (which they're pretty relucatant to do anyways)
        but also to provide feedback into the next iteration.
        >
        > So I'm looking for some tips on how to talk to these guys without
        being overly pushy. I'm consulting at the firm I'm at and the IT
        guys are all for Agile, but the biggest problem they see is the
        solidity that the business users are set on.
        >
        > Yes, this is a tough problem and I know there's no real boiled-
        down, step-by-step, corn-fed answer that can be applied to any
        situation. I'm just looking for some help on ways to approach the
        problem.
        >
        > Thanks.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.