2014/01/27 9:45 Tyson Browning, “Program Agility and Adaptability”, Agile Systems and Systems Engineering Working Group

Tyson R. Browning (Neeley School of Business, TCU) 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, Torrance, California

Review articles are at:

Sharing research from recent projects

  • View large projects as complex adaptive systems

Three projects all touch on agility and adaptability, theme around program agility

Working with industry, some automotive and aerospace, the pain of “process”

  • Part from ISO certification and CMMI that stress documentation weighing down on progress and productivity in engineers
  • Is the most agile process then no process?
  • Short answer:  the right amount of process and process increases agility and adaptability, then increasing further becomes stifling
  • It’s how it’s used

The right amount of structure and standardization in a process or program will increase the amount of agility

First project

  • Empirical, second-hand 14 case studies, assisted by grad student who had come back from Iraq
  • Interest in circa 2004-2005 between U.S. Army and Iraqi insurgencies on Route Irish, to be protected for supplies and dignataries (route from airport to green zone?)
  • Both parties, looked at 5 areas:  desired results, process, organization structure, tools and resources using to do activities in the process, and goals-objectives
  • Each of 5 areas is in itself a system, that could be adaptable
  • Tried to view all 5 collectively, to see how the overall could be agile or adaptable
  • Proposition:  projects, programs (maybe organizations or enterprises) if don’t get results, they will change
  • These two organizations changed in opposte directions, on range from no process or structure to highly procedures
  • Insurgencies tried to get more process and structures, more protocols and ways to understand each other, what they could do and when
  • Army was so procedural and structure who weren’t able to respond, had to give more authority and decision-making to lower levels of organization, and take off layers of bureaucracy
  • Each organization moved towards the centre
  • Hypothesis:  the value by each project or program will follow a stylized value curve

Were looking for an analogue in the buisiness world

Four cases:  Looked at Google, Microsoft

  • 5 years ago, Google found needed more procedure
  • Microsoft Project Longhorn (which became Vista) moved to give more authority to lower levels, changes from overly standandrized and burdensome
  • Research looks at the 4 projects in changes with 5 areas

Formed hypothesis:  How do programs emerge or adapt, or exercise agility?

  • Some perception of a value gap (between results they’re getting and what they want)
  • Change action to product, process, and other of 5 systems that comprise a program
  • Change to one will affect other 4
  • Desireable or not, some programs will change
  • Cycle repeats self, speed has to do with agility, can get around cycle faster than an non-agile organization
  • OODA loop, applied to program management rather than users

Focus is on products, and adaptability for the future, like buying options in the futures world

  • However, options come at a price
  • Agility isn’t all or nothing, can selective purchase to increase adaptability

Adaptive Process Decision Framework:  what activities are done in the activity network to get things done?

  • Instead of a Gantt chart in advance, at each step, choose direction with highest value
  • Instead of a priori, then organize as a complex adaptive system
  • Could similate to see which are most favourable

Comment:  these diagrams aren’t included in the paper, so will need verbiage

Current direction is to leave paper the way it is, conscious of word limit

Comment:  Getting at bandwidth of feedback control system, have to keep up with the environment.  Helps to explain the OODA loop.  Puts this into a common body of knowledge terminology.

Comment:  Figure 1 implies sweet spot for insurgents is the same as far the army.  If that’s not what was intended, then need to clarify.

Not every program has the same value curve.  Maybe insurgents on curve 1 and army on curve 2 or 3.

Comment: Conclusion on planning and standardization, requisite planning often not funded, knowledge not well managed.  May not fit with the rest of the paper.

Focus on one plan, but that could become obsolete.

Comment:  Defining terms on what is meant by an agile system, also “stifling burden of process”, moving “decision-making closer to the front line” requires some agreement.  Some process came into being as perceived value.

Stakeholder groups as internal or external, some will or won’t benefit.  Externally-driven via internally-driven.

Many people can come to build many different things.  Agile may require an understanding of what will and won’t work, and can assemble a response that occurs at the projects.

  • Toyota sees changes not has a process but as a theory, can be approved quickly.

Comment::  Careful to say that things like CMMI and ITIL are the problem, as they were the result of major program failures.  Now living with potential overuse.

Could be use for the wrong reasons.  ERP similarly, like pouring wet concrete on processes.


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