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

RE: [agile-usability] Re: Real data

Expand Messages
  • Glen B. Alleman
    I would agree in some cases. But I ve watched a major health insurance firm here explode and have to get bought by an even larger firm, because of the
    Message 1 of 218 , Feb 1, 2010
    • 0 Attachment
      I would agree in some cases. But I've watched a major health insurance firm
      here "explode" and have to get bought by an even larger firm, because of the
      complete failure of the claims payment system.

      G

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



      --- In agile-usability@yahoogroups.com, "Glen B. Alleman" <glen.alleman@...>
      wrote:
      >
      > Dave,
      >

      >
      > 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
      > industrial)?
      >
      > Glen
      >

      Glen,

      Yes. I've seen agile methods used effectively in factory floor systems,
      embedded systems, and corporate IT infrastructure development, credit
      authorization systems, point-of-sale systems, and most definitely insurance
      claims processing. These things don't explode, and it can be feasible to
      deliver results incrementally to obtain feedback about the direction of
      development.

      There are some product development initiatives going on even now that
      involve 500 - 750 people working in multiple countries to build products
      that include both hardware and software components, and that use at least
      some agile methods. These programs don't look much like the small-scale
      projects described in some of the early books about Scrum or XP, but that's
      because we aren't in the early stages of agile anymore. People have learned
      how to scale. In those cases, incremental delivery and feedback are internal
      to the program, since it wouldn't make sense to take a partial product to
      the field, like half a network switch or 2/3 of a cell phone. But even so,
      the product doesn't explode.

      I disagree that low cost of failure implies low business value. Business
      value is usually a question of revenue enhancement, improved profit margins,
      improved cash-flow, reducing operational overhead, or market penetration.
      Companies can try different business ideas and get software into production
      quickly using agile methods, with a low enough cost of failure that they can
      cut their losses easily and move on to the next idea, until they hit a
      winner. One of the advantages of agile is that it helps us control the cost
      of throwing something away and starting over, because we can see we're
      headed down the wrong path relatively early in the process.

      I understand there are domains and contexts where agile doesn't fit. But
      those who are looking at agile from the outside in might be surprised at how
      many cases agile /does/ fit, provided we are pragmatic about choosing agile
      practices and adapting them to each situation.

      Dave



      ------------------------------------

      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.