Systems Thinking

A PMI "Agile Thought Leader," speaks about systems thinking.

"Systems thinking is a conceptual framework that takes the view that understanding how systems work requires a holistic view & realization that systems exist within other systems. None of these systems (or system of systems) are well-defined by the components themselves but rather are driven by the relationships of the components."

Yes, that's one approach to systems thinking, but let's look at systems thinking from the point of view of Systems Engineering (I have a Graduate Degree in this subject, so my POV may be different from the agile thought leaders who coach and train agile software developers.

But first a serious flaw.

None of these systems (or system of systems) are well-defined by the components themselves but rather are driven by the relationships of the components. Is simply not true in our Systems Engineering world. The modeling of the system starts with the models of the behaviors of the individual components, and then the interactions between the components.

What is Systems Thinking?

The Systems Engineering Body of Knowledge, from INCOSE, IEEE System Council, and Stevens Institute of Technology says ...

Systems Thinking is a starting point for dealing with real world stituations using a set of related systems concepts...
  • Wholeness and Interaction - A system is defined by a set of elements that exhibit sufficient cohesion, or "togetherness," to form a bounded whole (Hitchins 2007; Boardman and Sauser 2008).
  • Regularity - is uniformity or similarity that exists in multiple entities or at multiple times (Bertalanffy 1968). Regularities make science possible and engineering efficient and effective. Without regularities, we would be forced to consider every natural and artificial system problem and solution as unique. We would have no scientific laws, no categories or taxonomies, and each engineering effort would start from a clean slate. But regularity does not mean static but can also mean probabilist or stochastic.
  • State and Behaviour - a quality or property of a system element called an attribute. The state of the system is the set of system attributes at a given time. These states can be: static (a single state exists with no events), dynamic (multiple possible states), homestatic (is static but its element are dynamic).
  • The state can be monitored with state variables. The set of possible values of the state variable are called the state space. State variables are generally continuous but can be models using a finite-state model or state machine.

More details are at Concepts of Systems Thinking

Why Are Systems Important?

Let's start with systems thinking from the professional organization where System is in the name - International Council on Systems Engineering www.incose.org.

A system is a set of parts that, when combined, have qualities that are not present in any of the parts themselves is a very productive way of looking at the world – which turns out to be full of systems. Engineered systems are much broader than the association with engineering might imply: the elements or parts of a system include people, processes, information, organizations, and services, as well as the software, hardware, and resulting products and services that fulfill the needs of those paying for the development and operation of the system.

Some Definitions of Systems Thinking

Systems Thinking enables you to grasp and manage situations of complexity and uncertainty in which there are no simple answers. It’s a way of learning your way to effective action by looking at connected wholes rather than separate parts. It is sometimes called practical holism. [Open University definition]

Systems thinking is a framework for seeing interrelationships rather than things, for seeing patterns rather than static snapshots. It is a set of general principles spanning fields as diverse as physical and social sciences, engineering, and management. The Fifth Discipline, Peter Senge.

Systems Thinkers Recognize that ...

  • People - through their perceptions, determine the purpose, use processes to deliver performance, and use change in patterns to measure progress.
  • People - understand the need to be good team players.
  • People - are our customers, stakeholders, designers, developers, and users.
  • People - have varying levels of rationality, intentionality, and even perversity.
  • People - have belief systems, perceptions, and viewpoints developed through culture, training, and views of best practice within disciplines.
  • People - are not separate from the problem, project, or program with which they are engaged. They are an integral part of System Thinking models.

Performance measurement...

  • Needs to be supported by evidence and suitably monitored to ensure that the purpose of the system is being fulfilled.
  • Is a combination of quantitative and qualitative measures that communicate a historical and forward view of performance.
  • Is often done inappropriately because people choose to measure what is easy to measure, rather than what needs to be measured to ensure that purpose is delivered.

Uncertainty...

  • Is an inevitable attribute of a complex system.
  • Is managed by first recognizing what we do not know and expecting unintended consequences particularly when new systems are being introduced or systems are used in a different context.
  • Requires the inclusion of feedback and feed-forward learning loops in the process to minimize its impact.

Let's look at the ideas presented by thought leaders of PMI Disciplined Agile

  1. Systems thinking is a conceptual framework that takes the view that understanding how systems work requires a holistic view & a realization that systems exist within other systems. None of these systems (or system of systems) are well-defined by the components themselves but rather are driven by the relationships of the components

The notion that none of these systems are well-defined by the components ... but rather driven by the relationship of the component ... ignores the principles of systems engineering. The behavior of individual components is the starting point of systems thinking.

The qualities that emerge at the level of the whole only come about when the system elements interact with each other and their environment, and only exist when the components of a system are able to interact. Although emergence brings the risk of unintended consequences, a major cause of embarrassing system and project failures, skilled systems engineers can create higher value for less cost by using emergence to deliver desired system qualities.

  1. Systems Thinking is a way of thinking used to address complex and uncertain real-world problems. It recognizes that the world is a set of highly interconnected technical and social entities which are hierarchically organized producing emergent behavior.

The understanding of systems starts with the network of system elements, not the hierarchy. Systems Engineering models systems, so the interactions between the elements of the components in that model. If that interaction is along the path of a hierarchy, fine, but rarely if ever is a system a hierarchy is its actual state. To be in the hierarchy would mean each component is related only in a parent and child relationship, possibly a cousin to uncle relationship.

The hierarchy of elements can be:

  • System - an integrated set of elements that accomplish a defined objective. What is to be created.
  • Subsystem - is a system in its own right, except it normally will www.nasa.gov not provide a useful function on its own, it must be integrated with other subsystems (or systems) to make a system.
  • Components - are elements that make up a subsystem or system.
  • Parts - are elements on the lowest level of the hierarchy.

In the real systems world, networks of components are the natural topology, since the reason for any part, components, subsystem, and the system is to provide a capability or accomplish some job, where the part, components, and subsystems interact to provide the system with the ability to deliver that capability.

There can be a hierarchy, but that is only one pattern of systems thinking. See Hierarchy and Network Patterns in Patterns of System Thinkingmeta patterns. Network patterns can be traditional where the network topology is a bus (common backbone), ring, star (central hub), tree, and mesh (multiple routes). The second type can be social and other complex patterns, such as percolation, cascades, power law, scale-free, small worlds, semantic networks, and neural networks. There can also be There can be meta-patterns as shown in the table of Patterns of System Thinking

3. The Systems Thinking view has usually been missing in most parts of Agile, particularly those based on frameworks that have prescribed practices. The culture and attitudes of the people adopting the framework are part of the system. No framework exists on its own and therefore its practices may not be fit for purpose. Practitioners and consultants can improve their frameworks by adopting some central thoughts of systems thinking

Yes, agile says nothing about systems. This is not because the people adopting the framework are part of the system, it is because agile is not based on any external principle, other than the Manifesto and the 12 principles. No principle in the form of Systems Engineering Principles at NASA, INCOSE's Systems Engineering Principles are the basis of agilely writing software for money.

4. Changing one part of the system affects other parts of the system, often with unpredictable behavior.

It's only going to be unpredictable when you don't have a model of the system. And if you don't have a model of the system, you're doing stupid things on purpose, since modeling of systems is straightforward. Find all the components of the system. Find the behaviors of those components in some analytical manner. If they're deterministic that's easy. If they're non-deterministic, then develop a probabilistic or stochastic model for that non-deterministic system. Start with a simple approach "A uniform framework for modeling nondeterministic, probabilistic, stochastic, or mixed processes and their behavioral equivalences."

Then connect the dots between the components, and model the behaviors of those connections - probabilistic or stochastic.

Then build a model of both the components and their interactions. Lots of tools for this.

Without this component and interaction model, you'll not only get complexity you'll get chaos

5. Systems manifest patterns of behavior, the understanding of which can help improve them

This is the case when you have a model of the system. It's individual elements, the individual behaviors of these elements, the connections between the elements, and the probabilistic or stochastic behaviors of the elements and the interactions.

A good place to start for modeling systems in this manner is Design Structure Matrix Methods and Applications. Design structure matrix (DSM) is a straightforward and flexible modeling technique that can be used for designing, developing, and managing complex systems. DSM offers network modeling tools that represent the elements of a system and their interactions, thereby highlighting the system's architecture (or designed structure). Its advantages include compact format, visual nature, intuitive representation, powerful analytical capacity, and flexibility.

So when you hear you can't model complex systems, even complex adaptive systems it's simply not true. Go read the book, follow the MIT DSMWEB site, read works by Tyson Browning, and learn to think like a systems engineer in our complex adaptive system of systems domain.

6. Systems interact with the systems they are part of a holistic view must be taken when looking where to start.

Yes, basic systems engineering principles.

7. Wherever started, the goal should be to affect the larger system. This requires attending to how those in the starting point are affected by and affect other parts of the organization.

Maybe, depends on what your assignment is. The enhancement of a sub-system or even a system element may be the goal.

Define the problem first before defining the solution
John Reeder, PMP, SSGB, CSM, JD

Difficult projects are the most enjoyable to tackle

3 年

‘Defining the problem first before the solution” should be recognized be all practitioners, whether Agile or not.

Mike Barcikowski

Senior Consultant-Defense/Space/Aerospace/Energy/Environmental Services (Contractual, Program and Financial)

3 年

Thanks excellent Glen

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了