
CD-ROM contains: Simulation software and Models including ithink,Powersim, and Vensim.
Systems thinking changes the way people think about solutions, often for the better (but not always). There's a tendency to think: "uh... it's the system, nothing's gonna change unless we change the _system_ per se". And that's correct. But individual actions also change systemic outputs. So. Case in point: climate change and all that...
[fun fact, I took a class with Sterman at MIT. He's fantastic, very engaging!]
[1] https://mitsloan.mit.edu/faculty/directory/john-d-sterman
Yes. Don't be dogmatic. Pick an initial set of processes/practices that match more or less what you already do, want to do (based on a reasonable belief of utility and practicality), or have done (with success) in the past. As you move forward, periodically reexamine what you do and change when something isn't working well (in Scrum this is the Sprint retrospective, which seems to be the first thing cut from every Scrum-derived process I've ever been part of or near to "save time"). Experiment not just with your code and systems, but with your processes and organizational structures themselves. If you only apply things like the ideas of Extreme Programming to your programs, you're only doing half (actually less) of what Agile aims for.
Sterman in his Business Dynamics book has a nice set of diagrams starting on page 15, talking about feedback loops/systems for learning.
Attempting to draw them as ASCII art, not that skilled at this:
Simplest feedback model:
Real world
^ \
/ \
/ v
Decisions<--Information feedback
This is a very common thing, people make a decision, try it, get info, and make new decisions. What they don't do is extend this feedback to their decision making model. He extends this model on page 16 with: Real world
^ \
/ \
/ v
Decisions<--Information feedback
^
\
\
Strategy, Structure,
Decision Rules
^
\
\
Mental Models
of Real World
Again, note that the feedback does not go back to the mental models which feed into the decision making strategies and, ultimately, the decisions. This is the dogmatic approach to any process. You select it, and you run it regardless of its real applicability or utility but based on a belief that you don't update (because it's dogmatic). Doesn't matter if this is Agile (big-A) or big design up front (BDUF) or anything else, if you don't reconsider your models then you will not be agile, you will be stuck. This doesn't mean things won't work, you may have settled into a local optimum (on accident or on purpose). Maybe things are done this way because they've always been done this way, but 30 years ago someone did think about the business and selected something that worked (deliberately) and things haven't changed much so it happens to still work well. But once it fails, you have no deliberate way of adapting to the new reality (which is a key to being agile, responsiveness).The final model he shows on page 19 brings that feedback to not just the decisions but also the models (this is the hard one to put into ASCII art):
Real world
^ \
/ \
/ v
Decisions<----Information feedback
^ ^|
| ||
| |v
Strategy, Structure,<----Mental Models
Decision Rules of Real World
This, to me, is the critical thing to agility and if you focus just on the manifesto and not the Agile Industrial Complex (and fuck SAFe and others like them), you will see that this is present (though less explicitly). Paying attention to feedback, trying new things, being adaptive. That is the essence of agility and Agility.=======================
Regarding using a shared spread sheet or something else for managing your work, that's all about scale. A 4-person team can use a spreadsheet for status management, it may not be the best, but it will totally work. Scale up to 4 teams, each with 10+ people, possibly geographically separated, and you'll need something else. But take one 4-person team or 4-teams that are all located in the same space, you could manage your status with sticky notes on a whiteboard and probably be as successful as with the spreadsheet or the fanciest project management software (and maybe more successful in some cases because of the relative ease and flexibility sticky notes on a whiteboard afford compared to the fixed, or more fixed, workflows of most PM systems). What you record, how often you review and consider things, those are going to be more critical.
I lent my copy to my brother over a decade ago. Still haven't got it back...
Also Exploring Requirements: Quality Before Design by Donald Gause and Gerald Weinberg. Really useful advice about questions to ask people to understand what the system really does/should do.
John Gall's _Systemantics_ is a classic, but it's a bit cranky.
Related:
John Boardman, _Systems Thinking_.
Gerald Weinberg, _An Introduction to General Systems Thinking_
John Sterman, _Business Dynamics_.
Take for example the "chicken-egg" problem. Economists study this under "multi-sided markets" (which the author touches on, but late in the example), as part of the study of path dependency. Systems dynamics researchers have framed the economics work in their own terms of stocks and flows, but the essential structure is the same and can be reduced to equations. It's mostly calculus, sometimes there's some linear algebra.
The best book in my view is still Sterman's Business Dynamics, which is much broader in scope than the title suggests (it's a play on earlier book titles). There will hopefully be a second edition in the next year or two.
Edit: I should note however that when I see "system" I pattern match on what I know best. But there's a whole discipline of "System Engineering" which comes mostly from defence, aeronautical and astronautical fields. It has a high focus on formalisms to try to govern immensely complex technological efforts.