This may just be throwing a half baked idea out. That said.... I was looking around on the net for some discussion of "lean", since people seemed to be talking about it as an alternative to Agile, and my sense of Lean was not an alternative. Perhaps a less structured version of Agile? (it seems to me Agile has become an umbrella under which Lean and others congregate).
I looked at a link to Wiki about Lean development, and from there to several links down into underlying theories (psychology, etc etc).. I keep coming up with the same thing: that Agile is an effort to pull together more humanistic theories of motivation and, perhaps, communication, into a working model.
And I keep coming to the same conclusion. The more effort put into creating the model (the rules?) , the more explicit the working model, the further away people seem to get from understanding and using the concepts.
This circles back to your description of systems. I wonder though if it also points to a weakness in a straight systems approach. Ie, is describing a system technically also another way to provide more detail about the model, where you lose understanding buried in the details?
For example. If you look at theories of motivation (intrinsic vs extrinsic)..... there a decent (I think) summary of those in wiki here http://en.wikipedia.org/wiki/Motivation . If as you read through these you start highlighting elements that seem obvious within Agile.... I think there's an aha moment in the effort. There's clearly a strong leaning (pun intended) towards a Maslow, even Rogers, approach. Maybe combined with some social interaction theory.
If you look at Measurements.... for example here http://en.wikipedia.org/wiki/Measurements and scroll down to Definitions and Theories.... the concept of story points etc., seem to be based, to a high degree, on "Representational Theory"... perhaps using representational theory to get to Information theory (??). Ie, accept the uncertainty of measurements, use ranges and relativity in what you're measuring, to evolve a more accurate measurement (estimate)
Imperfect, not fully refined, examples. But in my mind these are the things that Agile, Lean, etc all seem to scream out. But people dont seem to "get" that?
I dont see how people can implement Agile successfully until they understand that. Going through the motions of the detail will always run into problems. Perhaps will always fail ?? because no two projects, no two companies, no two teams of people, will be exactly the same. The variables in the differences will respond to the underlying theories, but not necessarily implementation "rules".
Ie how can so many people spend so much time talking about specific rules, or practice, without understanding those underlying theories. Or, at least at some point, going "aha, all this "stuff" we've been talking about all relates to these theories"..... then issues like arguing for months and years over "face to face" become true Waste (in the Lean terminology)... as an example.
I have to wonder if the weakness in applying Agile, in many instances, is the result of the mind set of the people trying to implement it. That is, the developer's, or the technicians, mind set ? If many of these discussions, even books about different methodologies, are 1) missing the point entirely because the people writing them have the same mind set or 2) trying to describe the concepts in a way that mind set hears it , rather than shifting that mind set so it can understand the concepts.
#2 is not ideally said but I'm thinking back to simplistic psychotherapy concepts like : dont just look at what the world does to you, look at how you cause the world to do things to you. Ie, change, or add, to your perspective.
So maybe looking at systems helps people suspend their specific mind set to see another perspective. hmm.... interesting, if I run with the ideas, I keep ending up with a conflict between what I think of as a technical, vs humanistic, approach to things. Hard science vs intuition. Pavlov vs Rogers/Maslow. Quant vs Chaos theory. (holding head)I agree with Stephen. Focusing too much on the details of Agile, the practices, can easily make us loose sight of the purpose of those practices. We can also loose the connection with the underlying attitudes that are fundamental to Agile. This has happened before, with TQM, with Lean, with SPC, and many other methodologies. The practices get separated from their paradigm, and retrofitted into the old paradigm. It may work, after a fashion, but most of the benefits are lost.
What about you? Do you agree? If not, why? If you do, is there a way out? What can we do to educe an understanding of the Agile paradigm?