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

Re: I prefer Lead By Example was Re: [agile-usability] Re: One Of My Biggest Agile Problem.

Expand Messages
  • Jonathan House
    Hi Jon, ... Good point, and well worth making. Honest and objective doesn t mean rude or demeaning. There is a vast difference between This isn t the way I do
    Message 1 of 46 , Sep 5 6:22 PM
      Hi Jon,

      Jon Kern wrote:
      > PMJI, a couple of observations ...
      > 1. "[end users] are encouraged ... to provide honest and objective
      > feedback, regardless of the impact on the development team."
      > "Regardless of the impact..." Well, as long as the end users don't use
      > poor manners or are rude to the developers. Some cases, a buffer is
      > need. In addition, I find that there is a skill that goes with running
      > product development in terms of handling user's needs. Many times,
      > user's have opinions veiled as "feedback" that they will freely offer up
      > (as do developers and i myself). Sometimes, these opinions conflict. The
      > adjudication of many opinions has to fall to someone on the team, or
      > somewhere in the process. Wasting lots of developer time listening to a
      > bunch of conflicting opinions is not that useful to the project. Even
      > with a "getting paid by the hour" mentality, this is frustrating to most
      > developers to be pulled in different directions. Someone has to be the
      > adult in the room :-)
      Good point, and well worth making. Honest and objective doesn't mean
      rude or demeaning. There is a vast difference between "This isn't the
      way I do my job" and "You have no clue about anything I need, do you?".
      It's surprising how often these feedback sessions need a mediator, or a
      heavily armed group of ninja peacekeepers.
      > 2. "We are discouraging the "develop first" conduct in favor of the
      > "communicate first" conduct."
      > as a coach/mentor of numerous project teams, i have a different style of
      > getting the team's conduct to a "better place". i always lead by example
      > and gently force this proper practice from the get-go. i don't want to
      > have them experience the pain and agony and wastage associated with not
      > realizing there are certain levels of "up front" work that makes for an
      > optimal project timeline and budget. i want to show them that an initial
      > effort to work with the business to describe the problem domain and
      > gather requirements is a good and logical thing. they even get to
      > witness -- and i explain much of my thinking along the way -- why i
      > might dig into some requirements more deeply than others. why i might
      > choose to do spikes on some aspects of the system and not others... This
      > "lead by example" technique is how i approach all aspects of getting a
      > project team and product development to be a success. For example, i am
      > now leading a team through getting a release candidate prepped and how
      > to set up a process for going to Alpha/ Beta/Production. I don't want
      > them to make mistakes that I can help them avoid due to my already
      > gaining the scars...
      > but, i think i can see why you may do this approach. It might seem like
      > it will "sink in" better. Who knows? However, I (and my clients) am
      > (are) usually in more of a hurry to get the team up the learning curve
      > by cutting right to what I have found to be the best practices that i
      > think will work in each particular cultural environment.
      Notice how I'm politely refraining from jumping all over your "gently
      force" statement above? :-)

      Interestingly enough, my "style" that is generating so much delicious
      angst here, is structured for the exact same reason - rapidly climbing
      the learning curve. My past experiences have taught me that the pain of
      lessons that I have learned or watched others experience are
      instructional, and trying to help a team to learn to avoid them would
      require an incompatible level of Shu-Ha-Ri understanding (a Shu has a
      hard time understanding the lessons that are effective for a Ha or Ri).
      So, rather than avoiding these painful lessons, I run my teams smack
      into them at high speed. :-) (again, kidding here, for the terminally
      humorless. I run them into those painful lessons as kindly and gently as
      I can...).

      That being said, I'm not a bit surprised that you enjoy success with
      your approach. There are a lot of ways to skin a cat, even an Agile one,
      and if anyone claims to have the "One and Only" path to adoption, better
      keep your hand on your wallet.


      Jonathan House
      Technology Operations Director, Amirsys Inc.
      Voodoo Usability Shaman, Agile Sadist
    • William Pietri
      ... That s a good point. The biggest complaint I hear about this list is that the volume makes it too hard to keep up. Might I suggest that any future
      Message 46 of 46 , Sep 6 2:04 PM
        aacockburn wrote:
        > I also have enjoyed this rampaging discussion immensely, even if
        > it has precious little to do with agile-usability. It has opened
        > some interesting doors for long-term inquiry in my mind. (Thanks
        > Jonathan for that).
        > Maybe now we can let this group get on with its regularly scheduled
        > program :)

        That's a good point. The biggest complaint I hear about this list is
        that the volume makes it too hard to keep up. Might I suggest that any
        future discussion on this topic go to a more appropriate list? E.g.,
        this one:



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