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

Re: [agile-usability] Real data

Expand Messages
  • William Pietri
    ... I think that s a great point, and it matches up with something I ve been thinking about lately. (And talking about with Jeff Patton just last night, so
    Message 1 of 218 , Jan 31, 2010
      On 01/31/2010 11:13 PM, Michael James wrote:
      > Having done aerospace embedded systems for most of the 80s and 90s,
      > and now Scrum, I'd probably use Scrum with an extraordinarily rigorous
      > definition of "done" to do aerospace in the future. [...]
      > Other aerospace work I was involved with didn't impress me as much.
      > Many of the requirements for 2167A probably reduced quality over all.
      > Combining what I've now learned doing Scrum with what we knew about
      > aerospace embedded systems could have led to a higher degree of
      > quality for the time/money spent.

      I think that's a great point, and it matches up with something I've been
      thinking about lately. (And talking about with Jeff Patton just last
      night, so some of thinking is his.)

      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.

      E.g., classic waterfall makes it easy to say it's somebody else's fault.
      It was the guy upstream. It was the guy downstream. Or bad scheduling.
      And since we don't really have a good way to measure the quality of
      inter-phase artifacts short of shipping, it's pretty much impossible to
      say who screwed up. If anybody.

      Even if what you're after is blame assignment rather than blame ducking,
      it pretty rarely helps. The theory is that you can fire the bad actor,
      or sue the bad vendor, or not pay for bad work. However, although I've
      seen or heard about a number of messy failures, I've never seen the
      punishment compensate for the failure. Generally, after a lot of
      shouting, the cost of failure gets shared some, with a tithe to the lawyers.

      In which case, everything spent on pre-blaming activity is wasted money.

    • 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
        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.