Some Pitfalls In Experiential Training

Training classes using an experiential approach has more and more become the norm in agile leadership trainings. Check if some of these pitfalls are something you need to design around as you prepare your next class.

Many trainers in the agile world are really good at using interactive exercises to engage participants. I’ve been a teacher in many different kinds of classes over the years. In the mid nineties I worked extra during my studies teaching evening sessions on how to office software. And photo editing. For a brief period I did some training in a content management suite for a client at various sites.

The last thirteen, fourteen, years or so I have been teaching various agile related classes, the majority of them scrum-related. This opportunity has given me many opportunities to make interesting mistakes”. Some of them I believe I have even learned from.

Here is a batch of tips on how to avoid some common traps that I’ve seen myself and others step into.

Interactivity vs Experiential Learning

I’ve always had a lot of interactive elements in my trainings even before I first came across the concept of experiential learning. The realization that there was something important missing from the way I taught came when I first attended workshops that were facilitated by a true master in experiential training (this was, of course, Jerry Weinberg, see book reference below). This happened about ten years ago. I came to see that it is not just about the interactivity (which makes the training more fun and engaging than a typical lecture) but about truly making new insights from engaging experiences and skilled reflection.

Experiential learning is based on the idea that knowledge is constructed rather than transferred. An example of trying to transfer knowledge would be a lecturer presenting a prepared set of slides while listeners follow along and take notes. I love a great talk. These days, however, I find that I might as well get them on Youtube. If it’s just the information I’m after, it seems very wasteful to move my body to a new location just to get at it. Let the information come to me, rather than the other way around.

The model I now use to design and facilitate these kinds of sessions looks something like this (and is described in the books referenced by the end of this article). It builds on the concept of the experiential learning cycle as described by Kolb. I learned about it first by watching Jerry Weinberg in action:

  • Exploration: invite participants to a seemingly simple task – that actually turns out to be more challenging than it first seemed
  • Invention: help participants put words on their experience, harvesting insights and constructing new knowledge. Also: add some theory from your domain of expertise that helps complete the picture. More about this “addition of theory below”.
  • Application: let participants figure out how what they’ve learned relates to “life outside the classroom”, so that the learning becomes real and useful. This might also mean that they take what they’ve learned in this particular part of the class and use it in the next part. For example: participants take their insights about the importance about having clear “working agreements” and next attempt to actually use the agreements they just formulated.

Without further ado: some interesting pitfalls that I’ve experienced and hopefully learned a bit from.

Navigating the Context

In experiential workshops and classes, so much is going on all the time. If you do it right, participants are constantly exploring new insights and concepts. The backside of this is that we might lose track of where we are every now and then. Some are more sensitive to this than others.

For myself, I have noticed that I am often quite immune (but not completely) to getting lost, because when I’m deep in learning mode I keep seeing interesting stuff everywhere I look. This means that I have to make a conscious effort when I teach to remember that some participants need to know “where in the agenda we are” is much greater than my own.

A physical agenda on the wall can help a lot for some, especially if you stop every now and then to publicly reflect on what’s been covered and what remains. I personally find this insanely boring, so I keep trying to come up with ways to make it more fun. One way I like is to let participants recap in small groups or pairs. To avoid being overly constrained by the agenda I choose to keep it a high level. This lets me observe and adapt as needed, while still keeping a general direction towards the learning goals people came to the class to satisfy.

Another part of navigating the context is to give some sort of introduction when you open up new topic areas. The more of an expert you are in your field, the more prone you will be to miss this. Why? Because to you it seems so obvious what you are talking about. Others may completely lack the mental models needed to understand just what the heck you’re talking about now. I find that storytelling is one powerful way of setting the scene in the right way.

And speaking of setting the scene. Therein lies another potential challenge when it comes to designing and facilitating experiential training sessions.

Use Just Enough Setup

While the experiential approach rests on letting learners use experience and reflection to construct knowledge, this does not mean that they should be left completely to their own devices.

The desire to let participants step into exploration sometimes makes us act too quickly. We kick participants off into a task that they have had no chance to get their minds around. If the learning goals had to do with learning how to act when the goals are unknown that would be fine, but if that’s not the case, it’s likely that your lack of setup moves the group in the wrong direction. If you notice that participants are struggling to understand something that you thought was very clear, then a lack of proper setup might be a reason.

Just enough setup might include giving participants a clear set of written instructions. It definitely means giving them a seemingly simple and clear task, the complexity of which is only revealed as they start struggling with it.

An example might help. When I teach story mapping I’ve come to realize that while the technique seems simple enough for those who have used it, those who haven’t yet tried it don’t find it quite so obvious. When doing story mapping for real with a client group for the first time, I’ve used Jeff Patton’s excellent advice from his book on the topic: we do a simple story mapping of how we go about our mornings. By using an example from a simple and relatable domain, we get more brain cycles left to focus on understanding the actual approach. Then we can safely start working on the real situation that needs to be mapped out.

With less time available to teach the concept, however, things are a bit trickier. In my product owner classes participants work under some time pressure to explore a product concept they’ve come up with in the class. A part of this is creating a story map for the product. Here is how I prepare participants for this part of the training:

  • First, I explain that I still cannot explain story mapping in a brief and clear way, and that the best way to learn is to actually try it.
  • Second, I still provide a brief explanation of the technique, while emphasizing that I don’t expect anyone to truly get it. It’s just a flyover over what is expected.
  • Third, I ask participants to study a very small example in a handout I provide, just for a few minutes.
  • Finally, groups are invited to create a story map using stories we have previously sketched out.

In this particular class module, since the focus is not on learning about the group dynamics in the situation, but the technique itself, I stay available to coach any team that gets stuck or has questions about how to do the work. Mindfully choosing how to adjust your behavior as a teacher in the different phases of the experiential learning cycle is key, but more about that in a bit.

Debrief With Powerful Questions

The absolutely biggest and most important insight for me has to do with the importance of debriefings: of helping participants construct their own knowledge. This is sometimes misconstrued as “letting people learn whatever”, but this is not the intention. We do have some learning goals in mind as teachers that we want learners to explore around.

In experiential training, your role as teacher is to help participants make sense of the experiential exercises you’ve created for them. One could argue that all learning is experiential. If this is true, that means that the tools you are using in your debriefings stay useful once participants leave the classroom. The option to learn more from experiences is available to us all the time. This may very well end up being the most important skill you teach.

The pitfall here lies in falling back to the deceptive safety of transfer mode. We know this has happened when we start talking about what we need to “cover”, as if simply mentioning something means that we’ve helped anyone learn about it.

This might happen when an experience has just ended and it’s time for debriefing. Instead of letting participants construct their own learnings, we step in, take over, and start to explain what the takeaways are. As an aside, I always get irrationally annoyed when a conference presenter ends a presentation by stating “the takeaways”. I’ll decide on my own takeaways, thank you very much.

I find that the way to prevent this destructive over-helpfulness is to prepare my debriefing approach as carefully as I prepare the experiential part itself. I prepare a specific set of questions that I will use to facilitate learners construction of new insights. These questions take the form of very open and powerful, or generative, questions. They open up for reflection and further discussion, and thus help learners engage in investigating what they are actually learning.

Control Your Interactions

Speaking of preparing ourselves, it’s helpful to think about how to interact with participants during the different phases of the learning cycle. During the explore part, I find that it works best if I step into the background. The more I intervene in the exercise, the more it seems that I rob participants of their own sense of responsibility for the work to be done – and with that much of the possibility for true learning. The situations turns to be about how well I can help them, as a trainer, rather than about how well they can construct new insights from what just happened, using skilled reflection.

I recently found myself on the other side of the table in this situation as I participated in a training. Just as I was about to grasp what I was expected to do, a trainer stepped in to help accelerate the process. I did learn from this, of course, but probably not what the trainer intended me to learn. My primary takeaway turned into a clear insight about just how disruptive and emotionally challenging it can be to focus on a challenging task, only to have someone else step in and take command. This was, by the way, a world class trainer, so don’t think you’re immune to this particular sort of unhelpful intervention. Often, the more we want others to succeed, the harder it is to step back and let them fail and learn.

Have Ample Time to Debrief

One more tip about debriefing, a short but important one: make sure you plan for ample time for the invention phase. Because we are always pressed for time (the more interesting stuff we have to teach, the more we try to cram in) we always run the risk of short-changing the debriefing. Also, because you as a trainer have already mastered much of the material you are trying to teach, there is always the subtle suspicion that it might be more effective to “just tell them the answer”. There is often an unconscious collusion here between learner and teacher, because most of us have gone through years and years of schooling where the message behind the message was that “the teacher has the answer, and you’re supposed to memorize it”. We need to remember that we all have a part of us that harbors a desire to just be told what to do.

Add Some Helpful Theory

Experiential training does not mean that participants are invited to make up any kind of insights. As a teacher, you have an agenda, some topics and models that you want to convey. You design exercises and debriefings that will help participants internalize these concepts, and often other insights (sometimes very personal realizations). This does not mean that your expertise in the field is not wanted. It fits well into this model of learning. Here’s how you fit it in.

Once participants have gone through an experience and you start debriefing it with them, this opens an interesting door for you to provide some additional theory, concepts, models, and such. Your primary task is to help participants construct new insights from what just happened. However, you can help them in this task by providing support. That support might come in the form of useful theoretical models that help learners make sense of what just happened. You do it with a light touch, however,

At this point, what you add fits right in, because if the experience people just went through has left participants with some ”hooks” to hang the new information you provide on. It has also most likely caused some new burning questions to appear, which you can now help answer. This means that the learning is connected to real experiences and true needs. Learning that satisfies a true and current need is very powerful. It is real in a completely different way; it’s not just adding new information – it’s helping you to make sense of the world around you.

Get Help With Your Congruence

I find it very important for us teachers to reflect regularly on to which extent the way we teach is congruent with what we are teaching. Why? Because if we say one thing and do another, the whole thing falls apart.

For example, if you are teaching the concept of self organization – are you conscious of when you do things that might actually impede self organization in the class? I once arrived late to a conference session on the topic of retrospectives. The presenter was a well known consultant in the agile community. As we entered the room he said something slightly demeaning about how arriving late was a sign of not caring, or something to that effect. He then proceeded to open his presentation about retrospectives by talking about the importance of creating a psychologically safe environment.

The only thing I remember from that session was the glaring mismatch between his actual behavior and his topic of choice. Try not to be that person: remember that your actions speak louder than your words.

A challenge for me (and, I guess, for you) is that it’s quite hard to spot these things in ourselves. We are stuck in our heads looking out at everyone end everything else. Everything can look quite OK from that vantage point, according to the same brain who just made you commit some obvious mistakes. We need a mirror to see better. So, ask someone you trust to spot you in class and give you feedback afterwards. For example, you could ask: “is there anything I am doing that goes against the message I am trying to teach?”


  • Experiential learning is the art of learning from experience using skilled reflection
  • Navigate the context. Help participants localize themselves in the vast space of situations and concepts that are whirling around.
  • Use just enough setup. Do: Give just enough information to avoid confusion and have enough goal clarity. Don’t: Try to explain exactly what needs to be done.
  • Debrief with powerful questions to help learners construct new insights.
  • Control your interactions. Let people have their experiences on their own. Step in to help make sense of what happened, but don’t do all the work for them. Step back and let people find the connection to their personal needs and situations.
  • Have ample time to debrief. Rule of thumb: use as much time to debrief as you used for the exercise itself.
  • Add some helpful theory when participants are ready to receive it. Before that, help them construct as much of the insights as possible themselves.
  • Get help with your congruence. Ask a trusted friend or colleague to spot you and explicitly tell them what kind of feedback you are looking for.

Learn More

Efficiency Is Not the Only Value

Not too long ago I was teaching a class at a client company. During the morning of the second day of the class, I had reserved a block of time for diving into some of their specific challenges. I usually do this, because while I have an agenda I’m supposed to cover, I know that one of the most important parts of learning new things is discussing how to apply the new knowledge and skills in your own unique context.

To kick off the discussion I asked everyone to write one or two sticky notes with the questions or topics of greatest interest to them. Once the time was up everyone got to take turns presenting their selected topics. Something interesting happened as this was going on.

During the posting of topics, one of the managers approached me and asked if we ”hadn’t already done this”. I asked him what he mean. He explained that as he signed up for the class, he had already been asked to provide some information about which topics were of most interest to him.

For some reason his question annoyed me. This was surprising to me because I seldom get annoyed with participants in my classes. I explained to him that I thought the activity would be time well spent. He clearly wasn’t satisfied with my answer, so I asked him a very direct question. I said: “Tell me what your real question is”. As that request came out, I could hear how threatening it might have sounded. He wasn’t fazed however and so could explain his thinking to me.

The manager’s answer shed some light on his concern – and simultaneously on my irritation: he thought that I was being very inefficient by asking participants to provide the same information twice. He thought I should have been able to use the information from the class signup as the basis for the discussion, rather than generating it all over again.

As I reflected upon this after the class, I realized why his question annoyed me. It annoyed me because his question (regardless of his intent) seemed to me to come from a completely different world view than my own. It annoyed me because it reminded me of some of the previous attempts of managers I’ve worked with to make things more efficient, and how I saw those attempts as a lack of respect for my leadership skill. Of course, none of these thoughts came to me in the moment all this happened. Then, I was just annoyed.

I was annoyed that this manager seemed to believe that he could improve on my class by making it more efficient. My focus is always on making a class effective (reach the intended learning outcomes) even if that means it can sometimes be a bit inefficient (some rework, for example).

You might wonder why an attempt at making things more efficienty would be so annoying? Isn’t efficiency important? Well, the topic of the class was the agile product owner. The major part of being successful in that role comes from the insight that it’s more important to be effective (develop the right things), than to be efficient (develop things in the most optimized way). At least if you want your product to sell and actually provide value when used.

Efficiency is a deeply held value in many organizations. That annoys me, because a lot of the time the focus on efficiency seems to cause more problems than it solves.

There are many other values we can choose to focus on, besides efficiency, if we can manage to stop worrying about being so darn efficient all the time (gasp!). Here are some other values that I suspect will bring you more benefit, should you choose to make them come to life in your organization:

  • Be effective – do what counts (in the class, for example, we collaboratively chose the topics of most value to the group as a whole)
  • Value learning (in this case, participants got a chance to reframe their key question based on what they had learned during the first day of class)
  • Value invitation and participation (by asking everyone to participate, I got input from all participants, even those who didn’t provide any when signing up)
  • Experiment (by trying new ways of doing this exercise almost every time I do it, I’ve come to learn many things about how I can make it work well)

With all this said, I do love being efficient. It’s just that I can’t fool myself: some of the time when I’m being efficient, I’m just really good at doing the wrong thing. Efficiency brings me joy, and that’s important. But: it doesn’t necessarily bring others value. Might the same thing be said for the work you do?

Managing as Helping

Are you a manager, or maybe an informal leader with implicit influence and responsibility? Have you considered how you think about your role? Have you considered thinking about yourself as a helper?

If you’re reading this, chances are you’re working in a knowledge-based organization: an enterprise that builds its success on being able to convert human motivation into creative ideas, and then use the best of those ideas to develop useful products and services.

Knowledge-based organizations are hard to manage, because people are hard to manage. Highly educated and creative people might be especially hard to manage, because they have high expectations when it comes to being managed in the right way.

How you see the role of management is going to be a major factor in deciding whether you end up managing in a way that’s helpful to people in your organization or not.

If there’s one thing the modern organization does not have room for, it’s unhelpful people. We may have room for freeloaders (you’ve been one too, at times in your life), assholes (you’ve been there too, especially if you think you’ve never been seen as one), and incompetents (in some things you should be incompetent, otherwise you’re just cruising).

However, I don’t think we have room for unhelpful people. Success as an organizations comes from creating a web of interactions – also known as helping each other. Here are some telltale signs that might indicate that you are currently not as helpful as you could be:

  • When somebody asks for help, you don’t help them. Well. That one’s pretty obvious I guess. Just remember that’s its easy to fool yourself. You may be presenting yourself with solid reasons why not helping is the right thing to do. Look closely at those reasons, and remember that there is more than one way to help. To begin with, helping does not necessarily mean taking on a task someone else should rightfully do – nor does it mean giving direct answers. Which takes us to point number two:
  • You give help by taking over the task completely, thereby robbing your colleague from the opportunity to learn to do the task. In knowledge organizations, eliminating learning is a cardinal sin. Therefore, this kind of helping isn’t very helpful.
  • You consider some tasks to be beneath you. Maybe you think that you no longer have to visit the development teams. After all, you paid your dues long ago, and now you have team leads or scrum masters or agile coaches or whatever working with the teams. They’re doing the floor work and report to you every now and then. But how can you possibly claim to manage work that you are so separated from? Don’t be afraid to go out there. Look at what’s really happening and learn, learn, learn. Then provide help.
  • You listen to people’s requests for help, then say: “I’m sure you can figure out a way to solve it”. Of course they can – but they came to you asking for help. Asking for help is not an easy thing to do. It puts you in a vulnerable position (which is why those who most need help may be least likely to ask for it). When somebody comes to you and asks for your help, you should see that as a sign of trust being extended. This is the moment when you can truly make a difference. Don’t throw that away.
  • You inflict help where help is not asked for. That’s not helpful, and will lead to resentment. You can’t help someone who does not want to be helped. I remember discussing this perspective on helping with a group that included a social worker. She was offended by the suggestion that help must be wanted. In her line of work, she said, help often had to forced upon people who aren’t asking for it, like addicts for example. In the end, someone asked her if she had ever had long-term success in helping an addict that didn’t want to go clean. She looked sad, sighed, and said no.
  • You don’t ask for help. As a manager or informal leader, your behavior sets the tone. You are a role model. If you are not able to ask for help when you really need it, why do you think others should have that ability? But wait, you might be thinking, what if I simply don’t need help? If you think that, then you’re beyond what I can help you with through a text like this. All I can say is this: what on Earth makes you think you don’t need help?

If you want to learn more about managing as helping, my recommendation is that you buy and study Ed Schein’s book “Helping”. It’s written in very plain and understandable language. Don’t be fooled into thinking that makes the topic easy. Helping is really hard work – but it’s also very rewarding.

The Worst Daily Scrum Ever

I once observed what was probably the worst daily scrum ever. Just when I thought it was over, something interesting happened.

I once observed what was probably the worst daily scrum ever. Just when I thought it was over, something interesting happened.

Visiting a team in an organization I worked with, I got to see one particular scrum master run a daily scrum – into the ground. This is the story of how he did that – but it’s also the story of how the team miraculously survived this train crash of a meeting.

Every morning, the team would gather around a large whiteboard, where the scope for the sprint and the relevant tasks were posted in the form of a bunch of sticky notes. The meeting would not begin until the scrum master, literally, pointed at a person, and asked:

– “What have you been doing since yesterday?” Upon hearing this, the indicated person would give a very brief account about what tasks had been worked on.

Then, the scrum master proceeded by asking:

– “What will you be doing today?” Again, a short answer, which seemed mostly directed at satisfying the need to say something in response to this direct question.

The third question asked by the scrum master was:

– “Do you have any impediments?” I noticed that the answer to this was always no, for all members of the team. I knew this answer couldn’t be true, because this was a team that struggled mightily every single day.

When I thought it couldn’t possibly become any worse, the scrum master fired off one last and revealing question:

– “Do you have any hours to reduce”

At first, I was surprised by this very direct way of trying to make the burndown point downwards, but it dawned on me that it was perfectly congruent with the scrum master’s unspoken goal: to preserve the illusion of control. The answer to this fourth question would go along these lines:

– “Hours to reduce? No, not really. But, I guess I have been working on this task a bit, so let’s see. Yesterday, the estimate of remaining time was 16 hours. I guess it’s about 14 hours left now. No, 13 and a half.” Hearing this, the scrum master nodded and smiled, and noted the change in his notebook.

Directed by the scrum master, the team continued in this fashion in a round-robin style. Whenever “some hours were reduced”, the scrum master would nod approvingly and take some notes.

I could hear no requests, and no offerings of help. No really valuable information seemed to be surfaced. Energy seemed to be at a rock bottom low.

Then something interesting happened.

The scrum master declared that the meeting was over, and turned his back to the team to work on his notes from the meeting. Because his back was now turned to the team, he never really witnessed what happened next.

With the official part of the meeting over, the team suddenly seemed to come alive. They suddenly huddled together and started a lively exchange about their plans for the day. One person would suggest a course of action, and someone else would fill in with some additional information. Someone asked a question, and others jumped in to answer it.

With the directive scrum master out of the game, the team took the reins and did what needed to be done to lay the groundwork for working together during the day. They performed an effective daily scrum. Energy was high, information flowed, and when needs had been met the meeting was over.

This real scrum went on for just a few minutes, with me watching in amazement. The scrum master never saw what happened. I know, because I asked him afterwards:

– “Did you see what happened after you ended the meeting”?
– “No.”
– “The team came together and sorted out the day.”
– “OK.”
– “Do you think you need to change the way you run the meeting?”
– “No. It works for me.”

How’s your daily scrum? Is it working for you? How about for the rest of the team?

If you liked this article, you may also like

There’s Always One [Drop|Comment|Question] Left

My childhood friend’s mother was a “dagmamma”, literally, a “daytime mother”. In other words, she took care of a bunch of other people’s kids in her own home.

She was a very kind and intelligent person. One of the things she said has stuck with me to this very day.

“There’s always one drop left.”

She would say this when we had had finished our “fika” (for kids in Sweden, this would be strawberry juice and cinnamon buns) and we would start playing with our empty glasses. Or rather: we thought the glasses were empty, but she knew better. That’s why she reminded us.

I think of this every now and then when facilitating a meeting or a workshop. Whenever you ask for comments and questions, there comes a point where the contributions start to taper off. Silence commences. This is where you as the facilitator or convenener should stay quiet, too. Because, to paraphrase the wise dagmamma:

“There’s always one comment left”

Keep quiet. Count to twenty in German *) to focus your attention on something other than the heavy silence, and lo and behold. One more reflection always pours out.


*) Silently, that is. If you experiment with counting loudly in this situation, let me know what happens. I haven’t tried it yet.