+ Reply to Thread
Results 1 to 9 of 9

Thread: Agile for systems engineering (beyond software)

  1. #1

    Agile for systems engineering (beyond software)

    I'm at INCOSE 2007 (http://www.incose.org/symp2007/) this week - for anyone not familiar with them, it's a systems engineering organization, where software is just a component.

    Anyway, many message board and blog posts will follow, but I wanted to capture a thought now. I realized something interesting after day 1 - there hasn't been a single mention of agile that I've heard! In software events and forums it is such a hot topic!

    I heard mentions of waterfall, mentions of spiral…but no agile. Anyone have any insight on agile in the systems world?

    I should mention there are 3 more days to come, so perhaps it's being kept quiet until Day 3. Or maybe software can be agile, but systems projects can’t. Anyway, just an interesting observation that I don't exactly know what to make of.

  2. #2
    Quote Originally Posted by jbeatty
    I'm at INCOSE 2007 (http://www.incose.org/symp2007/) this week - for anyone not familiar with them, it's a systems engineering organization, where software is just a component.

    Anyway, many message board and blog posts will follow, but I wanted to capture a thought now. I realized something interesting after day 1 - there hasn't been a single mention of agile that I've heard! In software events and forums it is such a hot topic!

    I heard mentions of waterfall, mentions of spiral…but no agile. Anyone have any insight on agile in the systems world?

    I should mention there are 3 more days to come, so perhaps it's being kept quiet until Day 3. Or maybe software can be agile, but systems projects can’t. Anyway, just an interesting observation that I don't exactly know what to make of.
    The lineage of the systems world is out of hardware. They started building hardware ages ago and now software is the wrapper. Those hardware guys are fundamentally engineers. In any case, agile approaches are repackaged iterative approaches which I think absolutely can work for systems.

  3. #3
    Quote Originally Posted by jbeatty
    I'm at INCOSE 2007 (http://www.incose.org/symp2007/) this week - for anyone not familiar with them, it's a systems engineering organization, where software is just a component.

    Anyway, many message board and blog posts will follow, but I wanted to capture a thought now. I realized something interesting after day 1 - there hasn't been a single mention of agile that I've heard! In software events and forums it is such a hot topic!

    I heard mentions of waterfall, mentions of spiral…but no agile. Anyone have any insight on agile in the systems world?

    I should mention there are 3 more days to come, so perhaps it's being kept quiet until Day 3. Or maybe software can be agile, but systems projects can’t. Anyway, just an interesting observation that I don't exactly know what to make of.
    One other thing, if the systems guys used agile approaches and worked more closely with their users, maybe we wouldnt have such badly designed hardware.

  4. #4
    Quote Originally Posted by jbeatty
    I'm at INCOSE 2007 (http://www.incose.org/symp2007/) this week
    ...
    I heard mentions of waterfall, mentions of spiral…but no agile. Anyone have any insight on agile in the systems world?
    I see Tom Gilb is presenting several papers. Tom is one of those Agile avant la lettre guys who inspired the original proponents of the Agile Mainfesto. He might suggest that the systems engineering world is just waiting for the more agile Agile software engineers to catch up!
    Last edited by AlanAJ; 06-28-2007 at 11:38 AM.

  5. #5
    It seems like the values of the Agile Manifesto could be applied to systems as well as software but maybe hardware development is not so obviously iterative and incremental as pure software development.

  6. #6
    Mechanical hardware, and to a degree, IC/Semiconductor hardware is bound by the physical constraints of interconnecting, inter-operating members and geographic proximity requirements which don't lend themselves as well to the agile methods employed in software development. In other words, software operates in a virtual environment without the constraints of a 3D, physical material laden world.

    In software, agile methods allow you to modify or replace the guts of a black box software component (Object) with another with relative transparency - as long as:

    1. The core I/O specs, Methods, Properties and Attributes either remain the same, or
    2. The interfacing components can be readily tweaked to accommodate the agile modifications.

    Hardware design changes are more expensive to implement on the fly because they entail changes to materials, manufacturing processes, packaging and other real world 'expense' items.

  7. #7
    Quote Originally Posted by MarkWBallard
    Hardware design changes are more expensive to implement on the fly because they entail changes to materials, manufacturing processes, packaging and other real world 'expense' items.
    While I agree with you on this - I think simulators can facilitate shorter iterations (and probably do - maybe they just don't call it agile!).

  8. #8
    I almost forgot to tell everyone - I did hear a mention of it once at INCOSE (outside of the times I brought it up). It was a discussion on the differences between software and systems requirements (http://www.incose.org/symp2007/paneldetails.html#410).

    I believe it was Matthew Hause of Artisan on this panel who made these comments (I'm not going to claim they are precise quotes!):

    -It’s a harder problem in systems than hardware.
    -Agile is stealing ideas that are best practices and saying they invented them – incremental development has been around for 50 years.
    -There were iterative development papers in the 80’s. Iterative is the best way we know to do requirements anyway.
    -There is a requirements process, even in agile, they are discovered by an iterative method. It is essential we write them down, otherwise what will we test against?

    I thought these were all good points. I think most people in this forum will agree we have to write requirements, even in agile! And I think it's pretty clear about agile being harder in systems projects, as the previous posts all stated.

  9. #9
    I just got finished at INCOSE 2008 and I have to say, same story. I just posted a link to a really good "agile in systems engineering" article in this post: http://www.seilevel.com/messageboard...=agile+systems

    And a blog post summarizing this year's INCOSE consensus on agile in systems engineering here: http://requirements.seilevel.com/blo...lane-with.html

+ Reply to Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts