Topic
  • 130 replies
  • Latest Post - ‏2012-12-08T14:55:35Z by WalkerRoyce
JonChard
JonChard
6 Posts

Pinned topic Virtual Round Table – Agile Systems Engineering (28 November – 7 December) [Event closed]

‏2012-11-27T15:43:58Z |
 **Even though this event is over, you are welcome to browse this discussion**
 

Welcome to this round table discussion which will run until Friday 7th December.

In this thread we are discussing how and where Agile approaches can be applied to product and system development.

 

Some questions to get us started:

1.        Are Agile practices applicable to product and systems engineering in any form?

What are the high-priority areas? Are there no-go areas – if so where and why?

Can Agile apply to non-software engineering disciplines such as mechanical and electrical/electronic engineering?

What are the key challenges? Are they industry-specific, project structure or technology challenges?

 

2.       Can our traditional methods link up ‘around the edges’ of Agile systems engineering practices?

Even if it were possible, organizations can’t move everything to Agile processes overnight. So the reality of doing Agile for complex product development means agile processes will have to join up with non-agile processes ‘at the edges’.

Where should those edges be? Are there successful patterns that can be applied to achieve success? Are there ‘toxic’ interface scenarios to avoid?

 

3.       Can we apply the Agile principles to existing process to improve what we have?

Many aspects of complex product development have constraints that make a ‘pure’ Agile approach impossible. For example hardware iterations typically take much longer than software iterations. Contracts might define ‘non Agile’ deliverables. But can Agile principles be adapted and applied around these constraints to yield benefits? What are the key principles to apply? Are there adaptation patterns that can be reused in different projects and contexts?

 

You will need to JOIN this group to reply to this topic.

Updated on 2013-01-07T22:51:47Z at 2013-01-07T22:51:47Z by sjpeich
  • mbakal
    mbakal
    8 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-27T21:50:03Z  
     Are Agile practices applicable to product and systems engineering in any form?
    Short answer in my view is yes. Agile is all about getting earlier and more frequent feedback from customers, product owners and others. It also is about having cross discipline expertise.   All of these things are critical to product and systems engineering. Another key piece is building a piece of the design, i.e. a use case at a time. This also is very useful in systems engineering and can be useful in building a powerful systems model. There are many other advantages as well but this is a good way to think about how systems engineering can benefit fit from Agile practices.
     
    Can our traditional methods link up ‘around the edges’ of Agile systems engineering practices?
    Yes and I have seen this done in practice. Some companies decide to have periodic synch ups with teams like their hardware groups that might still be using a waterfall process or something similar. There are many different potential edges depending on teams, out sourcing, regulatory, etc. You just have to add this in and make decisions in a thoughtful manner.
     
    Can we apply the Agile principles to existing process to improve what we have?
    Short answer is yes again. Anyone can decide to get more frequent feedback from customers, decide to test a component and not wait for a complete system, or even deploy some pair programming (engineering). These are all potentially useful processes in any organization even in an existing process. You don't have to be following everything agile to get be benefits from some agile practices. You just need to have a process in place and know why you are using specific practices.
     
  • JimDensmore
    JimDensmore
    17 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-27T23:29:47Z  
     I think Agile practices are part of a robust engineering capability.  If architecture is lacking from some Agile shops in the IT space, architecture is even more important in the systems space, so a DAD that includes architecture is probably appropriate.  On #3, Agile ought to make it easier to accommodate iteration cycles of different lengths, one thing Agile does do well is focus on artifacts more and processes less.  Planning becomes more important, but it always does in Agile contexts.
  • baamaba@us.ibm.com
    baamaba@us.ibm.com
    1 Post

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-27T23:32:19Z  
    • mbakal
    • ‏2012-11-27T21:50:03Z
     Are Agile practices applicable to product and systems engineering in any form?
    Short answer in my view is yes. Agile is all about getting earlier and more frequent feedback from customers, product owners and others. It also is about having cross discipline expertise.   All of these things are critical to product and systems engineering. Another key piece is building a piece of the design, i.e. a use case at a time. This also is very useful in systems engineering and can be useful in building a powerful systems model. There are many other advantages as well but this is a good way to think about how systems engineering can benefit fit from Agile practices.
     
    Can our traditional methods link up ‘around the edges’ of Agile systems engineering practices?
    Yes and I have seen this done in practice. Some companies decide to have periodic synch ups with teams like their hardware groups that might still be using a waterfall process or something similar. There are many different potential edges depending on teams, out sourcing, regulatory, etc. You just have to add this in and make decisions in a thoughtful manner.
     
    Can we apply the Agile principles to existing process to improve what we have?
    Short answer is yes again. Anyone can decide to get more frequent feedback from customers, decide to test a component and not wait for a complete system, or even deploy some pair programming (engineering). These are all potentially useful processes in any organization even in an existing process. You don't have to be following everything agile to get be benefits from some agile practices. You just need to have a process in place and know why you are using specific practices.
     
    Are Agile practices applicable to product and systems engineering in any form? We see a variety of responses to this question primarily driven by time, resource and quality constraints. The details and metrics on the break even point is the most challenging question customers and the ecosystems are struggling with from what we have seen in applying Agile practices. A work force is changing at a different pace as the technology.  Although goals are becoming more aggressive, Agile may or may not work depending on the situation and constraints.There is a balance of risk, time, quality and resources that the teams are grappling with. As the complexity deepens, diversity, redundancy, and depth may place extra steps in the process and schedule. As we learn more about the systems and their interactions, velocity and agility improves providing more opportunities for agile techniques and modifications. We see the desire of agile practices, but not always the same outcomes when the details and ability to respond is not clear or transparent to the members.  As we learn more and assets are harvested, we expect Agile techniques to become more pervasive.
     
    Can our traditional methods link up ‘around the edges’ of Agile systems engineering practices? Yes, as Marty stated, you have to make decisions in a thoughtful manner and be able to respond to changes in the process and system.
     
    Can we apply the Agile principles to existing process to improve what we have?  Yes, it is continuous improvement with a particular focus on the details.
     
  • MaureenMonte
    MaureenMonte
    7 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T11:59:21Z  
    • mbakal
    • ‏2012-11-27T21:50:03Z
     Are Agile practices applicable to product and systems engineering in any form?
    Short answer in my view is yes. Agile is all about getting earlier and more frequent feedback from customers, product owners and others. It also is about having cross discipline expertise.   All of these things are critical to product and systems engineering. Another key piece is building a piece of the design, i.e. a use case at a time. This also is very useful in systems engineering and can be useful in building a powerful systems model. There are many other advantages as well but this is a good way to think about how systems engineering can benefit fit from Agile practices.
     
    Can our traditional methods link up ‘around the edges’ of Agile systems engineering practices?
    Yes and I have seen this done in practice. Some companies decide to have periodic synch ups with teams like their hardware groups that might still be using a waterfall process or something similar. There are many different potential edges depending on teams, out sourcing, regulatory, etc. You just have to add this in and make decisions in a thoughtful manner.
     
    Can we apply the Agile principles to existing process to improve what we have?
    Short answer is yes again. Anyone can decide to get more frequent feedback from customers, decide to test a component and not wait for a complete system, or even deploy some pair programming (engineering). These are all potentially useful processes in any organization even in an existing process. You don't have to be following everything agile to get be benefits from some agile practices. You just need to have a process in place and know why you are using specific practices.
     
     Great points!  Can you expand more on where you've seen Agile be less effective? What are the obstacles?  (HW, SW, culture - we don't do it this way, we've always done it this way?)  Looking to better understand where the shoe fits, so to speak.  Thanks for sharing!
    Maureen 
  • MaureenMonte
    MaureenMonte
    7 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T12:01:15Z  
    • mbakal
    • ‏2012-11-27T21:50:03Z
     Are Agile practices applicable to product and systems engineering in any form?
    Short answer in my view is yes. Agile is all about getting earlier and more frequent feedback from customers, product owners and others. It also is about having cross discipline expertise.   All of these things are critical to product and systems engineering. Another key piece is building a piece of the design, i.e. a use case at a time. This also is very useful in systems engineering and can be useful in building a powerful systems model. There are many other advantages as well but this is a good way to think about how systems engineering can benefit fit from Agile practices.
     
    Can our traditional methods link up ‘around the edges’ of Agile systems engineering practices?
    Yes and I have seen this done in practice. Some companies decide to have periodic synch ups with teams like their hardware groups that might still be using a waterfall process or something similar. There are many different potential edges depending on teams, out sourcing, regulatory, etc. You just have to add this in and make decisions in a thoughtful manner.
     
    Can we apply the Agile principles to existing process to improve what we have?
    Short answer is yes again. Anyone can decide to get more frequent feedback from customers, decide to test a component and not wait for a complete system, or even deploy some pair programming (engineering). These are all potentially useful processes in any organization even in an existing process. You don't have to be following everything agile to get be benefits from some agile practices. You just need to have a process in place and know why you are using specific practices.
     
     Hi Marty!  I'm interested in the aspect of where Agile works in "tangible" product development.  Can you expand a little bit more upon what you saw that worked?  What kind of products where they, and was it complete product or parts of the product that allowed the benefits of an Agile approach?  Industry differences? 
     
    This is a great opportunity for me to learn more about something I know little about!  Thanks!
    Maureen 
  • MaureenMonte
    MaureenMonte
    7 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T12:04:31Z  
     I think Agile practices are part of a robust engineering capability.  If architecture is lacking from some Agile shops in the IT space, architecture is even more important in the systems space, so a DAD that includes architecture is probably appropriate.  On #3, Agile ought to make it easier to accommodate iteration cycles of different lengths, one thing Agile does do well is focus on artifacts more and processes less.  Planning becomes more important, but it always does in Agile contexts.
     Hi Jim!  Great post!  And I think you make a great point about planning - I think that perhaps the ALM world has much more swiftly adopted a "planning" mentality, versus PLM, which traditionally has had the benefit of time on its side (but no longer true).  Have you seen approaches that were more effective than others in moving the ball towards agile?  Did you tackle people first, or process first, or tools first, or ...? 
    Thanks again for sharing.  
    Maureen 
  • WalkerRoyce
    WalkerRoyce
    14 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T12:41:23Z  
    "Purity" is for zealots and professors who think they live in a frictionless environment and, who make for pretty ineffective teammates in our friction-packed world of product development. Engineering, whether it is focused on IT applications, products, systems or services, is more about managing impurity (let's call that uncertainty). The discriminating goal of becoming more agile is an improved efficiency of change, especially in the headwinds of high uncertainty in the requirements, designs or plans.
     
    Agile principles apply to all software development where managing uncertainty to achieve a better economic outcome is the main objective. In the IT world, where most projects live in a cost center, the goal of productivity improvement is usually to reduce cost, or achieve more bang per unit time or per unit dollar. In other words, the IT context is predominantly confined to the denominator (cost) of a business).  In the systems world, where most projects live in a profit center, the goal of productivity improvement has two branches: 1) to capture new revenue sources through innovating new features or attracting new markets, and 2) to reduce cost by achieving more per unit time or per unit dollar. So systems teams have the added complexity of improving the numerator of a business (revenues) along with improving the denominator of the business.
     
    So bottom line...if agile principles help you become more efficient at improving productivity, then they apply to systems endeavors as well. Agile principles (managing uncertainty, measurement, more intimate collaboration) help steer innovation and uncover better paths to improved revenue. Agile practices (scrum, user stories, TDD, XP, et al) are mostly effective at improving execution efficiency, quality and cycle time and reducing scrap and rework.
     
     
     
    Updated on 2012-11-28T12:41:23Z at 2012-11-28T12:41:23Z by WalkerRoyce
  • mbakal
    mbakal
    8 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T14:53:34Z  
     Hi Marty!  I'm interested in the aspect of where Agile works in "tangible" product development.  Can you expand a little bit more upon what you saw that worked?  What kind of products where they, and was it complete product or parts of the product that allowed the benefits of an Agile approach?  Industry differences? 
     
    This is a great opportunity for me to learn more about something I know little about!  Thanks!
    Maureen 
     As Walker taking purest aside who say agile can only be done one way (especially given that agile is a collection of processes anyway), agile practices can help in building any types of devices from mobile phone to airplanes. Rapid prototyping, responding to customers and building in small chunks for examples are just good business practices. To be honest Agile came from lean manufacturing which wasn't even invented in the software realm in the first place.
     
    Please note I am not saying following a strict agile process is right all the way through. In some cases you do need to plan your architecture a bit before building, but some of the concepts are useful even then and are just best design practices anyway.
     
  • purban
    purban
    1 Post

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T15:26:31Z  
     Hi Marty!  I'm interested in the aspect of where Agile works in "tangible" product development.  Can you expand a little bit more upon what you saw that worked?  What kind of products where they, and was it complete product or parts of the product that allowed the benefits of an Agile approach?  Industry differences? 
     
    This is a great opportunity for me to learn more about something I know little about!  Thanks!
    Maureen 
    Systems engineering encompasses many disciplines hw, mechanical, software,etc.   Agile approaches have traditionally been used for software development and even have been applied for safety critical software, albeit with the proper controls in place.  One aspect of systems engineering is to elicit and analyze user requirements to derive requirements for the various sub-systems. Interpretation or misinterpretation of user requirements can lead to errors discovered late in the development cycle.  Getting early feedback from the customer is critical here.  The agile manifesto stresses the need to customer collaboration and  executable software.  But early in the systems engineering phase there is no software and certainly no mechanical or electrical systems.   This is where taking a modeling approach can help work in an agile fashion.  The model can help systems engineers to reason about the requirements and establish consistency across them earlier.  An executable model can be used to provide early feedback on the system and its behavior to derive better requirements for the various sub-systems. 
  • HazelWoodcock
    HazelWoodcock
    15 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T16:14:29Z  
    "Purity" is for zealots and professors who think they live in a frictionless environment and, who make for pretty ineffective teammates in our friction-packed world of product development. Engineering, whether it is focused on IT applications, products, systems or services, is more about managing impurity (let's call that uncertainty). The discriminating goal of becoming more agile is an improved efficiency of change, especially in the headwinds of high uncertainty in the requirements, designs or plans.
     
    Agile principles apply to all software development where managing uncertainty to achieve a better economic outcome is the main objective. In the IT world, where most projects live in a cost center, the goal of productivity improvement is usually to reduce cost, or achieve more bang per unit time or per unit dollar. In other words, the IT context is predominantly confined to the denominator (cost) of a business).  In the systems world, where most projects live in a profit center, the goal of productivity improvement has two branches: 1) to capture new revenue sources through innovating new features or attracting new markets, and 2) to reduce cost by achieving more per unit time or per unit dollar. So systems teams have the added complexity of improving the numerator of a business (revenues) along with improving the denominator of the business.
     
    So bottom line...if agile principles help you become more efficient at improving productivity, then they apply to systems endeavors as well. Agile principles (managing uncertainty, measurement, more intimate collaboration) help steer innovation and uncover better paths to improved revenue. Agile practices (scrum, user stories, TDD, XP, et al) are mostly effective at improving execution efficiency, quality and cycle time and reducing scrap and rework.
     
     
     
     Going back to the agile manifesto where
     
    'we value
      • Individuals and interactions over processes and tools
      • Working software over comprehensive documentation
      • Customer collaboration over contract negotiation
      • Responding to change over following a plan.'
    I think these are all vaild in a systems engineering context, including safety critical development, however we may need to move a little more to the right than for projects with minimal consequences of failure.  Agile practices at the embedded software end of the systems development may be applicable, but tailoring or reinvention for systems of systems integration would probably be necessary.
    Does anyone have experience of applying the agile practices to non-software systems projects? (by which I mean projects where the software is buried within a black box).
  • LeeBThomas
    LeeBThomas
    8 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T16:38:10Z  
     What are the key challenges?
     
    One challenge I've observed is the Agile stress on testing early, whether that is Test Driven Development, or Continuous Integration Testing, or simply requiring unit testing prior to checking in source code, versus the availability of a system on which to execute those tests.  This is particularly a problem at the beginning of the lifecycle, when the hardware, drivers and so on may not yet be available, but it's also a problem later in the lifecycle if the system is expensive to produce.  Testing is often forced into an iterative or even a waterfall model because access to a testing platform is difficult to justify.
     
    This problem goes away if the project can use commodity hardware and software platforms.   If every developer can have their own system, they can test their code as they develop it.
     
     In cases where the platform is not a commodity, one alternative is simulators.  Simulators can be expensive to build or to purchase, and often the systems developers don't trust their accuracy.  For Agile testing, simulators may be completely adequate, but a cultural bias against them may present a barrier for developers and testers who want to use them.
     
    IBM Rational Test RealTime provides support for automated testing of C and C++ applications in Systems environments, for unit and integration tests.  It has been used as part of automated regression test systems for Build Verification Testing.  It can execute a test in either a simulated or a physical system, with no changes to the test.  It could be a powerful aid to adopting Agile practices for Systems Engineering, if the other issues were addressed.
  • JimDensmore
    JimDensmore
    17 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T17:42:14Z  
     Hi Jim!  Great post!  And I think you make a great point about planning - I think that perhaps the ALM world has much more swiftly adopted a "planning" mentality, versus PLM, which traditionally has had the benefit of time on its side (but no longer true).  Have you seen approaches that were more effective than others in moving the ball towards agile?  Did you tackle people first, or process first, or tools first, or ...? 
    Thanks again for sharing.  
    Maureen 
    Yes :-) , we tackle people, process, assets and tools first.  In creating a plan for change, the assessment tells us where the "hottest" process, asset and tools spots are.  While we let process lead, usually we find that the processes development organizations (devorgs) really need can't be efficient enough without automation/tooling.  Then we create an early adoption iteration (sprint) with a couple (never less than 2) of important, but not too large, projects within the devorg, and we foster adoption in those projects of an appropriate subset of the overall set of capabilities the organization will eventually adopt.  The people get to see success with the new process, assets and tools, and in the retrospective we find ways to tailor the next sprint from the lessons learned.  In the next sprint early adopter projects get more new capabilities, and a larger fraction of the devorg gets the initially adopted capabilities while leveraging the first group as mentors.  Thus we expand in two axes, capabilities (process, assets and tools together) and people.  One of the guides I use in preparing plans using this framework is John Kotter's 8 organizational change steps - more and more necessary as the size of your devorg grows.
     
    Now why did I add Assets?  First, I think about an asset as being any collection of artifacts that we wish to govern as a collection.  So an asset could be a backlog, or a developed system or application, or even just an individual requirement.  Assets are important because people use process and tools to build them.  Some are intermediate (the collection of requirements for the next sprint) and some are more final (the system we're building).  Governing through assets makes more sense to me in an Agile context because the things being built are being governed directly.  Process continues to be important, but it is a guide, not a mandate.  Different groups who have come together to build a system or application might have different processes - and if you're governing through the assets being developed, that will be ok.  btw, open source development has done asset-based governance for years.  Certainly as soon as the architecture is solid (elaboration is complete) you can govern this way.  The hard part is determining the lifecycle for each asset (type) to ensure that appropriate changes of lifecycle state are identified as governance points.  Think of each governance point as a decision about the asset's quality and/or other factors.  Often, the current process can be used to initialize a set of assets and governance points, especially in the systems world.
     
    I might note that our community - the systems and software development community, so I'm speaking of a large community - is having trouble making the switch from process-based to asset-based.   I find that interesting, because all this is is the extension of basic "object oriented" properties into a larger space.  OO can be a swear word in the systems community, but it shouldn't be.  We all know what it's about: maintaining appropriate coupling and cohesion properties that improve our system's architecture, robustness, and ease of modification and improvement.  Governance, once the lifecycles are developed, is easier, and easier to automate, as well.  Those are allgood things.
  • HazelWoodcock
    HazelWoodcock
    15 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T18:14:10Z  
    Yes :-) , we tackle people, process, assets and tools first.  In creating a plan for change, the assessment tells us where the "hottest" process, asset and tools spots are.  While we let process lead, usually we find that the processes development organizations (devorgs) really need can't be efficient enough without automation/tooling.  Then we create an early adoption iteration (sprint) with a couple (never less than 2) of important, but not too large, projects within the devorg, and we foster adoption in those projects of an appropriate subset of the overall set of capabilities the organization will eventually adopt.  The people get to see success with the new process, assets and tools, and in the retrospective we find ways to tailor the next sprint from the lessons learned.  In the next sprint early adopter projects get more new capabilities, and a larger fraction of the devorg gets the initially adopted capabilities while leveraging the first group as mentors.  Thus we expand in two axes, capabilities (process, assets and tools together) and people.  One of the guides I use in preparing plans using this framework is John Kotter's 8 organizational change steps - more and more necessary as the size of your devorg grows.
     
    Now why did I add Assets?  First, I think about an asset as being any collection of artifacts that we wish to govern as a collection.  So an asset could be a backlog, or a developed system or application, or even just an individual requirement.  Assets are important because people use process and tools to build them.  Some are intermediate (the collection of requirements for the next sprint) and some are more final (the system we're building).  Governing through assets makes more sense to me in an Agile context because the things being built are being governed directly.  Process continues to be important, but it is a guide, not a mandate.  Different groups who have come together to build a system or application might have different processes - and if you're governing through the assets being developed, that will be ok.  btw, open source development has done asset-based governance for years.  Certainly as soon as the architecture is solid (elaboration is complete) you can govern this way.  The hard part is determining the lifecycle for each asset (type) to ensure that appropriate changes of lifecycle state are identified as governance points.  Think of each governance point as a decision about the asset's quality and/or other factors.  Often, the current process can be used to initialize a set of assets and governance points, especially in the systems world.
     
    I might note that our community - the systems and software development community, so I'm speaking of a large community - is having trouble making the switch from process-based to asset-based.   I find that interesting, because all this is is the extension of basic "object oriented" properties into a larger space.  OO can be a swear word in the systems community, but it shouldn't be.  We all know what it's about: maintaining appropriate coupling and cohesion properties that improve our system's architecture, robustness, and ease of modification and improvement.  Governance, once the lifecycles are developed, is easier, and easier to automate, as well.  Those are allgood things.
     Jim,
     
    Is asset based governance not arguably close to the process based governance that people are used to?  There are probably more assets in a process based project, assets such as review records, meeting minutes etc.  With process based governance the activities have to happen, but the evidence of that is always an asset.  You are describing something that presumably has a smaller set of assets - who read the meeting minutes anyway - and puts the emphasis in a slightly different place.  I know that we used to say that the UK MoD didn't care if they got their hardware at the end of the project, but that what we really got paid for was the documentation.  I don't think that was ever totally true, but the documentation was certainly considered a very important deliverable.
  • mbakal
    mbakal
    8 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T18:30:07Z  
     Going back to the agile manifesto where
     
    'we value
      • Individuals and interactions over processes and tools
      • Working software over comprehensive documentation
      • Customer collaboration over contract negotiation
      • Responding to change over following a plan.'
    I think these are all vaild in a systems engineering context, including safety critical development, however we may need to move a little more to the right than for projects with minimal consequences of failure.  Agile practices at the embedded software end of the systems development may be applicable, but tailoring or reinvention for systems of systems integration would probably be necessary.
    Does anyone have experience of applying the agile practices to non-software systems projects? (by which I mean projects where the software is buried within a black box).
     Certainly have experience in this. I know of agile development being used to develop medical devices (we had a bunch of presentations about this at Innovate), car infotainment systems and many other places. This is becoming pretty common place.
  • LeeBThomas
    LeeBThomas
    8 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T18:32:41Z  
     Hi Jim!  Great post!  And I think you make a great point about planning - I think that perhaps the ALM world has much more swiftly adopted a "planning" mentality, versus PLM, which traditionally has had the benefit of time on its side (but no longer true).  Have you seen approaches that were more effective than others in moving the ball towards agile?  Did you tackle people first, or process first, or tools first, or ...? 
    Thanks again for sharing.  
    Maureen 
    Maureen, Jim's correct that a holistic approach is needed.  However, Hazel quotes the Agile Manifesto: "we value: - Individuals and interactions over processes and tools".  So I'd argue that the holistic approach can't be avoided, but that per your question, the first place to start is with the people.  In particular, many individuals in Systems are highly resistant to any kind of change, and they maintain a cultural mindset to support that resistance, reinforcing it with every interaction.
     
    I think this also applies somewhat to the asset/process discussion also; it's quite important, but in the Systems space it's not the most important aspect of leading change toward Agile.
     
    (And I'll note in passing that I've observed Jim exercising what I take to be his Strengths as he is able to facilitate profitable discussions with change-resistant individuals who work in a change-resistant culture.)
  • mbakal
    mbakal
    8 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T18:35:36Z  
    Exactly, it's not a major change.  The problem we're trying to solve is the one where the process is followed but after doing so, the asset sucks.  "But we followed the process!"  By placing the governance on the asset itself we at least note that we're trying to move that asset from one stage to the next in its lifecycle, and that to do so the asset must meet the criteria set for each gate.
     
    Hardware?  You mean we got some hardware with this documentation?  You're kidding!  :-)  I worked on the F-22 program, and along with airplanes, Lockheed delivered simulators.   Much better than documentation for the pilots.  (But there was still a boatload of documentation *sigh* .  That could bring us to the next topic: Model Driven CDRLs.)
     I agree with Jim. This isn't a major change. The issue is in the nuance. Because is process based systems demonstrations many times don't come until late in the process who knows in the real product actually works. This everything slips and we blame testing when it actually was engineered and architected wrong because no one asked for a working prototype. The type of assets Agile asks for is actual demos so people can see the work is progressing. This is why it is an asset based process. Produce and asset to show the work you have done not just show you can fill out the process steps.
  • JimDensmore
    JimDensmore
    17 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T18:36:33Z  
    Maureen, Jim's correct that a holistic approach is needed.  However, Hazel quotes the Agile Manifesto: "we value: - Individuals and interactions over processes and tools".  So I'd argue that the holistic approach can't be avoided, but that per your question, the first place to start is with the people.  In particular, many individuals in Systems are highly resistant to any kind of change, and they maintain a cultural mindset to support that resistance, reinforcing it with every interaction.
     
    I think this also applies somewhat to the asset/process discussion also; it's quite important, but in the Systems space it's not the most important aspect of leading change toward Agile.
     
    (And I'll note in passing that I've observed Jim exercising what I take to be his Strengths as he is able to facilitate profitable discussions with change-resistant individuals who work in a change-resistant culture.)
    I didn't even pay him to say that!
  • LeeBThomas
    LeeBThomas
    8 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T18:56:26Z  
    I didn't even pay him to say that!
     Well, Maureen would get the Strengths-with-a-capital-"S" reference, since she leads the StrengthsFinder discussions.  But my main point was that introducing Agile to Systems folk is as much about psychology/sociology as it is about technology - maybe more, in some cases - so those leading that kind of change must have excellent skills in both areas.  And, they have to be able to jump from a discussion of bits in a shift register to a discussion of the advantages of Agile to both the organization and an individual, and back again, rather seamlessly.  That's rather rare, and should be valued.
     
    But if you did want to pay me, . . . :-)
  • elko.mike
    elko.mike
    28 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T19:05:04Z  
     Jim,
     
    Is asset based governance not arguably close to the process based governance that people are used to?  There are probably more assets in a process based project, assets such as review records, meeting minutes etc.  With process based governance the activities have to happen, but the evidence of that is always an asset.  You are describing something that presumably has a smaller set of assets - who read the meeting minutes anyway - and puts the emphasis in a slightly different place.  I know that we used to say that the UK MoD didn't care if they got their hardware at the end of the project, but that what we really got paid for was the documentation.  I don't think that was ever totally true, but the documentation was certainly considered a very important deliverable.
     The definitive answer to the questions posed is it depends.  The best way to answer these questions is to subject them to a rigorous inquiry, starting with Use Cases so that we can all understand what it is that we are talking about.  It makes no sense to me to say that a team working more cooperatively is more important than the tools and process on a systems engineering project such as the International Space Station, as the tools and processes are an essential enabling factor for team cooperation.  But there is a problem with the systems engineering and development for projects such as the International Space Station.  It was bid at $3 billion originally and, depending upon how the money is counted, it cost between $20 and $100 billion to deliver.  Improvement is obviously needed.
    The Rebaseline Use Case is in my view a canonical example of the problem faced in large-scale systems engineering projects.  Ram Ravishankar worked on it with me before I retired and likely has preserved much of that material.  This is a problem that is worth solving as (from an admittedly poor memory) the top 80 DoD programs are a combined $300 billion over their original budget estimates.  That is a business case for improving the performance of systems engineering teams. 
    I do agree that agile concepts have a role to play and the trick is to find out how to integrate the lessons learned from agile with the problems encountered in large systems engineering efforts.  Finding that role will require, in my view, a structured examination of the challenges faced by large-scale systems engineering efforts to find that role.
    I helped write a paper on the issues of development and delivery of satellite systems, which talks about some of the issues and offers a few thoughts about solutions.  http://www.iafastro.net/iac/archive/browse/IAC-07/D1/3/7286/
    Updated on 2012-11-28T19:05:04Z at 2012-11-28T19:05:04Z by elko.mike
  • Adrian_W
    Adrian_W
    1 Post

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T19:18:37Z  
    Can Agile techniques apply to SE? Absolutely, in my eyes I don't see it as all that different from the  "Concurrent Engineering" concept that was all the buzz in the mid 90's. Getting all the stakeholders in the life-cycle working together, at the same time, collaborating and sharing, to reduce design errors early. The hard part in all of this is actual execution. How do you actually achieve this end goal in practice. Certainly the notion of practices and tooling back then, wasn't what it is now.
     
    So yes, Agile techniques I think can be applied, but care should be taken on how its messaged to the SE community. Lessons have being learned from when UML was applied to SE. "Its too software focused", folks would say .... and from that came "SysML". Something thats specific to the SE community. The same needs to be applied to the "Agile concept", make it specific for System Engineering, and ensure one uses terms and terminology that's applicable to that domain, otherwise I fear the message will be lost.
  • WalkerRoyce
    WalkerRoyce
    14 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T19:37:06Z  
     So after seeing most of the comments so far, it seems like the consensus is that agile principles and practices are clearly applicable.
    Maybe a better question to stimulate discussion is: What agile techniques, practices or principles DON'T make sense in a systems context? ....or must be substantially adjusted to fit into the constraints or challenges of certain domains.
     
    Here is my contribution.
     
    There is one agile practice that I have been pushing for years that may seem difficult at first glance to achieve in some embedded systems domains That practice is to plan for, and execute integration testing prior to unit testing.
     
    Many folks building software for embedded platforms, some whose hardware components may not be available until late in the development cycle, argue that this principle does not apply to them. In my view, that is narrow-minded. Sure, there are some new constraints, but you just need to be creative about dealing with the constraint.
     
     Are there any agile techniques, practices, or principles that folks think are counter-productive in some systems domain context?
  • elko.mike
    elko.mike
    28 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T19:52:42Z  
    • Adrian_W
    • ‏2012-11-28T19:18:37Z
    Can Agile techniques apply to SE? Absolutely, in my eyes I don't see it as all that different from the  "Concurrent Engineering" concept that was all the buzz in the mid 90's. Getting all the stakeholders in the life-cycle working together, at the same time, collaborating and sharing, to reduce design errors early. The hard part in all of this is actual execution. How do you actually achieve this end goal in practice. Certainly the notion of practices and tooling back then, wasn't what it is now.
     
    So yes, Agile techniques I think can be applied, but care should be taken on how its messaged to the SE community. Lessons have being learned from when UML was applied to SE. "Its too software focused", folks would say .... and from that came "SysML". Something thats specific to the SE community. The same needs to be applied to the "Agile concept", make it specific for System Engineering, and ensure one uses terms and terminology that's applicable to that domain, otherwise I fear the message will be lost.
     Adrian, I lived concurrent engineering and it had many fine properties.  The problem I saw with it, which was addressed in the paper we wrote (reference earlier), is the inherent difference in lifecycle attributes between hardware and software.  For instance the hardware needed for software testing often came very late in the development cycle, which always put software onto the critical path. Without some means of identifying these dependencies and planning to address their inherent risks early in the product's development lifecycle, concurrent engineering worked in practice the same as traditional engineering.
    A solution to this problem, which is in the spirit of concurrent but hated by the hardware teams I worked with, was to build emulations, simulations, or prototype hardware to provide an early test bed for iterative software development.  It is essential to the success of such an approach that the hardware teams build and deliver these things to the software teams.  My belief is that hardware teams disliked the fact that their plans were driven by the needs of software development.  I'm not sure.
    In any case our general approach was to take the critical use cases, focusing on the critical paths within them. down at least two levels.  We would look at the dependencies in the class and sequence diagrams to define our plan for iterative development.  With this material we would build a schedule for delivery of software content to the System Integration Lab where it would be scored independently of the software teams' estimate of their progress.  Thus we were forcing definition, integration and testing of interfaces horizontally and vertically across components and teams within a few months of starting a multi-year development.  
    It was this level of hardware-software development integration, enabled by modeling, that provided a robust and useful approach to concurrent engineering in my view.  
  • JimDensmore
    JimDensmore
    17 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T19:53:07Z  
    • elko.mike
    • ‏2012-11-28T19:03:16Z
     The definitive answer to the questions posed is it depends.  The best way to answer these questions is to subject them to a rigorous inquiry, starting with Use Cases so that we can all understand what it is that we are talking about.  It makes no sense to me to say that a team working more cooperatively is more important than the tools and process on a systems engineering project such as the International Space Station, as the tools and processes are an essential enabling factor for team cooperation.  But there is a problem with the systems engineering and development for projects such as the International Space Station.  It was bid at $3 billion originally and, depending upon how the money is counted, it cost between $20 and $100 billion to deliver.  Improvement is obviously needed.
    The Rebaseline Use Case is in my view a canonical example of the problem faced in large-scale systems engineering projects.  Ram Ravishankar worked on it with me before I retired and likely has preserved much of that material.  This is a problem that is worth solving as (from an admittedly poor memory) the top 80 DoD programs are a combined $300 billion over their original budget estimates.  That is a business case for improving the performance of systems engineering teams. 
    I do agree that agile concepts have a role to play and the trick is to find out how to integrate the lessons learned from agile with the problems encountered in large systems engineering efforts.  Finding that role will require, in my view, a structured examination of the challenges faced by large-scale systems engineering efforts to find that role.
    I helped write a paper on the issues of development and delivery of satellite systems, which talks about some of the issues and offers a few thoughts about solutions.  http://www.iafastro.net/iac/archive/browse/IAC-07/D1/3/7286/
    Mike, I must agree that some of our answers here are flippant ... well, at least not rigorous, maybe even there is some guessing going on.  Taking an (add-or-enhance)-selected-practices approach is piecemeal and can achieve a local optimum that is nowhere near the global optimum.  However, on too many large systems engineering efforts I have seen crazy failures (like your factor-of-between-6-and-33 overrun example) and they never change their processes at all!  (Reference insanity definition.)  Surely something more agile (lowercase) is warranted to try and mitigate some of the higher risks up front, instead of at the end-end-end-end during ((((re)re)re)re)integration.  On a big program one can/should afford to mitigate process risk by doing the rigorous inquiry you suggest.  Where possible I recommend that some of the inquiry be done via execution of selected practices we believe will help, and measuring results.  It is the last that so rarely gets done, just to ensure that no objective feedback is available. 
  • LeeBThomas
    LeeBThomas
    8 Posts

    Re: Virtual Round Table – Agile Systems Engineering (28 November – 7 December)

    ‏2012-11-28T19:55:57Z  
     So after seeing most of the comments so far, it seems like the consensus is that agile principles and practices are clearly applicable.
    Maybe a better question to stimulate discussion is: What agile techniques, practices or principles DON'T make sense in a systems context? ....or must be substantially adjusted to fit into the constraints or challenges of certain domains.
     
    Here is my contribution.
     
    There is one agile practice that I have been pushing for years that may seem difficult at first glance to achieve in some embedded systems domains That practice is to plan for, and execute integration testing prior to unit testing.
     
    Many folks building software for embedded platforms, some whose hardware components may not be available until late in the development cycle, argue that this principle does not apply to them. In my view, that is narrow-minded. Sure, there are some new constraints, but you just need to be creative about dealing with the constraint.
     
     Are there any agile techniques, practices, or principles that folks think are counter-productive in some systems domain context?
    Walker, I was just with a Defense contractor where demonstrating the system to the customer was an extremely high-ceremony affair, requiring weeks of time (three weeks of 12-hour days, including weekends, was typical) and much advance planning for each event.    I contrast that with the Agile principle of valuing "Working software over comprehensive documentation", for two reasons:
     
    1. Some Systems customers lose confidence if the developers demonstrate software that is in any way incomplete.
     
    2. Some Systems customers see "comprehensive documentation" as an essential deliverable.
     
    Whereas in an IT context it may be possible to deploy a system with only partial functionality and the users could derive benefit, in Mil-Aero I believe that approach would need to be heavily modified.