Experiential Learning: What Does it Have to Do with Agile?

Software Development Magazine - Project Management, Programming, Software Testing

Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban

Experiential Learning: What Does it Have to Do with Agile?

Karen Greaves and Sam Laing, www.growingagile.co.za

Do you remember learning to ride a bike or drive a car? You didn’t learn how to do it by reading a book, or attending a lecture did you? I am also sure you didn’t get it right the first time you tried. You learned by trying it out, again and again, and slowly improving until you got to the point where you didn’t even need to think about it anymore, it just happened.

This model of learning is called experiential learning. Essentially it means we experience something as a way of learning about it. It’s very effective, yet in school we are programmed to learn by listening to the teacher. Unfortunately this lecture based learning style is still very prevalent today.

We use experiential learning as a key component of agile training. We find it far more effective than traditional lecture based learning. Agile is about learning how to do something rather than just passing a test. As a result, having an opportunity to fail and try again in the safety of a simulation using LEGO instead of business critical software can help teams grasp agile concepts much more quickly. It also makes them much more likely to remember the learnings once they encounter similar issues in the work place. In this article we will look at what experiential learning is, why it works, and how it is helpful for agile training.

So what is experiential learning and why does it work?

As it suggests in the name "experiential learning is the process of making meaning from direct experience"; or "to discover and experiment with knowledge firsthand, instead of hearing or reading about others' experiences". [1]

Agile Experiential Learning
Image source: http://growingagile.co.za/blog/

According to David Kolb [2], an educational theorist, in order to gain genuine knowledge from an experience, certain abilities are required:

The learner must be willing to be actively involved in the experience;
The learner must be able to reflect on the experience;
The learner must possess and use analytical skills to conceptualize the experience; and
The learner must possess decision-making and problem solving skills in order to use the new ideas gained from the experience.

We find experiential learning maps well to "Training from the BACK of the room". A training method developed by Sharon Bowman [3] based on how the brain works.

Sharon Bowman emphasizes some key points for helping people to learn.

People learn in different ways and therefore it is useful to include a range of activities like moving, reading, writing, listening, drawing and talking into any training.
Our reticular activating system keeps us sane by tuning out lots of stimulus. To make sure we aren’t tuning out training, the training needs to change every 10 to 15 minutes.
We need repetition to remember things. Sharon’s advice is 6 times in 6 ways to remember something.
People don’t learn when they are afraid, so it is important to create a safe environment in training to allow people the best opportunity to learn.

Okay if it’s that great, why don’t more people use it?

We often look to experts to learn. In the agile community it is commonly these experts who are teaching others. However, being an expert in a field does not make you an expert trainer. Simply lecturing what you know is not training. Effective training is about understanding and application of that knowledge afterwards.

As mentioned earlier in the article, most of us were exposed to lecture based training in school and university. It is commonly what we expect when we think about training. Many people have never experienced something other than training by PowerPoint.

How have we used this?

We use "Training from the BACK of the room" as a training style to incorporate experiential learning. There are some simulations or games we use regularly in training agile teams. Without fail we find that the insights people share when debriefing these games are far more powerful that any lecturing points we could teach. People often refer back to the game, when trying to explain why they should do something differently at work, a sign that the experience of the learning worked.

Let’s look at some examples

Scrum Lego Simulation

When training teams in Scrum we use a LEGO simulation [4] where teams have to build a LEGO Zoo in two 10-minute sprints. The most common lessons teams learn through the simulation are:

The value of working on one thing at a time
How tasks don’t need to be assigned to individuals up front, it can emerge during the work
The importance of having a shared understanding during planning
The value of communicating regularly with your Product Owner and stakeholders

Teaching these points in a classroom, don’t work half as well. Although people might understand the theory they do not have physical experience of how working in this way is better. In a relatively simple simulation, people try one way, fail, try an alternate way and succeed. This is a much better method for reinforcing behaviour than telling people why they should change.

The Airplane Game

A favourite game of mine is the Airplane Game [5]. This is a powerful game because it physically shows something that is counter-intuitive. In this game, which looks at limiting work in progress as a way to speed up cycle time, people realise for themselves that being busy is not the same as being effective.

One of the reasons this game is so effective is that people build physical paper airplanes. Often in the world of software, since all our artefacts are electronic it is difficult to see work piling up at a bottleneck. Having a pile of paper planes accumulating makes the pressure surrounding it visible. People can literally see the bottleneck. Having made this visible, it is easy when debriefing for people to relate this to work, and realise how they are creating a bottleneck in a specific area. This same logic is why physical task boards work so well.

Agile Testing with Jenga

A topic we have been doing a lot of training on recently is agile testing. We try to promote testing first through TDD and having testers and developers pair. Often teams like the idea but believe it will slow them down. We use a great game with Jenga [6] to help people realise that although testing upfront and as you go seems to slow you down, if you count the time it takes to correct the bugs that are found, this is much faster than traditional approaches.

So what can I do?

Think about the last time you attending training? What was it like? And what do you remember from that training?

Next time you attend training, find out before hand a bit more about the trainer’s experience and style. Also think about why you are attending and what you hope to learn. If the trainer does run an exercise, get stuck right in. The more you participate the more you will learn. If the training doesn’t give you an opportunity, think about how you can practice what you have just learned the very next day, to get some experience and reflect on how it can help you.

Now think about the last time you tried to teach someone something new: Maybe to a colleague at work? Maybe show your grandparents how to use a computer? What was that like? How much of what you taught them did they retain? How much were you talking, and how much were they experiencing for themselves?

Next time you teach something, consider how you can get the person to experience the concept in a safe environment where they can fail and self-correct.

If you’d like to know more about creating experiential training, here are some resources we would recommend: