I have an interest in how people learn and what it takes to be a successful teacher. This interest has taken me on a trip into the world of neuroscience where, it seems, a lot of useful information has appeared in recent decades while most of us were going about our business using stale techniques. My interest in neuroscience has opened up the door to “Accelerated Learning” techniques. In particular, I am using the book “Training from the Back of the Room” by Sharon Bowman to redesign my courses into a more experiential style than before.

I have always incorporated hands-on exercises in my training - which goes way back into topics of interest prior to the rise of Agile development. But I never had a good understanding of why exercises were important. Now I am emphasizing the experiential part of the training and leveraging Bowman’s theses that participants already know most of what you were expecting to teach them and that they learn from each other better than from you, the trainer. This viewpoint provides the opportunity to spend time in the back of the room observing rather than force-feeding information.

I want to be clear that training from the back of the room is not as easy as it sounds. A lot of effort goes in to designing and facilitating the class. An unexpected benefit for the trainer is that this style gives you energy rather than depleting it.

I also picked up a book called The Accelerated Learning Handbook by Dave Meier to get some more grounding in the reasons why these techniques work so well. I was not surprised to see a couple of familiar names in the book. Many years ago I had the pleasure to experience accelerated learning in an intensive French class taught using Super Learning techniques ala Georgi Lozanov and Ivan Barzakov, two pioneers in the field. It was a fabulous experience and extremely successful for me personally. In more recent times, I have experienced similar immersion learning in coaching skills from the talented people who run the Amplifying Your Effectiveness conference and the Problem Solving Leadership workshop.

As a coach, my job is to help people find their own solutions. A consultant’s job is to solve someone’s problem for them. If an organization purchases a solution by hiring a consultant, there is a lower emotional investment in the success of that solution. On the other hand, helping people find their own solution results in a higher investment and ownership of the solution increasing the probability of success.  A coach may not know what solution is best but is skilled in leading an organization to the discovery of a solution that is good for them.

I am starting to see training as analogous to coaching. If the teacher simply tells the student the facts or perhaps points to facts in a book, the student does not own those facts. The application of those facts in real life may be mechanical, brittle and half-hearted. If, on the other hand, the teacher can successfully impart the motivations, spirit and principals of the topic, the student will come to a stronger understanding and start to own that knowledge. Follow-on action will be better informed, more strongly motivated and energetic.

How do we do this? I suggest that you buy the books or others like them for a full answer. Here is the condensed version of what I have learned so far about creating an accelerated learning experience.

• Provide a safe environment
  • This means more than just free parking. Take care of basic needs like food and hydration. And make it safe for people to speak their minds. I provide stress balls to help with difficult learning moments.
• Create a space that is rich in sensory stimuli
  • Brains build stronger neural nets when the experience is colorful, bright and musical. I supply arts and crafts supplies, drawing pads, posters on the wall, a collection of reference books, upbeat background music when appropriate.
• Involve the entire body
  • We learn faster that way. These days we communicate too much through electronics. Our hand gestures are usually aimed at SmartPhone interfaces. The brain evolved to power a human being with many moving parts and sensory channels. Knowledge is wired in faster when the whole body is involved. This means exercises in both senses of the word – things to do and people in motion.
• Promote spontaneity within a visible structure
  • Give people an idea of where they are going and where they have been. Then allow things to emerge. Build on what happens. Help people find the lessons in what they experience.
• Link the topic to the participant’s prior understanding of the world
  • If you try to substitute current knowledge with something entirely new, it will backfire. The brain gets defensive. Fear circuits in the older parts of the brain kick in. Sensory inputs shut down. The more modern parts of the brain in charge of reasoning, synthesis and wonder are blocked while energy is used for defense. It is better to build on what people know and edit existing neural networks rather than trying to form whole new ones to replace the old ones.
• Work in small collaborative groups
  • Creativity is higher. Learning is enhanced by people sharing their experiences. And, yes, people really do know a lot about the subject already. Draw this out by providing chances for them to share it. Sharing reinforces concepts in both the provider and their collaborators.
• Have fun
  • Learning is quicker that way. In my French class way back when, the experience was purposely designed to be like the conditions we experienced when we learned our first language – safe, simple and playful.
• Plan to cover the essentials and no more
  • Keep to the basics and let the details and variations come when they may. This means being clear about the learning objectives and being courageous enough to throw out half of what you previously tried to cover – especially your pet topics. I admit to having some challenges with this one still.
• Park your ego at the door
  • It is no longer about you being the smart person in the front of the room, fielding questions to show off how much you know. If you are going to lecture, never talk for more than 10 minutes before giving the class something to do on their own. It is a tough habit to break.

In Bowman’s book, she presents a handy model for designing a training class. It starts with clear learning objectives. Then you assemble the concepts to be covered in a module of 20-30 minutes. Then identify some activity that will connect the concepts to something they already know. Next you do one of two things: give the class an exercise to discover the concepts from each other or from the environment (books, handouts, posters) or present the concepts briefly followed by an exercise to practice them. Finally close the topic with another short activity that reinforces the learning.

There is much more to it as described in the book, along with many ideas for exercises. I have had great fun and good success with these techniques. And I still have a lot to learn.

I would like to acknowledge two partners in this adventure. Bob Hartman introduced me to Bowman’s book as I was trying to get there on my own without knowing the true destination or path to it. Mark Levison has inspired me to study the neuroscience of learning and is my partner in broader studies of how a knowledge of neuroscience can improve our skills as trainers and coaches.

References

- Bowman: Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn

- Meier: The Accelerated Learning Handbook: A Creative Guide to Designing and Delivering Faster, More Effective Training Programs

- Bob Hartman, CST, CSC @ Agile For All

- Mark Levison, Agile Coach @ Agile Pain Relief

- Amplify Your Effectiveness

- Problem Solving Leadership

Where They Apply in Agile Development

When training people in basic Scrum, we often talk about the Five Levels of Planning. I always put it in what I call the Product Context (organizational strategy and product portfolio). Luke Hohmann, inventor of Innovation Games, calls these levels the Planning Flame:

Innovation Games can be used for some of the planning activities that are within the Agile/Scrum boundary. Mike Griffins gives some examples at LeadingAnswers. During the class, Alan Shalloway worked with Luke to quickly prototype a new online game for affinity estimating of user stories based on Steve Bockman’s Team Estimating Game. Use of the games in the team context are always applied to achieve convergence – finding consensus and keeping everyone going in the same direction.

The more valuable learnings for me, though, were the use of these games at the outer levels of the flame, market research, for which they were originally designed. This is where real customers are involved in helping organizations develop and refine strategy, new products to realize those strategies and new feature areas for existing products. Luke expressed a goal of bringing the Agile mindset to product marketing. One motivation is that Agile teams can build product faster than traditional market research takes to define products. So the games provide ways to speed up the research process – gaining qualitative data more quickly and identifying targets for quantitative data gathering more efficiently.

Innovation Games used at the outer layers can be applied for either convergence or divergence. Often the players have very different perspectives. They may be from different market segments, different customer organizations, different geographical areas. The games are used to discover the values and possible actions based on those perspectives. This may lead to multiple responses rather than a single aggregate response (ex. a line of products vs. a single product or a roadmap based on successive target markets). Awareness of divergence can even lead to whole new product ideas (“You use our product to do what?”).

Emergent Value

While it was both fun and interesting to learn about the games and game framework and to play some of them, I was also gifted with a challenge to my belief that collaboration is best done in person. (See Tips for Distance Training). Luke told the story of how a client asked for the games to be playable online in order to cut down on travel costs. After some discussion and work the online games emerged. And guess what? You can do things with the online versions that you can’t do with the physical versions. You can reach more people and more time zones. Some synergies of physical presence are missing but observation of co-located games gave guidance to some interesting designs in the online versions that lead to other kinds of synergies. And you can get different kinds of information from the two versions. So, perhaps counter intuitively, technology brings a different set of capabilities and  opens the games up to an even wider set of possible uses.

Other Applications

The games can be used for other purposes beyond market research. They can be used to solve allocation problems, design questions and prioritization puzzles - many things that benefit from multiple points of view. If you take the class, you will begin to see the wide range of applicability.

One especially intriguing area of application is in public debate and discourse. Imagine if you could share your opinion on civic matters in other ways besides the polling booth. Take a look at GamesForDemocracy.org to see where that idea is going.

Recommended for Agile Coaches

Innovation Games are well defined and have years of road testing. The book gives clear instructions on how to plan and execute a game. They can be done alone or combined into “cocktails” to drill down to a solution and be “hacked” to suit specific circumstances. They hold a huge promise for finding out about commonalities and differences in how groups of people think. They come with many business success stories and are beginning to be applied in not-for-profit areas. I highly recommend that you give them a good look.

A recent coaching client is a small company that wanted to transition their entire development department to Agile. It was an easy sell to the applications people, harder to the maintenance people (until I told them about Kanban). The ones in the middle were the mainframe programmers. This company is in insurance, an industry that has lots and lots of legacy backend systems.

I have met mainframe programmers in my Agile travels before who were resistant to an Agile approach. The reasons are many but mostly based on the constraint that legacy systems take longer to change and mainframe systems in particular are not amendable to Agile development practices.

In this particular case, I was pleasantly surprised to see interest, even enthusiasm, at tackling a project using the Agile framework even though the systems involved were RPG, COBOL and CICS. I want to summarize the experience by describing what Agile practices we implemented, what challenges we faced and what successes we saw.

Standard Agile Practices

• The team was small: 3 developers and a QA specialist also playing the ScrumMaster role. There was a dedicated Product Owner who was a Business Analyst familiar with the problem to be solved.  The sponsor, a Product Manager, was also highly involved.
• The team chose a 3-week Sprint length based on unfamiliarity with Agile in general , the observation that tasks and stories might be larger (in hours required) than in other projects and the realization that team members could not cover for each other well due to specialization.
• Detailed design was incremental.
• Features were prioritized and done in priority order.
• The Product Owner and end-users were involved on a daily basis.

Challenges to Standard Agile Practices

• The developers were highly specialized in their technologies. Cross-training was limited by a steep learning curve. Yet there was some.
• Automated testing was considered to be impossible. We brainstormed this at great length. At the unit level, well – what is a unit in COBOL? It is a structured language. Programs are huge, monolithic. Compiles take a long time. It is tough to run just part of the code. Testing is done by stepping through a debugger and fiddling with variable values in memory. This does not lend itself to automation. We looked into screen recording and playback, which is possible, but the resulting scripts are extremely fragile. In the end, the relative cost of investigation was too high for the short project timeline.
• Having a small team did cause some delays when people were absent.

What We Got

• During backlog estimation, elaboration of a story was short-circuited when it became apparent that the business was asking for something that was technically impossible within the downstream host system. The story, initially estimated to be quite large, was simply dropped. The Product Owner was not concerned at the loss of the functionality given the essentially infinite cost of the story even though it had originally been prominent in the original project BRD. Cost savings were estimated at about $10,000.
• While planning Sprint 2, another large, high priority feature evaporated when the PO realized that the work done in Sprint 1 resulted in a sufficiently useful solution to the goal of the story. The feature was a real-time update of data from one backend system to a front end on another system. User testing of the first sprint product showed that batch updates had sufficient value and were much simpler to implement. Poof, another $10K saved.
• The team felt that these savings would not have been realized in a traditional project approach. The requirements would have been baked into a design document and implemented as well as possible without any discussion with the Business.
• Changes in other requirements resulted from continuous review by the PO (“Now that I see it…”) and were not an issue for the developers .
• The project was short, but still completed so quickly compared to pre-Agile expectations that the team stayed together to implement another set of features out of the scope of the original BRD and budget.
• The team, some of who were skeptical, had fun and enjoyed the success. The Business was very pleased as well.
• The pre-Agile estimate of work was 2 years elapsed time in this highly multi-tasked environment. The Agile project was completed in less than 3 months thanks to a focused effort. Time value of money, anyone?
• Thanks to executive story pruning by the Product Owner and Sponsor, the product shipped earlier than even the original Agile estimated release date.
• Management had a greater knowledge of status without having status reports simply by attending the daily stand-ups.

Conclusion

So, did Agile work out well for this all-mainframe project? Indeed it did. Even though it was not full XP in technical practices, using a Scrum approach and Agile principles resulted in both earlier ROI (cost savings for end-users) and lower cost (thanks to evaporating features). Oh, and everyone had fun doing it - always a good sign.

I took an Improv workshop at Agile2008 and really enjoyed it. I have been looking forward to a chance to do it again. This session was led by Todd Sedano from Carnegie Mellon. We did a number of cool things. I wanted to share one in particular because it was simple and, for me, powerful. It was called Gift Giving.

“I have given you a box. It is wrapped and has a gift inside. Take it, lift it, examine it. Now tell us what you find.”

We had a moment to look over our invisible boxes. One-by-one we described our boxes and the gifts inside. Mine was white with a black and orange ribbon. Inside was a Willie Mays autographed baseball glove and a can of neatsfoot oil. While the other people in the session were describing their boxes, I took out my glove and began pounding it quietly to soften it. I was having memories of childhood, when a new glove was a rare treasure. Back in the day I would spend hours working in neatsfoot oil to keep my glove soft. It was a special aroma, the oil and the leather.

What brought that image to mind? It must have had something to do with being in San Francisco and having seen a few Giant’s games this year. Doesn’t matter. It was fun.

The real gift, though, came from what Todd said about how he uses the exercise. Whenever he goes in to a consulting engagement, rather than feeling uncertain about meeting the unknown challenge ahead, he pictures a Gift Box waiting for him. He anticipates that the job will have something for him beyond what is written into the contract.

And so it is with Agile Coaching. We go into an engagement with our toolkit ready, but we never know for sure what we will find. It is easy to feel some concern that we might encounter something outside of our experience. This is not unreasonable - every place is unique, every person is unique, every team is unique. So it takes trust in our skills to go in with confidence that the job can be done before knowing for sure what the job is. Believing that the job will also have a gift for us, and not knowing what that gift is, makes the job all that more interesting. And it can help increase our confidence. Each engagement brings new learning, honing of skills and broadening of horizons. All of that makes us better at what we do and more valuable to our customers.

So now when I step into a coaching situation, part of my preparation is to wonder “What gift will be waiting for me here?”