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