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

RE: [agile-usability] Real data

Expand Messages
  • Glen B. Alleman
    Michael, What if you were making a $100M investment - SAP for example. Our a mission critical investment, say a teleco provision system or credit card
    Message 1 of 218 , Feb 1, 2010



      What if you were “making” a $100M investment – SAP for example. Our a “mission critical” investment, say a teleco provision system or credit card billing system.


      Scrum is found in many of our flight systems, not named specifically, but 45 day iterations bound all deliverables through Work Packages. Planning Packages can be longer, but their deliverables are not as specific.


      The combination of small iterations, embedded in larger spirals, in conjunction with Earned Value Management measures of physical percent complete all embedded in the Integrated Master Plan / Integrated Master Schedule is now the process for all DoD systems. Add DO-178 and we’ve moved light years beyond the process.


      Glen Alleman


      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Michael James
      Sent: Monday, February 01, 2010 12:14 AM
      To: agile-usability@yahoogroups.com
      Subject: Re: [agile-usability] Real data


      On Jan 31, 2010, at 10:27 PM, William Pietri wrote:

      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.




      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.  Probably the highest quality software I was involved with (for an airliner) had us divided into small, cross-functional teams, each led by a verification engineer.  Another particularly effective team I recall being on was a collocated mix of hardware and software engineers with the type of manager who encouraged self organization and frequent reality checks.  Some of the practices we used in aerospace, particularly thorough automated testing, are only becoming mainstream commercial practices nowadays thanks to the Agile movement.


      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.




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