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

Re: [agile-usability] Re: Real data

Expand Messages
  • William Pietri
    Great post, Dave. ... This is true, but my point in mentioning this is that if you have a culture that s about blame, then Agile methods are a poor fit. Agile
    Message 1 of 218 , Feb 1, 2010
    • 0 Attachment
      Great post, Dave.

      On 02/01/2010 03:57 AM, davenicolette wrote:
      > --- In agile-usability@yahoogroups.com, William Pietri<william@...> wrote:
      > ...
      >> One of the big points of a number of software processes (and software
      >> development contracting arrangements) isn't producing more value, higher
      >> quality, or more efficiency. It's blame assignment. Or, possibly, the
      >> ability to duck blame.
      > ...
      > This reminds me that the way we work can be strongly influenced by the incentives that affect us.
      > In the sort of environment you're describing, a person who stood up and took responsibility for a problem would be punished. He/she might have no career at all after the incident. In a culture of blame, you'd better be able to duck it. With that in mind, I don't think it's a question of process or methodology. "Waterfall" didn't cause blame-ducking behavior, and "agile" doesn't cure it. It's a question of organizational culture and values.

      This is true, but my point in mentioning this is that if you have a
      culture that's about blame, then Agile methods are a poor fit. Agile
      doesn't cause or cure finger-pointing, but if you need to do a lot of
      it, I don't think you can fully adopt the Agile approach, and therefore
      the benefits may be limited.

      > I think people tend to assume the sole goal in improving processes is to achieve ever-higher levels of "productivity." Everything is subordinated to that goal. But this is not the highest-priority goal in every organization. I worked with a company recently where a key development team valued the ability to work from home 1 or more days per week, without the need for planning it in advance. They could have adopted pair programming as a technique to improve their productivity, but they chose to adopt pairing as an occasional practice because by-the-book pairing would have eliminated their ability to work from home.

      Interesting. For me, the goal in improving processes is to do better
      work, to create better business outcomes; I think productivity is a side
      effect. This weekend Alan Cooper pointed a notion of Drucker's that I
      need to look up: that the pursuit of efficiency reduces effectiveness.
      It rings true to me.

      Anyhow, one of my teams just struggled with that recently. They chose to
      leap the dilemma and learn how to do remote pairing. But that's a
      quibble, and I certainly agree with most of your broader point:

      > We have to be careful about sacrificing important organizational cultural values in a single-minded quest for "productivity". Long-term sustainable performance may be a more appropriate goal. It's all about balance.

      Indeed. However, I think there are some cultural values that are
      poisonous to Agile approaches, so we can't always honor the local
      cultural values and retain integrity.

      > In the case of large-scale government-funded programs, there is more going on than just blame-ducking. Remember it's government money - free money, if you can play the game well. It's in the contractor's interest to maximize the amount of money they can charge the government. I suspect a lot of the apparently-redundant overhead activities that don't appear to improve quality or value are in place to increase the amount the contractor can bill for the work. It's not my thing, but I can see how it could happen.

      Yes. For me, that's in the category of blame assignment. With an agile
      outsourcing approach, I can look each week and see what's being
      produced. If I'm happy, great. If I'm not, we talk about it and
      eventually end the relationship. We don't go back and fight much about
      who's responsible for the failure; the stakes are too low, and the
      previous transparency too high. It's only when we have a very long
      feedback loop and lots of money involved that a multi-year legal fight
      becomes worth it.

      Of course, sometimes blame assignment is necessary. If I'm building a
      medical device, for example, there's a reasonable chance we'll all end
      up in court as part of a blame-assignment exercise that, at least some
      of the time, has real societal value. I think I could end up with a
      strong Agile process that has lawyer-approved blame assignment
      mechanisms. But I doubt there's one that fits well with a blame culture.

    • George Dinwiddie
      Hi, Jon, ... I ve never found creating software to be a one and only time no matter how small the program. There s a lot of similarity between writing one
      Message 218 of 218 , Feb 12, 2010
      • 0 Attachment
        Hi, Jon,

        Jon Kern wrote:
        > ok, maybe it is silly to debate the term...
        > George it's a free country, use method anytime you please :-)
        > I personally will only use "method" when I want to describe some way
        > that I achieve something over and over. Often in an abstract sense,
        > often in a step-wise way. Often because the "something" is a desirous
        > end goal, and one that I (or someone else) wants more than one time.
        > I would not describe the /ad hoc/ "how" of the one and only time I will
        > ever do something as a "method" if it is not.

        I've never found creating software to be a "one and only time" no matter
        how small the program. There's a lot of similarity between writing one
        line of code and writing the next.

        And I've observed, that people generally continue to do something
        somewhat in the fashion they've done it before. Thoughtful people will
        consider the result their achieving, and modify their actions to try to
        improve some aspect.

        I've never seen anyone continue to approach the work as if they'd never
        done anything like it before, choosing some completely different way of
        working. And I've never seen anyone carefully follow the recipe in a
        process manual. At best, a process manual gives the worker some ideas.

        It's the process people actually /do/ that has an effect. If you and
        Scott and Glen want to reserve the word "method" for officially blessed
        procedures, go right ahead. It won't change a thing.

        - George

        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
      Your message has been successfully submitted and would be delivered to recipients shortly.