I got to his session early and I’m glad I did. The room became packed, with every seat taken about 15 minutes before the session was scheduled to start. Then the floor started to fill up. By the time he arrived, the room was over capacity and the anticipation was electric.

He introduced himself and the session. He then proceeded to go through a series of topics. He would talk for 5 minutes and then ask the room to collaborate around the idea for 15 minutes. This pattern repeated for the better part of 90 minutes.

In the end, we heard from him for about 20 minutes and we spent 70 minutes “working amongst ourselves” around themes that he posited.

With all due respect to the entire room, I did not come to this session to learn from the attendees. I came to hear from the presenter. I left feeling cheated somehow. That he had taken the “agile approach” of collaboration to an extreme and he missed the opportunity to share his experience and stories more deeply with the audience. I felt like he had almost forced the collaboration to some extent.

I left feeling incredibly disappointed.

Experiential Learning

A few years ago I attended the AYE (Amplify Your Effectiveness) Conference in Raleigh, NC. AYE is spearheaded by four consultants who are widely recognized for their experience: Esther Derby, Don Gray, Johanna Rothman, and Gerry Weinberg. I’d guess that there was easily a century of software consulting experience “in the room”.

The conference sessions were marketed as focused “experiential learning”. That is, we would be doing something, playing with something, or running simulations as part of the learning. I hadn’t been to a conference quite like this before, so I was looking forward to learning in this new way.

I remember one of the sessions from Don Gray we were asked to construct a zoo, including buildings and animals out of pipe cleaners. It was an exercise, as I recall, of teamwork and collaboration.

There was another session with Johanna Rothman where we all sat in a large circle and discuss various topics, sharing stories and experiences amongst ourselves. While both sessions provided valuable, I started to get a bit tired of the “experiential” part of each class as the conference went on.

It proved exhaustive at times to figure out what the instructors were trying to get us to learn. In some cases, again, I wanted them to more so share their experience than organize attendees to surface theirs.

To be honest, and I’m a little embarrassed to admit this, I left the conference early. I’d simply had enough “experience” for one week.

TFTBOTR – Training from the Back of the Room

There’s a movement afoot in the Scrum Training group (Certified Scrum Trainers – CST’s) to leverage by the same name. TFTBOTR focuses on brief snippets of learning exchanges using a 4-C approach to learning: Connections, Concepts, Concrete Practice, and Conclusions.

Loni Weaver-Johnson is a CST who wrote about the technique from a CSM class perspective back in 2012. Here’s the she wrote.

My struggle with the technique is not with it directly. It’s just that sometimes I’ve seen instructors put literally ever concept or learning activity into the format. Forcing things in if you will, even if a simple lecture or workshop approach would have been the best way to convey the information.

Gamification OR Games R Us

A common pattern in running Certified Scrum Master classes is to run a simulation for much of the class that gives participants a chance at experiencing a Scrum team. Lego’s are a popular medium for the simulations – the goal being for a team to form and to iterate (sprint) around creating a structure or other object.

Often impediments are thrown into the mix to demonstrate software team dynamics. I run games myself in my training. I like to use a Scrum simulation around creating a Pampered Pooch Doggy Spa brochure in my Scrum introductory sessions. And I love to run something called The Pizza Game as an introduction to Kanban.

I find the games are a way of solidifying the underlying principles we discuss in the class. But I try hard to not let the games take over the content. Something I find many others don’t do as well.

I can’t tell you how many times I’ve attended an agile session where we play a game for 90% of the time and then we basically leave. Sure, there’s a brief debrief, but largely you’re left scratching your head and trying to figure out—now what did I just learn? And how do I apply it to my “day job”?

Enough already Bob, What’s your point?

The truth is, I’m still forming it. I’ve used each of the above techniques or approaches in my own classes. The one I’ve used the least is TFTBOTR, but I’m working hard to incorporate more of it.

But the reality I’ve seen, and it’s a bit of a shiny object syndrome problem, is that nearly every teacher, coach, CST, etc. in the agile community seems to be “All In” leveraging these approaches. And the trend appears to be increasing.

And the real problem I have with it is using the techniques for EVERYTHING – all teaching or instruction and not balancing these new game and experiential techniques with more tried and true instructional techniques. It’s the lack of balance that I’m railing against and not the techniques themselves.

Suspicion

One suspicion I have is that many of my colleagues in this space lack real-world experience and stories to tell about it. And I’m not talking about real-world experience from 10-15-20 years ago. I’m speaking to having recent, real-life, in the agile trenches, experience.

Without being able to tap into that relevant experience, then of course games become a primary teaching alternative. But I’ve found that sharing your experience PLUS some experiential learning and simulations can really be a balanced learning experience for disparate audiences.

Another Learning

I’ve also discovered another thing that I’d like to share. Often these sorts of classes are being given to individual agile team members. But when they are used for more senior leadership, management, or cross-functional students, they actually don’t resonate as well.

For example, I’ve yet to meet a Sr. VP of Software Engineering who would be delighted to sit in a workshop for 2-days and “play with” Lego sets making various types of buildings. Can you get them to do it for a couple of hours? Perhaps. But there’s a limit to the time, attention, and learning methods these sorts of folks will resonate with and tolerate.

So I view many of these techniques as being more “team-centric” and not being as general purpose if you’re trying to train an entire organization as part of an agile transformation.

Wrapping Up

Yes, this article was a bit of a rant against these more experiential approaches. But do I want them to entirely stop or do I think they add no value? No! My rant is against the frequency or pervasiveness of the approaches. And perhaps the reluctance to:

• Lecture
• Tell Stories
• Use PowerPoint
• Provide written class materials

as being evil in some way. Sure there can be Death by PowerPoint. But I’m now positing that there can also be Death by Experiential Learning or Death by TFTBOTR.  May we all strive for better balance!

Stay agile my friends,

Bob.