IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
4 replies Latest Post - ‏2012-12-05T09:33:51Z by Victoria Bunyard
15 Posts

Pinned topic Virtual Roundtable - Agile Systems Engineering - Planning and Process breakout [Event closed]

‏2012-11-29T16:16:51Z |
**Even though this event is over, you are welcome to browse this discussion**
This thread is discussing the issues of planning and the applicability of different agile and lean processes to systems engineering.

Some key points raised so far include

- there should be an emphasis on the people over processes and tools
- people problems are really management problems
- as SysML is to UML, we need a systems flavour of process
- overplanning is endemic in systems engineering projects

Updated on 2013-01-07T22:38:41Z at 2013-01-07T22:38:41Z by sjpeich
  • BrianNolan
    9 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Planning and Process breakout

    ‏2012-11-29T21:37:12Z  in response to HazelWoodcock
     "emphasis on the people over processes and tools"--I understand this one--people resist change; people can figure out better solutions to problems than processes can dictate; tools are only as good as the people that use them.  However, in SE, and in large, complex projects/programs (which is when you really need SE), tools and processes can make all the difference.
    Here's some examples--it takes a long time to create interface documents--especially if you're doing it manually.  If you implement as part of your process  using sequence diagrams to flesh out interactions between components of a system, and include fairly full signatures, you capture much of the information that is needed for the interface requirements and design documents.  This information can then be extracted automatically and inserted into the appropriate document templates.  You save lots of time, and make people's jobs easier.  Once you get over the initial learning curve of thinking in sequence diagrams for this, you get significant gains in productivity.  You do have to show the benefit to get people to do this, but on a large project with many interactions, you can speed up the process considerably, and reduce errors when changes are made.  We have multiple attestations of this kind of productivity gain.
    Another example where tools/process can make a big difference (again with sequence diagrams, because that is where I have had a lot of experience)--in DoDAF, and UPDM, if you create an OV-6c view, you can essentially generate at least an OV-3 from it, and possibly an OV-2.  There are some folks in the community who will disagree with this, but we did this a number of years ago and demonstrated it.  Also, if you create the right linkages as you go (preferably automatically, based on the process you are using), you can generate  SV-5(a or b, I believe) to an arbitrary number of levels.  Again, we have done this.  And if you use the right process supported by the right tooling you can transform what is often perceived as a compliance checkoff to useful engineering information.
    If you use a process we used to call "flow down" (can't recall what we changed it too) in modelling the functionality of systems and subsystems, you can automatically and dynamically generate extensive traceability information--this becomes very important as the system gets large, and maintaining manual traceability links in any tool becomes a significant issue, not to mention possible performance issues as the number of manual links explodes.  Here a well-thought out and tool-supported traceability strategy should produce significant savings.
    These kinds of linkages, both inferred and manual, are at the heart of what Mike Mott (elko.mike) proposed with regards to the "rebaselining" issue, where many millions of dollars (or euros, or whatever) could be saved if you can make a dent in the time it takes to evaluate changes to a big program.  This is not a people solution to a big problem, but a system/process/tooling solution (with a nod again to Mike and his mention of Deming).
    My point is, that you need to combine an emphasis on the people with some fairly rigorous models (in the larger sense, not just uml/sysml--abstractions perhaps) supported by processes/best practices and tooling to get the kinds of changes needed in productivity and value production in today's environment
  • KeithCollyer
    14 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Planning and Process breakout

    ‏2012-11-30T11:21:05Z  in response to HazelWoodcock
    Many, many years ago I had a sideline reviewing books for UK Computing weekly magazine. One of the books I reviewed was Tom Gilb's Principles of Software Engineering Management. At the time, I thought this was one of the best books on software engineering management I had read. Over time, I have revised my opinion. It is the best book on engineering (not just software) management I have ever read. It pre-dates most agile thinking, but can be read as providing a sound philosophical footing for a lot of the agile arm-waving (like the four tenets in the agile manifesto). Gilb manages to provide a balance between rigorous requirements and incremental delivery in a way that seems so obvious you wonder why it isn't done everywhere. It isn't the easiest book to read (and knowing Gilb's writing, it would have been a lot harder without the contribution of Susannah Finzi), but don't let that put you off. Read it, wonder what the hell it is you just read (though some parts will make sense), read it again and start to see, read it for a third time and the light-bulb explodes.
    Tom's son Kai has written a newer book that explains the "Evo" approach in a more accessible way, and in a lot more detail ( Kai Gilb, evo: Evolutionary Project Management & Product Development, available as unpublished manuscript at Maybe some people will find this easier.
    The other source of inspiration and rigour in this area is David Parnas and Paul Clements classic paper A Rational Design Process: How and Why to Fake It. This is important as it emphasizes that, regardless of your development approach, you should make it seem as if you used a rational approach to the development. Not to fool anyone, but because it is the only way that people who come after you, and don't necessarily have the benefit of your presence, have any chance of understanding what the product is about, how it was developed and, importantly, why in hell you made those wacky design decisions that plague us now.
    • BrianNolan
      9 Posts

      Re: Virtual Roundtable - Agile Systems Engineering - Planning and Process breakout

      ‏2012-11-30T11:50:27Z  in response to KeithCollyer
       Thanks for providing the reference to the Parnas paper--it is a good one, I enjoyed reading it
      Updated on 2012-11-30T11:50:27Z at 2012-11-30T11:50:27Z by BrianNolan
  • Victoria Bunyard
    Victoria Bunyard
    13 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Planning and Process breakout

    ‏2012-12-05T09:33:51Z  in response to HazelWoodcock
     So in reality we need to spend some time looking at the systems engineering processes that we have experience of, plus the literature that we all believe in - Tom Gilb indeed springs to mind - and to relate that to agile principles in a way that is scalable to include the mechanical, hardware, human factors etc. elements of systems engineering that  we know are not covered by Agile - and are not adequately covered by our own Agility@Scale story?
    The issue of over-planning being endemic is one that is strongly related to why our agility at scale story is not appropriate for certain systems industries at this time. Any system with a safety critical burden is going to limit the ability of the teams to be ''more agile''.  I do not believe that you cannot do it - but it means that the process needs to be very disciplined, and it may mean that for some sprints you have to be able to extend the sprint length instead of moving things to a backlog..........
    I do believe it comes down to some very basic principles:
    1 - Automation - automating as much as possible to reduce human error and to allow people to think about the important stuff (design and delivery) not the trivial stuff (which tool this information should be added to)
    2 - Control - a lot of the over-planning issue is also to do with control or perception of control (i.e. it is an overreaction to the either the lack of control, or the fear of losing control)
    3 - Transparency - so you can see what is going wrong quickly and fix it quickly
    4 - Traceability - so you can see how the heck you got to where you are, and how to get back!
    None of this is new - Brian and Keith absolutely cover all of these issues - and it is what we try to implement in our own products - but to do it properly requires very tight product integrations, coupled with an ''Agile4Sytems'' or ''SafetyCriticalAgile'' based on the principles and methods outlined in agile and by Keith and Brian - preferably with associated dashboards  - now that should be something really interesting for people in the systems engineering world. 

    Updated on 2012-12-05T09:33:51Z at 2012-12-05T09:33:51Z by Victoria Bunyard