What Artists Can Teach Us About Solving Problems in Agile

Imagine being in an art class and your teacher hands you a photograph and a blank sheet of paper. The task seems simple: copy the image. But just before you start, you're asked to turn the photograph over, cover the image with the blank paper, and copy it piece by piece, revealing it as you go.

At the end, the teacher explains: when we see an object the right way up and try to copy it, our brain automatically fills in missing information, making us believe we know something we don't really master. We know what a nose or a leg should look like, but that doesn't mean we can draw them accurately. When we turn the image upside down, that nose stops being "a nose" and simply becomes a problem of lines and shapes to solve.

This experience raises a question in agile: how many times do we look at our organizational problems believing we see them clearly, when in reality we're only seeing what we expect to see?

The Limits of Pattern Completion

The technique of drawing upside down, popularized by Betty Edwards in Drawing on the Right Side of the Brain (1979), is based on how our brain processes visual information. When we draw familiar objects in their normal orientation, we mainly activate the left hemisphere of the brain, which works with known symbols and patterns. We literally draw "our concept" of a chair, not the chair in front of us.

By inverting the image, we force the brain to process shapes and spatial relationships without the shortcut of recognized patterns. As Edwards explains: "The left hemisphere rejects the task of processing information upside down because it finds it slow and confusing, yielding control to the right hemisphere" (Edwards, 1979, p. 63).

This phenomenon of "seeing what we expect to see" is not exclusive to art. Daniel Kahneman, in Thinking, Fast and Slow (2011), calls it "confirmation bias" and "attribute substitution": our brain substitutes difficult questions with easier ones we know how to answer. In an organizational context, this means we often diagnose problems according to familiar patterns, not according to the specific reality of our context.

When "the Sprint Problem" Isn't About the Sprint

The team doesn't finish the work committed to in the sprint. The Scrum Master observes the problem and thinks the team doesn't estimate well, and that planning needs to improve. It's a logical and familiar response. We recognize that pattern, we've read about it, and we know what to do.

But, as in the drawing exercise, perhaps we are seeing "our idea of an estimation problem" instead of the real problem. If we applied the artist's technique and "turned this problem over," covering it and revealing it piece by piece, we might discover something different:

• Part 1 (revealed): developers spend 40% of their time in unplanned meetings.
• Part 2 (revealed): three different teams are requesting urgent changes from the same team.
• Part 3 (revealed): the Product Owner receives direct pressure from stakeholders during the sprint.

Suddenly, what seemed like "an estimation problem" reveals itself as a problem of dependency management, blurred boundaries, and protecting the team. But we only see this when we stop looking at "the sprint problem" as we know it and start observing the lines and shapes that are actually there.

Esther Derby emphasizes exactly this: "The problems we see are symptoms. Effective solutions require that we understand the system that produces those symptoms" (Derby 2019, p. 28).

Three Lateral Thinking Techniques for Solving Problems

1. Turning the Problem Over

The artist's most direct technique is literally inverting the perspective. In agile, this can mean asking the opposite of what we usually ask.

Practical example Instead of: "How do we get the team to commit more?" We ask: "What are we doing that makes commitment impossible?"

This inversion, known as inversion thinking in Charlie Munger's methodology, forces us to identify the forces that sustain the current problem before trying to push toward a solution.

When Teresa Torres works with product teams in Continuous Discovery Habits (2021), she uses a variant of this technique: instead of asking "what features do users want?", she invites teams to explore what jobs users are trying to get done and what prevents them from doing them (Torres 2021, p. 47). Inversion shifts the focus from our preconceived solution to the user's real problem.

2. Covering and Revealing Piece by Piece

The second technique of the artistic exercise was to cover the entire image and reveal it progressively. This keeps us from building a premature narrative about "what we are seeing."

In agile, this translates into deliberately separating different dimensions of a complex problem to analyze them in isolation before integrating them.

Example When a team experiences "low velocity," instead of looking at the whole problem (which activates our patterns of "slow team = needs training/motivation"), we could fragment it:

• Fragment 1: measure only the time from when an item enters progress until it is in review (development time).
• Fragment 2: measure the time from review until merge (review time).
• Fragment 3: measure the time from merge until production (deployment time).
• Fragment 4: measure how much time items spend "blocked" vs. "in progress."*

This fragmentation allows us to identify exactly where the bottleneck is without being carried away by the general narrative that "the team is slow." Perhaps we discover that the team develops quickly, but reviews take days because reviewers are overloaded. Or that deployment is manual and takes hours. Each fragment reveals a line of the real drawing, not the drawing we imagined.

3. Removing Familiarity

A third technique artists use is "blind drawing," or drawing without looking at the paper. This forces concentration solely on the observed object, not on the result you are producing. It is pure observation without immediate judgment.

In organizational coaching, this is equivalent to observing without interpreting, at least temporarily. Michael Bungay Stanier proposes the question "And what else?" as a tool for sustaining observation before jumping to interpretation. Each "And what else?" reveals another stroke of the real problem.

Example In a retrospective where the team reports "too many interruptions," before proposing solutions (closing Slack, focus hours, etc.), we could apply abstraction:

• "And what else counts as an interruption?" (perhaps we discover that HR emails also interrupt.)
• "And what else?" (maybe the ceremonies themselves feel like interruptions to the work.)
• "And what else?" (perhaps we discover that the open space makes any nearby conversation an interruption.)

Nancy Kline (1999) calls this "generative attention": creating a space where information can emerge without our preconceived solutions filtering it prematurely. When people have that space, they often discover that the problem they thought they had wasn't the real problem (Kline 1999, p. 37).

The Danger of "Blind Expertise"

There is an uncomfortable paradox in all of this: the more experience we have in agile, the more vulnerable we become to this bias of "seeing what we expect to see." Experts recognize patterns quickly, which is a huge advantage. But that same speed can become a trap.

Ellen Langer (1989) documents how experts often operate on "autopilot," applying known solutions without examining whether the current context really fits the recognized pattern. Langer proposes the concept of mindfulness as a cognitive disposition to notice new things, be sensitive to context, and remain aware of multiple perspectives (Langer 1989, p. 62).

This raises an uncomfortable question: how many times have we diagnosed "the team needs more autonomy" when the real problem was a lack of strategic clarity? Or recommended "more collaboration" when the problem was too much unnecessary synchronization?

When to Turn Problems Over (and When Not To)

These techniques are not universal solutions. Turning everything over, fragmenting every problem, and questioning every observation would be paralyzing. We need our recognized patterns; they are valuable cognitive shortcuts that allow us to function.

The key lies in developing what Chris Argyris called "reflection-in-action" (Schön 1983): the ability to notice when our habitual patterns aren't working and consciously shift our mode of thinking.

Signs that it's worth "inverting" the problem:

• You have tried the obvious solution and it hasn't worked.
• Different people describe the same problem in very different ways.
• The solution seems clear but nobody implements it.
• The problem keeps reappearing after you "fixed" it.
• Your initial reaction is very strong or very fast (a sign of pattern activation).

Signs that your recognized pattern is probably correct:

• It is the first time the team faces this problem.
• The circumstances are similar to previous successful situations.
• Multiple independent observers see the same pattern.
• There is objective data that confirms your initial hypothesis.

From the Art Class to the Daily Scrum

Let's return to the photograph exercise. What's interesting is not only that when drawing upside down, many students produced better drawings. What's truly revealing is that after that experience, when they went back to drawing the right way up, they drew differently. They had learned to see in a different way.

In agile, consciously incorporating these techniques can fundamentally change how we diagnose organizational problems. It's not about rejecting our experience or our frameworks, but about having tools for when that experience is limiting us instead of helping us.

Some concrete ways to incorporate this into your practice:

• In retrospectives: before jumping to solutions, dedicate explicit time to "fragmenting" the problem. If you have identified "lack of communication," ask: "What specific kind of communication is missing? Between whom? At what point in the process? What exactly happens when that communication doesn't occur?"
• In coaching: when a leader presents you with a problem, consider asking them to describe it "from the end back to the beginning" or "from the perspective of someone who thinks completely opposite to you." This inversion often reveals hidden assumptions.
• In product discovery: before designing solutions, fragment the user's work into micro-moments. As Torres (2021) suggests, don't ask how we make checkout easier but what the user is doing 30 seconds before abandoning checkout. And 30 seconds before that?
• In agile transformations: when planning change initiatives, apply Munger's inversion: list everything that would guarantee the transformation fails. You may discover that some of those things are already happening.

Discomfort Is Information

There is something uncomfortable about these techniques: they require admitting that perhaps we weren't seeing what we thought we saw. For those who hold roles as experts, coaches, or facilitators, that can feel like vulnerability.

But perhaps that discomfort is precisely the point. The best professionals are not those who have the most answers, but those who best tolerate uncertainty while exploring complex problems. The ability to say "I thought I understood this problem, but let me look at it another way" is a strength, not a weakness (Schön 1983, p. 69).

As adults, when something overwhelms us, we can ask ourselves: am I seeing too much at once? Am I looking at it the right way up when I should be inverting it? Am I drawing my concept of the problem or the problem I actually have in front of me?

The answers won't always be clear, but the question itself changes how we look. And sometimes, that change in perspective is the difference between repeating solutions that don't work and finding the specific stroke we needed to adjust.

Bibliography

• Argyris, C., & Schön, D. A. (1978). Organizational Learning: A Theory of Action Perspective. Addison-Wesley.
• Derby, E. (2019). 7 Rules for Positive, Productive Change: Micro Shifts, Macro Results. Berrett-Koehler Publishers.
• Edwards, B. (1979). Drawing on the Right Side of the Brain. J.P. Tarcher.
• Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
• Kline, N. (1999). Time to Think: Listening to Ignite the Human Mind. Cassell Illustrated.
• Langer, E. J. (1989). Mindfulness. Addison-Wesley/Addison Wesley Longman.
• Marquet, L. D. (2012). Turn the Ship Around!: A True Story of Turning Followers into Leaders. Portfolio.
• Schön, D. A. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books.
• Skelton, M., & Pais, M. (2019). "Team Topologies: Organizing Business and Technology Teams for Fast Flow". IT Revolution Press.
• Stanier, M. B. (2016). "The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever". Box of Crayons Press.
• Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.