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?”

Summary

  • 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

Experiential Learning (No More “Silentium”)

15h Century Classroom - teacher, students, and wall inscription reading silentium, or silence.

Over the last five years, I’ve taught lots of classes to lots of people. If I knew it before, I’m convinced of it now: lecturing is not the most effective way to help others truly learn.

The problem with lecturing is that it doesn’t really do much to change someone’s behavior, at least not in a lasting way. So what? Well, I believe learning is more than just collecting new pieces of information. Learning also means enabling new behaviors.

One thing is for certain: lecturing is satisfying, at least for a while. It makes me feel smart, and many of my student’s love it, because they get to lean back and enjoy the ride without expending too much energy on their own, until they finally fall asleep, or worse, just tune out. A great lecturer can stay interesting for longer, of course, but I’m afraid most people leave even a great lecture only to go back to doing whatever they did before.

Lecturing isn’t all bad – it’s just that too many expect too much from it.

Sometimes I get sucked into lecturing mode, even though I don’t want to. Maybe it’s an effect of my academic schooling.

I remember one of my university teachers well. In the first lecture of his course, he displayed a cartoon of a poor fellow in a chair. Attached to the fellow’s mouth: a hose. The other end of the hose was attached to a faucet, labeled “Knowledge”. My teacher proceeded to explain the picture.

– “I’ve recently been to a pedagogy course. They taught us not to try and stuff knowledge into our students in the same way you fill a sausage. I definitely agree”, he continued, “but then again, this is an advanced level class”. With that, he started lecturing.

The first few weeks of the course were indeed stuffy. We were expected to mechanically fill out answers to five hundred questions presented in a booklet given to us. Before you’ve done this, the teacher explained, you’re not really ready to enter into meaningful discussions on the topic.

Once the first part of the course was over, the style of teaching changed dramatically. Group work and seminars were substituted for lectures and answer hunting. I liked the second part better, but the first part was useful too.

I suspect fewer would pay to come to my classes if I required them to answer hundreds of questions beforehand. In just a couple of days, I want to help the participants in my classes discover new and more effective behaviors. How do I do that, if lecturing delivers such weak results?

My chosen path has been to learn about experiential learning. In experiential learning, the idea is to create a situation where students can construct new knowledge on their own. As a teacher, my work is to design the right environment for learning to occur, and to help the students make sense of what they discover.

I’ve always designed my courses to be very interactive, but there’s one key thing I’ve learned as I’ve started to study experiential training: debriefing is key. While experiential training builds extensively on exercises and simulations, the real learning seems to happen during the debrief. This is when the group works together to reflect on what just happened, and to build up their new knowledge. Debriefing often takes as much time as the exercises themselves.

Experiential training is not always welcome. It can happen that participants who did not quite know what they were getting themselves into are unpleasantly surprised by the format, which is the complete opposite of the archetypal classroom situation, where the all-knowing teacher is at the front of a silent crowd, lecturing from his book of clear cut answers.

For some, this format is different enough to create an uncomfortable confusion. For others, the amount of insights and emotions turn out to be an overwhelming surprise. For many, it leads to lots of learning. Whichever the case, it is my responsibility to make sure participants know what will happen, and that participation always is optional.

When was the last time you really learned something new – something that changed you? What conditions made that learning happen?

PS. If you want to experience experiential learning in a workshop setting, try to get a (highly coveted) place in one of Jerry Weinberg’s, Esther Derby’s and Johanna Rothman’s “Problem Solving Leadership” workshops. If you’re interested in this topic, you will learn as much about this style of teaching as you will about yourself during one intensive week.

Ken Robinson on Changing Education Paradigms

My friend from the AYE conference, John, just reminded me about the clip below. It has an important message, but there’s another reason to watch it too: the presentation is stunning.

In the clip, Ken Robinson argues that our schools are using methods designed for a different age. Those methods are no longer helpful. We live in different times.

If you want to learn more about the history of our schooling system, and how it could evolve, I recommend Russell Ackoff’s “Turning Learning Right Side Up”.

The Power of Completion: Great vs Excellent Teachers

When I practiced aikido, I was struck by the difference between good and excellent teachers. The good teacher would be more than willing to correct me when I did something wrong. Too willing, in fact. So eager were they to instruct me that they would interrupt me mid-motion to show me how to improve. The excellent teachers never did this. They would always let me complete a full technique, only stopping me when it was all done to explain, very briefly, one small thing I could do differently.

The difference was profound. I became annoyed at the instructors who interrupted me. I felt I couldn’t really learn anything when being interrupted all the time. With the good instructors, I would often find out myself what I was doing wrong, and correct myself before they could. I don’t know about you, but I find that things I discover myself stick a whole lot better than things I’m told by others.

What was going on here? I believe that being allowed to complete a full technique, even if that meant doing it less well, made it possible for me to judge the results by myself. The good instructors could spot I wasn’t going to get a great result just from watching my early movement, and stopped me. The great instructors saw this too, but understood that only by discovering this myself would I truly learn.

Systems thinkers will recognize this problem: it is a problem of working on the parts versus working on the whole. The good instructors thought that improving the parts separately could work. The excellent instructors knew that focus needed to be first on the whole, second on the parts.

What kind of teacher are you? What do you do to ensure that you give your students a chance to learn by themselves?

Use Improvement Stories to Make Your Retrospectives More Effective

<plug>I teach a one-day class on retrospectives. It’s in Swedish only for now, but if that’s not an obstacle, you should read about it on the Citerus web site.</plug>

I love to use the user story format when I help teams plan their work. It can sometimes be hard to break user stories down into useable chunks, but their format is very easy to use: As a <type of user>, I want to <do what with the product>, so that <this value will come about>. There are different ways to format stories, but the essence remains the same. Use a simple format to quickly shake out some key information about a given requirement.

Maybe you’ve noticed that it’s not just during planning that we have hard time putting our thoughts and desires into words. Teams that do retrospectives frequently find that it can be very hard to get valuable output from these meetings. One cause of this, which is easy to remedy, is the use of inexact language.

If you’ve brainstormed improvement suggestions with your team, you might have seen a suggestion like this (written on a post-it note): “Better test”. Or maybe even terser: “Cooperation”.

These notes are a good start, because there’s an interesting story behind them. The problem is that we might have to spend considerable time pulling that story out. There is a simpler way to get there.

Nowadays, I use the story format not only in planning meetings, but also in retrospectives. Whenever I ask a team to brainstorm improvement suggestions, I ask them to do it using a template I supply. I ask them to write Improvement Stories.

An improvement story is quite easy to write, and looks like this:

Because <description of problem or situation>

we should <description of suggestion>

so that <description of desired result>.

I find that asking teams to supply their suggestions in this format results in contributions that are well considered, easy to understand and quick to process.

Have you tried using improvement stories? Drop me a note in the comments section!

Ackoff’s 95% (Cannot manage them the same way)

I’m currently cleaning up my trusty old Mac Mini G4. I’ve been cleaning out old stuff I don’t need to save, and a few days ago I installed a cheap 1 gig of memory. That upgrade did not make the machine notably faster. Today, however, I ran a bunch of maintenance tools, which seemed to do the trick. There’s a noticeable improvement in the speed of the little things, like how long it takes to fold out a menu. There was a delay before, and now it seems to be gone. Hope it lasts.

Energized by my success in speeding up the old can, I started another round of file cleaning. I found an old NeoOffice file called “Russ Ackoff – 95 Percent”. Because NeoOffice has always been extremely slow on this old machine, I wanted to see how fast I could open it. That, and the fact that I’m always interested in Ackoff’s teachings.

NeoOffice turned out to be as slow as before, but the file contained pure gold. Not new gold, but pure gold. In it was a little piece of knowledge that I’ve been using in my scrum master classes for a few years, ever since I came across it on the web.

Here are the contents of the file, which I remember transcribing from a sound file as I listened to it:

“http://www.open2.net/systems/practice/rus12.html

1900 – 95% of the people in the US could not do the job as well as their bosses could.

If the foreman retires from a group, you pick the best man to become the new foreman.

He can thus do the job better than any of his subordinates.

He will continue to rise as long as he is the best in the group.

All managers thus rise to the level of their own incompetence.

Today, 95% of the people can do their job better than their bosses.

You cannot manage them the same way.

Don’t manage what they do – manage the way they interact.

Requires different organization, and a different type of management.”

Centralized Services in Software Development

Reading a blog post by Tripp Babbitt reminded me of Ackoffs discussion on internal market economies in Re-Creating the Corporation.

Babbitt’s blog post talks about how focusing on cost reductions often increases costs. One reason is that cost reductions are often approached by centralizing services in organizations. When this happens, a feedback loop is broken. Those who produce the services are no longer those who consume them. This means that they loose their understanding of how well the services work. When the consumer of the service sees the service degrade, they cannot easily improve the service, because they don’t control the production of it. Instead, the consumers work with what they can control, which sometimes means reproducing the service locally, thus increasing total costs.

How can we use this insight to improve software development?

In software development, we sometimes see this phenomenon with centralized platform teams. A platform team is formed to develop shared functionality, to be used by teams that develop actual product features. In reality however, platform teams often have a hard time living up to the expectations of the feature teams. Because of this, feature teams sometimes choose to locally develop functionality that was supposed to go in the shared platform.

Another example that comes to mind is when organizations set up project management offices, and these offices proceed by pushing out standardized methods of work, instead of listening to the needs of the different areas of the corporation. Again, the idea here is to save money by standardizing, but the result is often frustration, because there is no such thing as a one-size-fits-all way to manage projects.

One final example: the central database administration group. Created to gain control over database services, it soon becomes the bottleneck more than anything else, stopping projects dead in their tracks.

In Ackoff’s solution, departments within organizations should be free to procure the services they need from internal services and from anyone on the open market. If top management wants to override a department’s decision to procure externally they can do so, but will have to use their own budget to compensate for the losses the buying department suffers through this decision.

In other words, if a sales department is forced to procure their new IT support system from the internal IT department, even though they could have gotten the same solution for a cheaper price from an external provider, the overriding manager will have to compensate the sales department for the difference in cost.

Well, this is really a bit outside of my area of expertise, but interesting nonetheless. My learning goes on.

What are your experiences of centralized services? Good? Bad? Why?

8 Steps to Getting Feedback

Forget everything you know about agile, about any methods, about any kind of tool you’ve mastered. If there’s only one thing you should do, it has to be this: ask for feedback.

It doesn’t matter what you do or how you do it. If you don’t stop and ask the people you work with for feedback, you’ll never know exactly how bad you did until its too late.

It’s not complicated to get feedback, but it can be hard on you. Here is one way to do it.

First of all, you find a person who can provide you with some feedback. It helps if this is a person you trust. To this person, you present your desire for learning about how you’re doing, and ask if that person is willing to give you some feedback. If the answer is yes, you make sure you sit down in a comfortable environment where you both feel safe and relaxed. Then you ask for feedback on how you’re doing with something.

You could word it like this: “How do you think I’m doing when it comes to the TPS reports?” Then you sit silent and wait. And wait. You will always get feedback, even if the person you’re asking says nothing at all.

When you get the feedback, you might be tempted to think that you’re both done. You’re not. You might be tempted to blurt out a defense, because what you’ve just been told seems so offensive. Don’t. Instead, when you’ve heard what the other person thinks, stay silent. Think. Think about what that feedback might mean. Quietly formulate your interpretation of what that feedback really means, then tell it to the other person and ask if your interpretation is correct. Then go quiet again.

Either the person will say that your interpretation is correct, in which case you can say you’ve received the feedback. Or the other person will correct your interpretation. If this happens, you listen and think some more. Then you present your interpretation of the feedback again, this time incorporating the corrections you just received. Then you listen again, and repeat the process until your feedback giver tells you that you’ve understood things correctly.

Note that even complete silence can be treated this way. Silence as a response to a direct question is a kind of feedback, which you can try to interpret. If you do, it becomes doubly important to check your interpretation with the other person, because it now comes solely from within your own head.

If this procedure seems cumbersome, that’s only because it is. It’s not as slow as it seems when its broken down like this, however. Communicating clearly is hard work. We almost always go wrong in some way when we try to communicate with someone else, and it’s often due to the fact that we think we’ve understood the other person, when in reality we haven’t.

Do I always do it like this? No, and neither will you. In fact, if you’re like me, you’ll do like this far too seldom. Sometimes, we simply lack the energy to go through all the work that’s needed to communicate well. For me, that means I’m least likely to get good feedback when I most need it. It’s at times like those that I get into trouble, and that’s why I have to keep reminding myself that feedback can be scary, but that’s just because I don’t ask for it often enough.

To summarize:

  1. Find a potential feedback giver
  2. Ask for help
  3. Find a suitable environment
  4. Ask: How am I doing [with regard to something specific]?
  5. Listen.
  6. Think.
  7. Present your interpretation of the feedback.
  8. Repeat 5-7 until you get to hear you’ve understood correctly.
Will you give me some feedback? Was this post helpful to you?

Learning From Mistakes

Whenever something unexpected happens – such as when we make a mistake –  there’s a possibility for learning to happen. For example, I just tried to add an extra branch in my mind mapping tool, but I pressed the wrong key combination. Instead of a new branch, a nice little yellow callout appeared. I immediately liked it, because it seemed like a useful thing.

What mistakes have you done recently, and what did you learn from them?