Boundaries of mental modelsMy industrial clients are used to products which are more complicated than complex, and thus processes where design is based on thorough analysis and careful tracking of requirements. They are used to heavy investments in machinery, and high levels of precision and standardization to enable efficient, large scale production of identical products.
It's almost impossible not to be shaped by the things we have done, both as individuals, and as organizations. We obviously use our previous experiences when we venture into new fields, and in my opinion, it's one of the hallmarks of intelligence to learn from whatever we do, and then utilize what we learned in new situations.
A problem in this is to understand where the boundaries lie for the mental models we form, since misapplied models will lead us astray. We might use the same words, and think that we are in agreement about a system we're building, but suddenly someone says something casual, and you realize that they are seeing something entirely different than you do. Maybe it's a big eye opener for you, or maybe you suddenly feel that someone else is in need of a big eye opener...
Looking from a different angleSome time ago, I heard a manager in a product development company talk about the upcoming first release of a cloud based software service as a Minimum Viable Product, and that surprised me, because to me the planned scope was way beyond what e.g. Eric Ries describes in The Lean Startup. But when he continues I understand, because he suggests that the next bunch of features would be released in a second major release, maybe six months after the first release.
We've been working hard to implement a continuous delivery pipeline, with the capacity to put newly developed features into production in maybe an hour from development, and management still thinks in half year release cycles... Almost as slow as new car models...
If he, with his background in heavy industry, had been charged with diversifying the company, and opening a chain of fast food restaurants, I'm pretty sure he'd suggested that we first open a single, small restaurant and learn from that, instead of opening lots of big restaurants at once. If he had been informed that a dish in the menu got massive complaints from the customers, he would never have suggested that we deal with that in a "second major release" six months from now.
While planning is certainly important in the restaurant business, planning too much in detail would be like planning all the moves in a chess game before you start. That strategy will fail quickly. Same thing with the restaurants. Your ways of working need to be based on rapidly responding to feedback from a ruthless reality, with your goals constantly guiding you.
Complicaded vs ComplexPeople get used to their tools. If their tools are gated processes, strict separation between R&D and operations, meticulous traceability tracking etc, it might feel very careless not to use these tools in substantial investments. When they learn about "agile" they see sloppy ways of working, since their standard tools, their safety nets, are missing.
A carpenter wouldn't try to use saw and hammer if had to cook meals instead of building a house. The difference would be so obvious that he'd realize that his normal tools were far from optimal.
People used to traditional, plan-based development don't see that agile processes mainly are for the complex domain, and their old tools are limited to the complicated domain, since they aren't aware of the distinction. They also don't see that a lot of their tools exist to manage complications that the agile processes eliminate if applied correctly.
For more about complicated vs complex, I'd suggest investigating the Cynefin Framework, which was first published as A Leader’s Framework for Decision Making in Harvard Business Review, and then elaborated further by Dave Snowden.