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

RE: [agile-usability] Re: Real data

Expand Messages
  • Glen B. Alleman
    Dave, Yes. For example in the same building there are programs with CMMI ML 5 for that program, a site CMMI ML 3, equivalent programs with no CMMI requirement,
    Message 1 of 218 , Feb 1, 2010
    • 0 Attachment

      Yes. For example in the same building there are programs with CMMI ML 5 for
      that program, a site CMMI ML 3, equivalent programs with no CMMI
      requirement, but similar outcomes. This is all in the domain of avionics

      I would conjecture that if the cost of failure is low, the business critical
      aspects of the project are also low. In the firms we work, there is little
      chance to have a non-critical business system or product project. Those days
      are over.

      So to reflect your last paragraph, do you see agile developers working on
      enterprise class IT systems - ERP, transaction processing (insurance claims
      processing for example), EDM/PDM system (typically in manufacturing or


      -----Original Message-----
      From: agile-usability@yahoogroups.com
      [mailto:agile-usability@yahoogroups.com] On Behalf Of davenicolette
      Sent: Monday, February 01, 2010 9:49 AM
      To: agile-usability@yahoogroups.com
      Subject: [agile-usability] Re: Real data

      --- In agile-usability@yahoogroups.com, "Glen B. Alleman" <glen.alleman@...>
      > Since all process and the products they produce are stochastic in nature.
      > Failure is mandatory.
      > How to "manage" that failure mode issue. We do it with formal processes,
      > designated roles and responsibility, and massive oversight. Other domains
      > and context have different approaches.
      > Loss of Mission is common in many domains. From failed ERP systems to Pad
      > Abort of the manned spacecraft. Loss of Crew is different.
      > Glen

      You've mentioned domain and context several times in this thread and in
      other discussions, as well. I think it bears repeating. Some people tend to
      think exclusively of the domain they are working in, and forget that other
      domains have different requirements. Maybe that's what leads them to look
      for a one-size-fits all solution. The trouble is, one size doesn't fit all.

      When the cost of failure is human life, you've got to manage risk
      differently than when the cost of failure is low. In many business
      application software development contexts, the cost of failure is that
      someone has to re-write a chunk of code and deploy it to a server or two.
      Except in cases when there are financial penalties for system downtime or
      delayed response (as in some financial applications), the worst case
      scenario amounts to a bit of temporary inconvenience. That's a far cry from
      a manned spacecraft exploding on the launch pad.

      Sure, people weep and wail about the inconvenience, often out of proportion
      to the true damage, but that's only because they have the luxury of living
      in a world where things don't explode. They can well afford a lightweight
      process that doesn't burden them with a lot of oversight and triple-checking
      specifications. If something doesn't work quite right, they can have a
      "do-over." No biggie.

      Most agile practitioners use these methods for building and supporting
      business application software. Only a few have worked in a domain that has
      truly high costs of failure. I think that may be why people tend to talk
      past each other in discussions of this sort.



      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.