2014/01/27 15:15 Perri Nejib and Dawn Beyer, “Agile Concepts for Security in SE at Lockheed”, Agile Systems and Systems Engineering Working Group

Perri Nejib and Dawn Beyer (Lockheed Martin) with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

These authors are writing an essay that hasn’t yet be cleared by Lockheed.

Secure Engineering Assurance Model

Starting working with challenges in security, saw them as the same in engineering in general

Also in agile, since threats change so quality.

Advanced Persistent Threats:  backed by nation states, e.g. China and Russia, but they don’t want us to know that they’re in there.

So, agile security is important in this world

  • Not just agile principles and practices, it’s about being agile

There are 15 people in Lockheed who have to approve the paper, some layers

Already presented some of the work in the INCOSE security group.

Content of essay is like talking to slides, which can share.

Perri has had to explain why security is part of systems engineering.

  • System security engineering is systems engineering applied in a security context.
  • Had some things to do that no one else was doing, they fall to the systems engineer.

Agile threat means need agile processes to respond.

Can look at security from cradle to grave

  • In proposal
  • Development phases
  • Operations & Management in Network Operations Centre, have Information Systems Security Analysis

Problems with security engineering in information sharing

  • We do a good job of information sharing in intelligence with DoD and talking about threats with competitors
  • But not joined into deployment and Operations and Management
  • Leaned process by 50%, still complaints of too long, now working on checklists
  • Problem if not in process, individuals won’t cost it out, because it’s someone else’s area, but then find new vulnerabilities
  • Testers need to surface controls to be done

Threat intelligence

  • If communication not shared immediately, then other vulnerability can be exploited

Question:  locus for threats?  Where they rise from?

There’s a lot of open source information on threats.

  • From counter-intelligence, China and Russia attack contractors
  • Hackers can brag about getting into network
  • Not seeing red (adversaries) but grey (friendlies) e.g. U.K.
  • They don’t want to be noticed, they’ll come in persistently and slowly, and then start getting information
  • Vectors are e-mail, USB drives, PDFs
  • Security office does a lot of testing of people, to see if they’ll report
  • Also insider threats, can’t trust own people:  disgruntled employees, someone who is about to leave the company

Not just challenges of cyber threats and cyber intelligence, may be identifying a vendor that has 3 pieces of which 2 are in the U.S. and one is in the Middle East

  • Normally a systems engineering wouldn’t red flag that
  • A security engineer could say we can’t use that piece

Or particular solution needs to be physically located outside of U.S., need to know there.

Threat working group

  • Part of this is supply chain organization
  • Internal intelligence
  • Business
  • Counter-intelligence

All in the threat working group are sharing knowledge, and it changes rapidly

  • e.g. did a trade study, found product A was best, but then with other considerations have to go with product B

Process itself is agile, morphs to needs of user

  • Wanted to make sure that the processes weren’t created top-down.
  • Piloted with actual processes at Lockheed
  • Did get feedback from some “are you crazy”, because threat assessments can be costly

Question:  Requirements, changing spec, test integration phase?

Framework, not methodology.

  • Shows activities that a security engineer has to perform at certain times of the life cycle.
  • e.g. as requirements going on, security engineer does a high level security risk assessment
  • These all have to be integrated into a systems engineering, otherwise will overlook security or contradict some other performance
  • Customer may call out security as standalone, as certain deliverables to be presented with a solution
  • Security architecture and code reviews:  not just functional
  • When in security, preached test before development, but then how to test “the system must be secure”
  • Penetration test
  • Vulnerabilities before upgrading

Question:  Change management?

  • Here’s its so fast, there’s no formal change management

Sharing threats is still a struggle to let information go

  • A privilege and control change, cultural
  • Need strong requirements:  what do you want, a report, machine-to-machine or to a person?

Question: Standards?

  • Requirement part of this is non-process-centric.
  • e.g. electrical utilities have FIPS.
  • Mapped against ISO and NIST standards: gap in direct modelling of threat sharing

Doesn’t matter where you are in life cycle, could go backwards and forwards.

  • e.g. while in design phase, evaluation/audit could request requirements documents

Started a community of practice

  • Invited to program managers meeting, if you see any of these words in an RfP, you need a security engineer
Advertisements

#agile, #incose, #iw, #systems, #systems-engineering

2014/01/27 15:15 Rick Dove, “Scrum a Dum Dum, Three Core and Some Crumb”, Agile Systems and Systems Engineering Working Group

Rick Dove (Paradigm Shift International) with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

This article is to fill in for a missing article.

From Alastair Cockburn, one of the original Agile Manifesto people

  • There’s the core of what scrum is all about, and then other people throw things on top of it

1. Concept of a sprint:  have to deliver something

2. Giving the team enough power to exercise expertise

3. Inspect and adapt every day

Learning loops is what makes Scrum agile

  • Every morning stand-up meeting:  are we still on track, what are you doing that someone else might line up
  • End of sprint:  technical retrospective, we delivered, what do we think about it; then process retrospective, should we have 3-week sprint or 5-week sprint?
  • These retrospectives can be confrontation, constantly will question what we did, and see if we could have done it better.  Not for the faint of heart.

In article, not trying to do a Scrum slide

  • Problem:  most of Scrum tells you about good project management practices, but it doesn’t make you agile
  • Loops
  • The people who invented Scrum understand that they were putting learning loops in.
  • There’s a good body of knowledge about what Scrum is trying to do, it’s Peter Checkland Soft Systems Methodology
  • SSM is taught in most Systems Engineering processes
  • Checkland came as a  hard systems engineering, and realized that everything he learned doesn’t work with politics, people
  • e.g. 14 stakeholders, and each want everything today

Have different corporate cultures, who is on team, and will let them do

Systems engineering is a soft system

  • Themes, conflicts

Comment: Start with Scrum, ending with SSM.

Way too many people equate agile to Scrum.  Want to start with a foundation of understanding they already have about Scrum, and figure out where else it could be reapplied.  Learning loops, that segue into learning loops.

Comment: Why scrum works?  The other barnacles (the scrum master, the product owner) can help to make things work.

Alastair Cockburn has a 5-minute video on this.

  • Says you don’t need a Scrum master, but they’re highly recommended, as people don’t appreciate that they’re supporting learning loops.
  • But there are a lot of people down the road on this who don’t need a scrum master.

Comment:  Audience?

  • Multiple domains of interest.
  • When we start defining a agile systems methodology, we’ll have to start with soft systems.
  • Starting with Scrum, but there are three core elements, period.

Comment:  Learning loops closer to action research than SSM per se, although the two are complementary.  People looking at SSM won’t necessarily connect to the learning loops in SSM.

Comment: Scrum master?

When have an experienced group, as scrum master could be a nuisance.

Comment:  SSM as a way of getting world views out on the table.  Scrum master can play out that role, and help with power balancing.

Agree, but the scrum master isn’t always necessary.

  • Have a 3-man team working on project, have to carry water to the team when they need it.  That’s a scrum master’s job, but we don’t look at it that way.

#agile, #incose, #iw, #systems, #systems-engineering

2014/01/27 14:00 Ralph LaBarge, “CubeSat — An Agile System Architecture”, Agile Systems and Systems Engineering Working Group

Ralph LaBarge (John Hopkins University Applied Physics Laboratory) with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

Joint paper with of Rick Dove with Ralph LaBarge

Rick Dove presenting Ralph LaBarge slides

Cubesat is form factor:

  • e.g. 10 cm squares
  • Small satellite thought to be interesting, as often empty space on a launch vehicle going up, but want to take advantage in a generic way so that others could take advantage of it
  • Excess baggage
  • Standard interfaces to power, onboard launch bay infrastructure, way to be deployed so that launch vehicles can deal with them
  • Many different launch vehicles are outfitted:  initially directed as university research environments, where you get “free” launch

Many different launch vehicles are outfitted:  initially directed as university research environments, where you get “free” launch

  • Since then, used by non-university organizations

What is an agile system architecture?

  • Once you have an architecture, these are principles that you can flesh out, and take advantage of agility
  • Passive infrastructure:  rules and standards of interoperability, e.g. plug and unplug — where constraints are important
  • Active infrastructure

Yes, it’s modular architecture, but there are challenges for agility

  • Lose a piece, and you don’t have a system

Active infrastructure:  recognition that deploying and agile systems and walking away from it, it will never be as agile again, because there’s no one maintaining the system

  • Means infrastructure can evolve, and someone is responsible to ensuring that it can evolve
  • Often in job, the usual response is “no”, you can’t get around the rule
  • However, sometimes the current infrastructure isn’t right
  • Who assembles the system of the moment, when the components are available (as Hillary says, composable) as system assembler
  • In a agile system environment, need to know who is responsible

Responsibility for the nature of the module itself

1. Do we have the modules we need today for today’s situation:

  • New things are in pool, in advance of need: will be available before disaster happens

2. Modular readiness:  may have a lot of interesting modules, but then when someone last returned it, was it rusty so that it can’t be used?

  • A lot of junk in inventory pools

Agile architecture pattern diagram

  • 3 depictions of 3 types of Cubesats, left to right (older to newer)
  • Left side basic cube
  • Centre:  cube x 3
  • Right side:  more recent, has same centre packaging capability, but new capabilities added to infrastructural packaging, so could do antennas

Ralph took a narrow view of agile architecture, so says it’s an agile architecture.

  • In paper, took a larger view of how JPL used the architecture
  • JPL doesn’t use agile term, aware of Scrum, but used “scrum master” as sheriff, to get people out of the software mindset
  • JPL has written about this, Dove and LaBarge says it’s agile-like

Advice to Ralph?

Comment: Used Dove work out of Stevens to flesh out this article.  Useful to see application of architecture, even use in words like “scalable”.  Could consider putting into introduction.  Yes, say it’s an agile architecture, but then say this follows a specific meaning for agile.

#agile, #incose, #iw, #systems, #systems-engineering

2014/01/27 14:00 Hillary Sillito, “Composable Capacity for Agile Systems of Systems”, Agile Systems and Systems Engineering Working Group

Hillary Sillito (University of Bristol) with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

Essay based on  INCOSE IW presentation last year in Philadelphia.

  • Agile for military, interoperability
  • An appeal to military to use systems thinking, systems engineering at force level

Problem and context

  • Long conversations over the past 10 years on capability engineering, bringing together with capability management and systems engineering
  • Language barriers, lots of definition of capability
  • Coming top-down gets stuck
  • Mission threads seems most successful, but Brits though too many situations that would never be encountered

Purposes of systems architecture:

  • How many people are actually doing this?
  • In engineering world, don’t quite know how to do this.
  • System-of-systems worlds, get things to work together, without side effects

If don’t achieve, get undesireable emergent properties (against enemies who do things that you said they couldn’t do)

General Sir Rupert Smith, from Bosnia:  In full view of enemy, did manoevers that enemy didn’t think of

  • Can’t plan ahead or fully anticipate

Open system benefits

  • First evidence that you can do this.
  • British vehicles to Afghanistan, trying to put new equipment on old equipment, couldn’t do it
  • So much equipment, couldn’t put on payload
  • Surveillance systems, etc.
  • Electronic architecture, standard data buses that can be updated without having to have controls and switches
  • Simplified version:  on the second or third upgrade, will get the money back, but on the current method for procurement, the open architecture was initially more expensive than alternative
  • Seems to work
  • Electronics and software work better than anyone had previously experienced

Interoperability

  • Definition: systems or units or forces
  • Everyone grabbed the systems or units, and haven’t focused on operational processes and culture
  • Benefit of interoperability is getting system-emergent properties, but it’s almost impossible to put together a business case to pay for the work

When was running integration authority, ran architectural inputs and audit of interoperability in 200 equipment programs

  • Equipment being bought by projects where procurement structure didn’t fit with operational way, so no one was going to own up for the operational architecture.
  • Would have been easier if everything was drawn from an operational architecture, rather than working bottom-up trying to integrated from components

How to specify a force element?

  • Force element as part of the system:  basic behaviour, key paramaters, timing and accuracy
  • But concurrency isn’t well dealt with, e.g. landing aircraft as enemy launches 20 missiles towards you.

Need to clearly separate the platform use cases from the system use cases

  • Not done properly on the systems worked on 10 years ago
  • What do the platform need to do to survive in a military environment?
  • Something things that have to do with logistics.
  • In military terms, apology, joint fires
  • Get a standard pattern for a military force element, rather than trying to integrate up into a force element never specified

Want stable, well characterized building blocks

  • e.g. ship, platoon — it’s the way a military commander puts a force together
  • Then exercise performance, behaviour
  • Something applying to disaster recovery may not apply to consumers
  • Granularity is important

Standard template for force element

Conclusion:

  • The more consistent and well-defined the components, the more you have to do in reconfiguration, will be dealing with system of system emergent properties

Comment:  Providing a system of system capability, might be better to portray as system of system architecture

Yes, using architecture as an approach.

Comment:  Quandary:  thinking of system of system as a system

May be better just to say “architecture” than “system architecture”

Comment:  Like composable systems, that are the active side of agility.  Reactions to the word “composable”?

Comment:  Composable not sufficiently strongly related to agile.  Didn’t hear agile throughout the presentation, didn’t hear composable (although the idea is used throughout).

Comment:  Composable, will this give me insight about whether this will tell how to construct a system of system architecture.  Without that knowledge, people may get lost.  A little pattern example, even if incomplete, would help readers translate.

Word count is 2144, could take something out so could have an example within 2500 words

Comment:  Non-military people should hear about this, because it translated into product architecture.

Comment: Getting closer to operational use case, back to basics.  Bridging to agile, have a lot of the bridges in the article.

#agile, #incose, #iw, #systems, #systems-engineering

2014/01/27 13:30 Richard Turner, “Balancing Agility and Discipline in the SE Process”, Agile Systems and Systems Engineering Working Group

Richard Turner (Stevens Institute of Technology) with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

Step back, to abstract need for systems engineering

Will talk about:

  • Why balance agility and discipline
  • Value in systems engineering (not values)

12 years ago, book on Balancing Agility and Discipline with Barry Boehm

  • Still selling, but old
  • At the time, had battles
  • Came up with frameworks, using risk to balance out discipline and agility

For this essay, what we’ve learned in the past decade, and systems engineering (which wasn’t in the first book)

Why balance?

  • Cone of uncertainty:  we didn’t know anything about it, but we did by the time we delivered
  • Could be out of code of need by the end
  • The timeframe in which we’ll delivering systems has made agility necessary

Had a nice video:

  • Wrote a paper on systems engineering and agile in Crosstalk
  • Usually talk about discipline as rules, but it’s not all
  • It’s about what you’re doing, e.g. configuration management is what you’re doing

Plans, not planning

  • Agile people said don’t like plans, but do planning, they don’t like plans that exist for a long time

Monitoring cogent external events is a discipline

Maintaining systems is a discipline

Discipline is a lot of what is done in systems engineering, don’t want to give it up

Other ideas for agility

  • Flow
  • Invention on the fly
  • Improvisation on the fly
  • We can gain insight from learning, repeating things with discipline

Have to balance

  • Two cones
  • If we don’t balance, spend all of time in discipline, we can deliver a system but it’s not relevant, and has decreasing value
  • Continuous delivery could be incomplete, unusable, unmaintainable, isolated, confusing

Value in systems engineering

  • Agile about delivering value to customer
  • Lean as measuring value, which is more important to do first
  • Can talk about earned value
  • Values aren’t mutually exclusive, they depend on the point-of-view:  maintainer value is not the same as the deliverer value
  • Neutrality of value in requirements hard to deal with:  which is more important, fast 20% solution, or a 99% solution?
  • Values tend to be arcane, hidden.  Power isn’t an obvious thing, who on the committee has the most power.  Have to look to make power more value and visible.
  • Value changes over time.  Different people have different values, depending on how much you’re talking to them.  By the time they see prototypes, may see more value.
  • Value is part of risk assessment, and part of opportunities.

Concepts key to balancing:

  • Wholistic and integrating part:  SECOM (capability model) had a category of integrating disciplines.  Disciplines may not have significant understanding of the whole.  Need things that are multidiscipline, wholistic view of all stakeholders (not just the people with money).
  • Collaborative and negotiating isn’t as strong as coordinating and stabilizing:  not “give us the requirements, and we’ll go and do our own thing”.
  • Coordinating and stabilitzing, so can move foward
  • SE as value-based, continuing service:
  • Not just front end value, have rear end, where engineering continues to have value.  Once in development, no reason that couldn’t be a services provider

ICSM principles used for balancing

  • Stakeholder value-based guidance
  • Incremental commitment and accountability

Meta-principle for balancing:

  • When you balance, if you do too much or too little, there will be a sweet spot that is important

Balance is an evolutionary action

  • It’s a culture change
  • Balancing agility and change is much more of a mental model change
  • Learning can be done, but it’s hard to do culture change

Comment:  Can guide systems engineers, as they have to understand balance.  They can create requirements, but does it meet the business need (and could drive the implementation team crazy).  Add how these ideas can be used to evaluate systems engineers, and possibly how systems engineers could become more reflective.

In SERC, have talked about reflective times, thinking about how could have responded to situation differently.

Comment:  Everything is an -ing, e.g. planning, integrating.

Can’t afford not to be continuous.

Comment: What’s practical, or lesson learned on the application side.  Establishing a value that everyone can agree on.  How we get the customer to evaluate to the value of the systems engineering activities.

Comment:  Uncertainty, balance set.  Didn’t see examples.  Put a simple framework together so we know how people see values.  A way of setting up a value framework that is balanced.  Then, what is it that they have to balance?

Comment:  Didn’t hear more about agile systems engineering.  Agile systems or systems engineering?

Intentionally did that, because wanted to get away from the idea of agile systems engineering.  If look as it as not being agile, or disciplined, but instead balanced so that satisfying stakeholders (just enough) ….  We miss the point when we only talk about agile systems engineering.

#agile, #incose, #iw, #systems, #systems-engineering

2014/01/27 11:30 “John Young: The Challenge of Reflection in Agile Development Systems”, Agile Systems and Systems Engineering Working Group

John Young (Red Elephant Technology), with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

Could change the title to be on Work Systems in general, not just Adaptive Development

Importance of reflection

Alastair Cockburn, one of founders of the Agile Manifesto

  • What is it that’s happening when we see a group of people designing?
  • First, people …
  • … communicating …
  • … problem changing ..
  • … languages …
  • … decisions …
  • … resources …

See a complex adaptive system, as per John Sterman.

Worked hard in this essay to not use the word “agile development”

To deal with complexity and change, systems have to include a ongoing process of learning through reflection

  • Learning, double loop learning
  • Alongside the development of a product depending on learning, must be able to change the work environment
  • Have been looking at the organization studies community

Reflective learning can disrupt individual and collective identoty

Traditional approach from Harold Bridger:  system psychodynamics (not used in the essay) based on systems thinking in the 1950s

  • Knowledge creation, but focus on the transtioinal approach
  • Concept of the double path:  primary path, plus second path with reflection on the work
  • Harold Bridger, as psychologist, recognizes antagonistic and conflicting forces
  • Differentiates from other perspectives on organizations
  • Need to set time and space as an opportunity for reflection
  • Build a holding environment:  from child psychology (haven’t included into essay), a safe space, from Norman Kirk on project retrospectives
  • Reflection is anchored to the work at hand; if decouple from work at hand, you’re entering into group therapy, risk of groupthink

Power can usurp learning

  • If power does not engage in reflective process, and usurps learning, then agility will be greatly reduced.
  • People find a way to survive

Manfred says managers today want to be surrounded by people who challenge, mirrored by their staff

  • Integrity of the development system
  • Agile has implications of such a development system
  • Manfred takes it further to deliver a delusion approach to the phenomena

Conclusion:

  • Alastair Cockburn’s TED talk, the tiger as the person promoted to the team lead, called his mascot Fluffy
  • A tiger leaping at an emaciated stick figure that is an engineer
  • Agile development movement:  have to learn to facilitate a more open collaborative way of working

Comment:  Would get a lot more out of paper, if less literature discussion, and expanded on last paragraph so that readers would know what to do.  Have explained why it’s important.  What like to know what organizations need to do to implement that.

Comment:  A lot of background material that would be better in a paper

Comment: Liked paper, reinforced the importance of retrospective. As an agile coach, it’s on the of things that gets dropped.  It’s important.  Should address this to the systems engineering audience.  If could make the importance of retrospective, it will give the learning opportunity to the rest of the audience.

Comment: Like content.  Some examples would make it more pointed.  There’s a lot going on.  Systems engineers may not talk about organizational dynamics, e.g. self-censorship is an example of something that would be written about.

Comment:  May have to watch for lengthy examples.

Comment:  Expand on research, to be submitted as an IS paper on engineering leadership.  Influencer in the Covey Seven Habits.

Comment: Visual at end was interesting, could bring up front.  Focus more on encouraging what organization should do.  Reflection cycle.

Comment: Useful if could highlight three tasks:  individual abilities to do reflection; ability to collaborate in group reflection; ability to collaborate in group reflection without external forces (management).  Donald Schon has written about the Reflective Practitioner and Educating the Reflective Practitioner.  Examples in the Julliard School of Music, and in architectural classes.

Fan of Donald Schon.  How much can be squeezed in?

Comment:  It’s an essay where you don’t have to prove what you’re saying.

#agile, #incose, #iw, #systems, #systems-engineering

2014/01/27 11:00 Dave Alberts, “System Agility IQ”, Agile Systems and Systems Engineering Working Group

Dave Alberts (DoD Command and Control Research Program) with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

Not from the agile community

In the command-and-control community, recognize that overall idea of agile (commanders to maintain order), use systems broadly

System as a collection of interdependent systems.

  • Where do dynamics and complexity come from?
  • The complexity of one in the network can impact the performance of another in the network
  • Wholistic approach can improve performance.
  • Have to give up optimal performance for agility.

Have to give up optimal performance for agility

  • Trying in experiment for some years

Manifest agility

  • Need to be able to measure potential agility.
  • Potential is what IQ is all about
  • A function of enablers of agility
  • Can be done independently of observing a system at a point in time at a particular situation

From a different community, what is meant when someone says agility

Some areas of commonality (three, not sure if more)

  • Agility as a necessary response to complexity and dynamics, otherwise would have a stable situation, or could reduce complexity and optimize
  • Thus, dealing with uncertainties
  • Is it a capability or an outcome?

Is it a capability or an outcome?

  • Was a system agile or not?
  • Could it improves its situation, would say, yes, it’s an agile system; otherwise, say no.
  • It’s not about just the reactive part.
  • Could say have a reactive system, recognize that something will change, will do something to get back on track or could prevent decline.
  • Could also be proactive

Manifest agility:

  • Can observer whether a systems does or does not stay within the acceptable range of performance.
  • Change, stress, when detected, when considered to be signficant, when do you decide to do something, what do you do, when does it take to get back to the desired state?

Depends on coming across situations that require agility, which sometimes happens often or not often.

  • May not have a lot of data
  • Data that you have may not be indicative of data in the future.
  • e.g. currency traders, top picks are all wrong
  • This pattern repeats itself in all domains

Can simulate, but may be hard if there’s a lot of interactions between the system and other systems.

  • Have played without thousands of alternatives.
  • Fidelity issues.
  • Not stressing the scenarios, it’s about what they think might happen.
  • Don’t want to do this blindly, don’t want to do in expectation.
  • Want scenario-independent.

If could only find a way to get agility IQ, then could see if expectations of environments, could see if will deal with unexpected.

We think about agility as an outcome, and the enablers of agility as way to get an outcome we want.

  • If you’re not responsive enough, you’re toast.
  • May be other ways to get you back into the zone of acceptability
  • The white space:  why do we need agility, that pressures us into the zone of acceptability.

Have stressors and enablers.

What do we need to understand agility IQ?

  • Could have more resilience, more responsiveness

For systems engineering community, could try to understand the ways and means by which the mechanism work, to build more flexibility or responsiveness

Recap:

  • Agility as an essential capability
  • Have to be something where you’ll sacrifice optimality
  • Have to observe both enablers and outcomes
  • Measuring real life isn’t good enough, success doesn’t have anything to do with what you did
  • Limitations to scenarios, there’s an additional agility measure

Question: Measures?

Reliability in software and in hardware?  Agility is around change, so reliability may not mean the same.

Question:  Figure 1, why is the lower curve preferred?

Lower curve isn’t preferred.  We can only observe reality.  The lower black curve is reality, the upper red curve is what we would have expected if nothing had changed.

Comment:  Need to change the wording on the chart

Comment:  Passive, reactive and proactive, which is strong.  Later, you don’t use those words, so may fix paragraph.

Question:  Is agile for a system or an evolvement activtity?  System agility is a design for an intended mission.  There’s no agility, e.g. a race car is designed for speed, not for 7 people.  Need to qualify, as system agility versus process agility?

Comment:  Clarify the difference between system agility and process agility.

Comment:  Title is exciting.  However, then think of original IQ to a psychologist as the ability to learn.  Would like to hear more about the learning ability.

Used in a difference sense.  Used it as potential.  Could use a different term?

Innovativeness part as that sense.

Comment:  Change IQ to AQ?

Accepted.

Comment: Clarify what agility means in terms of foreseen change, and unforeseen change, when think in terms of versatility.  A Swiss army knife is versatile, but not agile.

Agree on versatile.  A Swiss army knife is more agile than a screwdriver.

Comment:  Agility onto the poeple who operate the system.  They don’t want autonomous systems.  They want it to be changed to their purposes

When have people adapting to system performance, and then the system adjusting to work practices, there’s an interdependency.

Could need to change organizational parameters to deal with degraded systems.

#agile, #incose, #iw, #systems, #systems-engineering