Agile learning for starters

I have previously discussed the "cost of learning" and it's impact on the learning strategy. After establishing that we should always keep this cost of learning below the Point of No Return, let us consider the differences in learning. The dogmatic statement "A coach should not prescribe a solution, but foster self-learning", presumes that self-learning is universally the best approach. But is it?

Let us consider which companies/teams typically call for help, based on this simple model:

Do you know why you don't know what you don't know?

There's a hidden relationship to the Cynefin Framework hidden: Software development is a socio-technological problem, and the issues of communication, understanding and skill are just a few factors affecting the team's performance. We work in the complex domain, where any model has an inherent error.
Usually, when a company requests external help, they tend to be basically aware that they don't really know what their problem is and that they assume someone else can help them make progress. In terms of our model, uncertainty is high and people admit that their specific knowledge and understanding of the problem domain is shallow. That's good. It's a basis for learning.

Initiaing problem solving

We have a wicked problem here: How do we know we're doing the right thing - and how do we know we're getting better at it?
A consultant has no choice other than first gaining clarity whether the problem is comparable to a problem where a solution is known, so would first try to drive down uncertainty - by asking questions and experimenting with the process.

If the problem is in a domain where deep expertise is available, the problem solving process is reduced to tapping into available expertise.

If the attempt to reduce the problem to a domain where a solution is known fails, this indicates that we're working in the domain of the Unknown.
This one splits down again:Either, we know that all known solutions fail, in which case we need to innovate - or all attempts to reduce uncertainty failed, which indicates our problem is ill-defined and we need to clarify the problem until we have a workable problem.

Innovative problem solving

If there is need to innovate, we're pretty much clear that we'll be using empirical data, feedback loops, inspect+adapt and experimentation to iteratively anneal the situation. The best thing a consultant can do in this situation is to provide support based on their own experience to discern which experiments make sense and what the available data implies.

There are tons of techniques for innovative problem solving, starting with Kaizen Events, Design Thinking, TRIZ ... potentially even a full blown Design For Six Sigma (not advised). Determining the suitable problem solving technique may also at the discretion of the consultant.

Introducing known solutions

When expertise is available, the consultant must factor in the impact and urgency of getting the problem solved.
Impact is high when there is a risk of crossing the Point of No Return, i.e. destroying the company / team, or have individuals lose life, health or their job.
Urgency is high when you only get one shot.

• If both impact and urgency are high, a dogmatic solution will save time at the expense that the inherent understanding remains low. Autonomous learning is purposefully replaced with prescriptive approach for a greater good.
• If impact is high, yet urgency is low, the consultant may choose to underline the solution process with moments of learning to deepen understanding. This will reduce long-term dependency and the risk for misunderstood assumptions around the solution.
• If the impact is low, yet there is a sense of urgency, the consultant might actually provoke "learning from failure" to create deep understanding for the next time.
• If both impact and urgency are low, the consultant should not invest further time. Providing a pointer on how the team could learn solving the problem can be sufficient. If they learn - good. Otherwise - no harm done.

Summary

In this article, I described only the consultant's approach when the team is lacking knowledge and ability that is available to the consultant. A different approach is required the team's knowledge already exceeds that of the consultant.

A good consultant weighs the costs of learning against the benefits of learning and chooses the optimal approach, carefully considering the tradeoff between short-term results and long-term results.

Innovative problem solving should generally not be used for known solutions, since that approach is inherently inefficient. Although it facilitates learning, it also maximizes the cost of learning.

Peoples who dogmatically insist on facilitating innovative problem to maximize learning solving might force the team to reinvent the wheel when a firetruck is sorely needed. That's not helpful. It's snake oil.
There are times for learning and times for just doing. Know the difference.