Process complexity

Often we believe that if we just instituted good processes, we could hire inexperienced people to follow them, train them well to follow the processes well, and then our projects would go smoothly.

The problem is, most of our projects are not in the realms of "Simple" or "Known" (these terms come from 2 different versions of the Cynefin framework), that which is the proper realm for process reengineering and best practices, where bins can be identified and once you find the bin your situation is in, you just enact the preprogrammed response.

Rather, most of our projects are at least in the "Complicated" or "Knowable" realm, if not the "Complex" realm. In both of these, we have difficulty just following process. Complicated situations embody cause and effect separated in distance or time, so we need to analyze to figure out what the right thing to do is. In complex situations "cause and effect are only coherent in retrospect and do not repeat"...an excellent regime for Monday-morning quarterbacking but not an easy place to predict in advance what to do.

My theory here is that when we find ourselves in a complex or complicated situation and we are told to follow processes that assume a Simple or Known situation, here is where we deviate from the processes. We intentionally apply more knowledge than the processes think is necessary...we use our brains, also called our "internal neural networks".

One advantage that neural networks are known to have that is superior to sequential computing is pattern recognition and associativity...meaning, this is *like* something I have seen before. Our brains do this, much better than processes encoded in text and stored digitally. We look for processes that might handle the current situation, and if we don't see one that avoids the problem we saw in the past, we move on and invent one that we think might be better.

Of course, inventing processes for documenting game software is a bit different in effect than inventing processes for testing a nuclear power plant...the latter could blow you up and possibly destroy a large part of the planet.

In general, we need to become more aware of what complexity is, how it affects our products and our development programs, and what we should do about it.

I am in the process of making new modules related to this for my Complex Systems Engineering course.

Blog-jam

Dan Breslau, in his post "Living Agile", describes what I happened to call "Blog-jam"...(here I unfortunately had to delete his simile...)

"...I’d planned to pick up where I’d left off,... inevitably, just as I sat down to write, a new idea poked its head in. ...hot on its heels came another one,... a third idea showed up...Some of those ideas were so darned appealing. But before I knew it, there was a crowd of them, each struggling to be the first to slide into the keyboard. With all of their jostling, none of them could get through. If I couldn’t break that logjam, this post was never going to happen. ... I’m trying to write a blankety-blank blog, not The Great American Software Book."

I too have too many ideas, not only when writing blogs but even just sitting down to work. Sometimes putting a Task into Outlook with the thought in it breaks the jam. Sometimes writing it up in a Word document and storing it in my Ideas file helps. Often nothing helps and I spend the day dithering.

I will meditate on focusing on one small thing. Thanks, Dan!