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

Re: customer groups

Expand Messages
  • Dave Churchville
    ... Couple of thoughts from my experiences, both as a developer and product manager: 1. I always tried to find the *most representative* person to act as
    Message 1 of 62 , May 19 10:38 AM
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, Brian Marick <marick@...> wrote:
      > 1. I've been the customer / product director on two projects, one
      > going on now. I find that I spend a lot of time making small
      > decisions, be they GUI-related or "functional". How does that work
      > with a customer team? Do programmers ask the most appropriate
      > immediately available customer? I'd hate to have decisions slowed
      > down because only one person can make decisions about GUI tweaks or
      > because consensus among the customer team has to be reached rather
      > than assumed.

      Couple of thoughts from my experiences, both as a developer and
      product manager:

      1. I always tried to find the *most representative* person to act as
      customer proxy. If that person didn't have a clear answer, then I'd
      go down the list to the next customer rep.

      2. Trust-based relationships were absolutely key. My customers
      trusted that I would do what was best for them and the company, not
      just what they asked for. At some point as a developer, you do make
      decisions implicitly, but only after gaining a deep understanding of
      your customer's needs and goals.

      3. As a product manager, I stayed very heavily involved in the
      development process until the trust and communication reached a "flow"
      state. I trusted that the team would ask questions if they ran into
      difficult or ambiguous problems, otherwise I assumed they would do
      something reasonable instead of asking about thousands of trivial things.


      > 2. The customer / programmer relationship often seems to me a
      > personal one. Rather than serving the company, the User, the stock
      > price, or some other abstraction, the programmers want to make that
      > person, Nickieben, the one sitting in that chair over there, happy.
      > Provided Nickieben is making decisions that serve the company, User,
      > etc., the personal relationship is an advantage, I think.
      >
      > Do the programmers form the same attachment to a team-that-speaks-
      > with-one-voice as they do to a human who really truly has only one
      > set of vocal cords?

      Again, in my experience, yes, the customer/programmer relationship did
      tend to be a personal one. Another developer couldn't just talk to my
      customer and have the same kind of interaction. The trust and deep
      understanding wasn't there yet.

      Even when I was no longer involved with one project, I was actually
      called in to "translate" customer requests so that newer developers
      could understand them.

      Software development has a distinctly human element, no matter what
      sort of processes we try to put into place. Humans prefer to work
      with people they know and trust. Good relationships make better software.


      --Dave


      David Churchville
      ExtremePlanner Software
      http://www.extremeplanner.com
    • William Pietri
      ... Which, honestly, I don t think is unreasonable. From the perspective of the waterfall person, all problems can be solved with a little more planning, and
      Message 62 of 62 , Aug 31, 2006
      • 0 Attachment
        Alexander Johannesen wrote:
        > If you can hide your work from them,
        > then great, but there is this notion of teamwork going on here that
        > requires a certain ... mediation to old progroms.
        >

        Which, honestly, I don't think is unreasonable. From the perspective of
        the waterfall person, all problems can be solved with a little more
        planning, and failing to plan it all up front looks dangerous and the
        fast route to failure. Until you have seen it work, it's easy to believe
        that agile processes are impossible. I sure did.

        When dealing with people like that I'll generally try one of two
        approaches. The first is "Well, let's try an experiment." We find some
        level of risk that they are comfortable with and try out agile methods
        in that context. If the experiment is a success, we try a bigger experiment.

        The other is, "You do what you think it takes." If they want a big spec,
        then sure, they can write one up as we have our discussions around the
        product. If they think a continuously updated spec is important, then
        great, they should keep updating it. If they want a big MS Project
        thingy, fine, we'll make sure all the necessary data is on our wall of
        cards.

        I don't know if those are helpful to you, but they've worked for me.

        William
      Your message has been successfully submitted and would be delivered to recipients shortly.