Engineering is often misunderstood. People see overpasses being built and think that that is engineering. While admittedly that’s an aspect of engineering, building overpasses is mostly manufacturing outdoors. Billy Koen, in “Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving,” says:
“The engineering method is the strategy for causing the best change in a poorly understood situation within the available resources.”
Albert Einstein provides further insights with:
“Scientists investigate that which already is; Engineers create that which has never been.”
Edwards Deming talks about the need of both with:
“Experience by itself teaches nothing… Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.”
Combining engineering with science has us:
- Use an existing practice that has demonstrated its efficacy in our situation.
- If one doesn’t exist, we look to what’s understood (flow, Lean, ToC, …) and create a new method or modify an existing one that looks like it will be an improvement.
- Have a plan to back out the change if necessary.
Implement the practice and see if it’s an improvement. Seeing the direction of effectiveness is more important than having a specific measure.
At short intervals, or when a clear success or failure has occurred, do a post-mortem as to why what happened happened. Use this to improve the theory underlying what you are doing. If the practice attempted was flawed, see how to improve both it and the decision to choose it. Avoid the temptation to blame the people for not being motivated or trying hard enough. Focus on making your approach easier to understand and use. Clarify the conditions in which it should be used. Recognize this is as being as, or even more important, as the results you achieve.
Double and triple-loop learning. Double-loop learning involves questioning your assumptions and beliefs and in particular what your objectives are. Triple loop learning is learning how to learn by reflecting on how we learn in the first place. This is perhaps the biggest difference between an engineering/science approach and frameworks – the former embraces being challenged while the second defends itself from them by requiring certain practices to be followed. That said, this approach can be applied to frameworks to improve them.
The Agile space has seen recurring patterns of failure in adopting frameworks. Much of this is due to not attending to why adoptions fail. There is much we can learn from how engineers, architects, and other engineering-related roles continually improve their discipline
Thinking for yourself with an engineering/scientific approach is often considered harder, but that confuses effort with the difficulty of achieving value. Yes, thinking may be harder, but achieving value with it is easier. In any event, readily tailored approaches can be presented to start with based on an organization’s context.