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

RE: [agile-usability] Real data

Expand Messages
  • Glen B. Alleman
    William, I work programs were risk is inherent in the process - military flying machines - I can say that when failure is unacceptable then innovation is
    Message 1 of 218 , Feb 1, 2010
    • 0 Attachment
      William,

      I work programs were risk is inherent in the process - military flying
      machines - I can say that when failure is "unacceptable" then innovation is
      raised to high levels - simply because failure means lose of the machine and
      in other cases loss of life.

      The role of Safety and Mission Assurance (S&MA), Flight Safety Officer, or
      Range Safety Officer bridges the gap between engineering and the pressures
      of cost and schedule.

      It may be a popular myth that "risk avoidance" is inversely related to
      innovation. This is not the process in some domains. The role of technical
      and programmatic risk management is a mature subject in some domains and
      nonexistent in others. Combining risk management with SM&A, with processes
      assessments like CMMI can - in some domains - provide the needed methods for
      risk taking, while also providing full visibility into the consequences of
      those risks.

      We keep speaking about this method or that process in the absence of any
      domain or context in that domain. This is the source of confusion in some of
      these exchanges.

      Glen

      > -----Original Message-----
      > From: agile-usability@yahoogroups.com [mailto:agile-
      > usability@yahoogroups.com] On Behalf Of William Pietri
      > Sent: Sunday, January 31, 2010 11:28 PM
      > To: agile-usability@yahoogroups.com
      > Subject: Re: [agile-usability] Real data
      >
      > On 01/30/2010 09:13 AM, Glen B. Alleman wrote:
      > > I'll send you the CMMI to RUP map we use in those domains. Our A&D
      > clients
      > > have their own internal software development methods using special
      > tools,
      > > since "software" usually turns into HW in the form of FPGA's and
      > ASICs on
      > > the avionics boxes.
      > >
      >
      > Thanks, Glen. I'll take a look.
      >
      > > As Gene Krantz is fond on repeating "failure is not an option."
      >
      > Well, there's failure and then there's failure. System breakage is one
      > kind of failure, and I agree for a lot of people that has high costs.
      > We
      > should avoid that. Especially when it includes death.
      >
      > On the other hand, risk and reward are correlated, and there's a kind
      > of
      > failure that's the flip-side of that risk. "Failure is not an option"
      > can mean "innovation is not a possibility".
      >
      > Interestingly, I received my most recent lesson in that from an ex-Army
      > surgeon, Dr. Richard Satava. [1] I ran into him at a conference
      > recently, and we chatted some about his time as a Program Manager at
      > DARPA. He said that a lot of research funders try to get DARPA-like
      > results, but with fewer projects that don't produce anything useful. He
      > scoffed at this; his view was that to get the big wins, you had to
      > accept quite a number of losses.
      >
      > What excites me about Agile approaches is the possibility of minimizing
      > the first sort of failure while embracing the second kind, the kind
      > that
      > generates learning. That's certainly what it has done for me and my
      > teams.
      >
      > But to bring this back around to the topic, if I were making
      > life-critical stuff, I wouldn't use a generic Agile implementation. I'd
      > absolutely go and study organizations like the ones you've mentioned,
      > because they have a proven track record with, say, not crashing planes
      > too much. But I'd start from my base Agile process (an evolved XP),
      > import practices, and see if I could meet the necessary quality goals.
      >
      > William
      >
      > [1] http://www.tedmed.com/speakers#satava
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
    • 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.