Tobias Fors

Category: Exercises

  • 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

  • Check-in in a Circle

    When I kick off a class or workshop, I want participants to engage as soon as possible after entering the room. I do work through some practical bits first, but after that I quickly hand things over to participants.

    For a long time, I’ve been using an opening exercise I learned from Ken Schwaber. In it, I ask participants to sort themselves along a line in the room, according to different criteria.

    First, I ask the group to sort itself according to how effective and efficient their current project is (in Swedish, a single word has the connotation of both “effective” and “efficient”). Once sorted, people take turns sharing their situation. Doing this, participants come to see what a wide range of different experiences are present in the room.

    After this, participants get to sort themselves again, this time according to the level of energy they perceive in that same project. Really low energy in one end, and high in the other. We talk about it again.

    Finally, we do the same thing, this time based on how much experience and knowledge of Scrum the participants feel they have.

    Earlier this summer, I participated in a terrific one-week workshop with organizational development pioneers Charles and Edie Seashore. The name of the workshop was “Intentional Use of Self”.

    In one part of the workshop, we talked about how check-ins are an important part of helping a workshop group come together. We also did check-ins every morning. One format we used was based on a fishbowl. Charles and Edie would ask one small part of the group to step into the middle, and tell each other about some thing.

    Today, I decided to try this format out. I asked people in the class to step into the fishbowl based on how long they had been using Scrum.

    First, I asked those with no experience to step in and talk to each other about their current situation and their expectations for the course. After that, those with a few months of experience got to share. Then those with up to a couple of years experience.

    Finally, those of us with longer experience (I joined the fishbowl myself here) stepped into the inner circle a told each other about our experiences and expectations.

    Here’s what I like about Charles’ and Edie’s check-in:

    • Participants face each other, not just me
    • In a circle, it’s easier to speak up
    • When you do speak, you speak with a smaller group
    • Everyone else can still hear you
    • The fishbowl circle puts more emphasis on the likenesses we share, whereas the line creates an exposed situation for those on the ends of a line.
    • We still get to see the different experiences available in the group

    It’s a simple but powerful check-in format. I’m fascinated by the fact that I had to travel half-way around the world to pick it up. I’m glad I did.

    Do you facilitate workshops or teach classes? Do you use check-ins? What kinds of check-ins have you tried so far?

  • An Exercise for Defining Done for Scrum Teams

    In this post, I’m going to share an exercise you could try for helping a team start their journey towards a clear and shared definition of what it means to done with a feature in a software product. I’m looking at this from the perspective of agile development with Scrum, but my guess is you can use this even if you’re not using Scrum. I’ve taken a core exercise I’ve used many times to help teams form a first definition of done, and combined it with some debriefing practices I’ve learned over the years. If you want to use this exercise, go ahead. If you run it a couple of times, you’ll be able to improve on it: then I’d love to learn about how you improved it.

    Scrum has taken some flak because many perceive the model as lacking a clear focus on solid development practices such as automated unit testing, refactoring and code or design quality in general.

    It’s true that Scrum does not supply us with a detailed definition of exactly how software should be developed. What we get instead are some general admonitions. From these, we need to create our own set of practices that are suitable in our specific context. Here are the general rules that Scrum gives us:

    • Every sprint should end with a done product increment
    • Done means having something potentially deployable, something of business value
    • Potentially deployable implies a well designed and well tested solution, documented with user manuals if those are needed for the product to be usable

    As a quick sidenote, let’s explore why we like to say “potentially deployable”, rather than “deployable”. Adding that extra word – potentially – gives us a useful, albeit sometimes risky, window of flexibility. What it means in practice is that, if by the end of the sprint we realize that we could gain from deploying, we should be able to do that deployment with just a little extra work. In an ideal world, we would be able to deploy directly – and some companies can do this. However, a company just starting out with Scrum probably cannot do this. They need to improve the way they develop software until they can be “more done” every Sprint, thus acquiring the ability to capture potential business opportunities by deploying early and frequently. The risky part: some will be satisfied with building “good enough” product increments, forgetting that in the long run, insufficient quality very easily turns into terrible quality.

    How does a team move from Scrum’s general definition of done to a detailed description of what done means for them? The team can get there over time, by inspecting and adapting every sprint. If for example, we notice that planning meetings take too long and are fraught with hostile discussions, we might want to explore if we really agree on what it means to be done with something.  If you and I are in the same team, and your definition of done is “if it compiles, ship it” and my definition happens to be “refactored, well designed and thoroughly tested”, we’re bound to have frustration and misunderstandings. If this is the case, a clear and shared definition of done will be very helpful.

    Let me describe an exercise I often use in my classes and workshops. It builds on several ideas to help a team get going with their work on defining what done means to them. The ideas I’ve built the exercise upon include these:

    • When asked if we agree on something, we sometimes say yes just to avoid exposing a conflict, so we need to find a way to safely expose disagreements that prevent us from working well together
    • Agreeing on a definition of something is often hard work, so we could use some help to get going and to avoid some common pitfalls
    • Simply stating that you agree is not as powerful as when you actively participate in the discussion, so we can use a setup that entices as many as possible to step in and actively participate

    Over the years, I’ve tried some different approaches to this. Let me give you a step by step description of the exercise the way I myself will do it the next time I use it. I think it will work well, because the core of it is about really activating participants and in getting the discussion going in an effective and safe way.

    Preparation

    1. On a set of regular size pages, type out a list of items that might be included in a team’s definition of done, such as: “Code is refactored”, “Automated unit tests written”, and so on. Take care to express things clearly. I have a set of four or five pages with things. Some of them are quite uncontroversial (“Code written”), some are things that typically need to be discussed and refined (“Full performance test run”).
    2. Format the pages so that each thing stands on its own line, a couple of centimeters (an inch) high, with large type. Add horizontal separators between each line, so that the sheets can easily be cut into slips.
    3. Add an extra page with blank lines that the team can fill in themselves
    4. Print these pages and bring them – and a couple of scissors – to the workshop.

    The Exercise

    1. Invite the team and set the room up so that everyone can work together comfortably around a large table.
    2. Explain that you are about to engage in an interactive exercise together, and that the purpose of it is to see if we can find a shared definition of what being done with a product increment means to this specific team in this specific project. If the team is new to Scrum, a mini-lecture about how defining done fits into Scrum’s iterative and incremental way of working will also help here.
    3. Hand out the sheets you prepared, and ask the team to cut them up into strips with the scissors you supplied. I prefer letting the team do this work, because doing something physical is an nice way for the them to slowly “warm up” for the hard parts of the
    4. Explain that the blank slips can be used to add missing items, if needed.
    5. While the team is doing the cutting, prepare a flip chart on the wall. On this flip chart, draw a vertical line down the middle, so that you get two columns of equal width. Over the left column, write the heading “Every sprint”. Over the right column, write “Before release”.
    6. Wait for the team to end their cutting, then ask for their attention. Explain the flip chart. Tell the team that you want them to take this flip chart and put it on their table. Say that you want them to sort their strips into the two columns. In the “Every sprint” column, they are to put every item that they agree should be performed by the team during each and every sprint. In the other column, “Before release”, they are to put items that they think are important, but that for some reason cannot be done in every sprint, but that definitely must be done before the product can be shipped out. There is typically no need to go into why something might end up in the “Before release” column, but if the question comes up, briefly explain that for technical or economical reasons, it can sometimes be hard to fit some things into the sprint, and that this may or may not be true for the current team.Defining done

    7. Explain that what comes next is very important. Once you have the full attention of the group, reveal that they will do the sorting under complete silence. This is usually quite surprising. Tell the group that they are to work in silence, until it is absolutely impossible to keep working silently. When this happens, but not before, they can start talking to each other.
    8. You also need to explain how the participants should handle differences of opinion during this part of the exercise. Explain that all participants have the right to place any slip in the place they think it should be. If anyone sees a slip that is in the wrong column, they can just move it to the right column. If you see someone moving a slip you just placed, just move it back again. You’ll notice if some slip keeps moving back and forth a number of times. If that happens, just place it on top of the line separating the columns, and keep working on some other slip. Don’t start talking when this happens, just keep going. When everything has settled down and you can no longer work in quiet, that’s when you can start talking about how to handle those hard to place pieces.
    9. Sit back and watch the team get to work. It’s quite fun. Take this time to practice your skills of observation – look at expressions, gestures, movements and think about what they might mean. If someone starts talking too early, gently remind them to work in silence for just a few minutes more, until most pieces have fallen into place.
    10. After some time, the team will notice it can get no further unless they start talking to each other. When this happens, most uncontroversial pieces have typically found their place, even though you can be sure there’s still no agreement. Depending on the team, you might need to facilitate this lightly. One way to do that is to ask some questions, like “I notice you’ve placed this slip here (point to a slip) – how did you decide on that?” Some teams naturally take to discussing, others need more help to get started.
    11. Let the team take its time working on the sorting. Remind them that we’re searching for a shared and usable definition of done, something that they could potentially use in their current project right away.

    The Debrief

    1. With the slips sorted into columns, hand out some tape and ask the team to fasten the slips to the flip chart they’ve been working on, then to post the whole thing on the wall.
    2. Ask the team: “You’ve created your first definition of what it means to be done with a product increment in a sprint. What are your thoughts now?”
    3. Write down the reflections that come up, exactly as they come up, on an empty flip chart.
    4. Next, write the heading “Suggestions” on a blank flip chart, then ask the team: “What are your suggestions on what you as a team should do next?”. Clearly explain that we’re currently only after ideas, that we’re not deciding anything yet.
    5. Help the team do a silent brainstorming to identify as many suggestions as possible . My experience is that a silent brainstorming results in more and more-varied ideas. To do this, just hand out sticky notes and ask participants to write one suggestion per sticky note. Set a time for this, perhaps five minutes, or maybe ten. I usually go with five, then ask if more time is needed when those five minutes are up. When the time is up, let those still writing finish their notes, then ask participants to take turns posting and reading their suggestions.
    6. With all suggestions up on the wall: do a quick dot voting to gauge the group’s thoughts about the suggestions. Ask each participant to place exactly five voting dots on the suggestions he or she thinks has the greatest potential in helping the team perform better. Explain that they can place the dots any way they want, all on one suggestion or distributed over several sticky notes. Explain that this still does not mean we’re deciding anything – we’re just trying to get a feel for the group’s overall interest in the suggestions.
    7. When the suggestions have all been posted, write the heading “Next steps” on a fresh flip chart and tell the group that the time has come to see if they can decide on some next steps to take. Ask the group: “Can you agree on some next step?”. Someone typically shouts out one of the previously posted suggestions, or something that is a synthesis or rewording of one of those suggestions. Help the group formulate the next step as a clearly stated action. Ask the group if they agree that doing this action is desirable. Use thumb voting if needed: thumb sup means agree, down means don’t agree, sideways means “I don’t care, so I’ll go with what the majority decides on”. If someone shows a thumbs down, work with them to modify the suggestion or create a new one, until agreement is reached. If no thumbs are pointing down, the group has decided.
    8. Ask for more next steps, until you have enough to see that the team will take some clear next steps to keep moving with the work they’ve just done on defining done. If everything goes well, the team will suggest activities that relate to incorporating the new definition of done into the daily work. If things go less well, they might not – but this is also information, and you should be glad that it comes up now and not later, when you’ve tried to build a product without first agreeing on how to work together. Don’t be surprised if the team comes up with really inventive and ambitious ideas, and choose to act on them – my experience is that this happens more or less every time I work this way with a team.

    The first definition of done agreed upon by a team in an exercise like this will not be the final one. Whatever you do, don’t print out and laminate this definition. As a team learns more, builds more capacity, and learns to work better together, they might realize that they can improve their definition of done. A team using Scrum then implements these improvements, and it does this in a way that ensures that the whole team is in on the changes.

    A word of caution. You might think this whole exercise seems like a waste of time. After all, how hard is it to create a solid definition of done and just hand it to the team? In fact, if you’ve been in the software business for a few years, that’s not hard at all. However, creating that list does not mean that the team will use it. Defining done is more about finding consensus than it is about listing an optimal set of practices. I’ll take a less impressive but widely shared definition of done over an ideal but ignored list any day. If we know where we stand, we can always improve from there.