Re: I prefer Lead By Example was Re: [agile-usability] Re: One Of My Biggest Agile Problem.
- Hi Jon,
Jon Kern wrote:
> PMJI, a couple of observations ...Good point, and well worth making. Honest and objective doesn't mean
> 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 :-)
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 theNotice how I'm politely refraining from jumping all over your "gently
> "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.
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
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.
Technology Operations Director, Amirsys Inc.
Voodoo Usability Shaman, Agile Sadist
- aacockburn wrote:
> I also have enjoyed this rampaging discussion immensely, even ifThat's a good point. The biggest complaint I hear about this list is
> 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 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.,