Doing Trumps Reading: Training from the Back of the Room Workshop June 5-6 2014

What’s the best training experience you’ve been in?  Take a moment to put yourself through the retrospectoscope and consider what made it memorable for you.

Maybe it was a Scrum training.  Or a ski lesson.  Or perhaps a first aid class.  I’m willing to bet that whatever type of training it was, you’re not fondly recalling sitting in a beige room being talked at or PowerPointed to death.  What I remember vividly from a long-ago Scrum training is not the words of wisdom falling from the instructor’s lips, but rather the games, exercises, and conversations with other participants that illustrated and reinforced the ideas being presented.

In Training from the Back of the Room, Sharon Bowman has distilled and shared a powerful framework for designing and delivering training experiences to adults that will help make learning stick.  The Training from the Back of the Room approach is grounded in 6 simple principles (Sharon calls them the Six Trumps) derived from what we know about how the brain actually works to receive and retain information:

  1. Writing trumps reading
  2. Talking trumps listening
  3. Different trumps same
  4. Moving trumps sitting
  5. Images trump words
  6. Shorter trumps longer

None of these principles are revolutionary – yet we often fail to apply them when designing training experiences because they don’t align to what we’ve experienced in the past as a model of “how adult learning is done”.

I’d read Training from the Back of the Room a while back and had attempted to apply the principles in the workshops that I deliver to my clients, but it didn’t really all come together for me until I took Sharon’s class last December.  For me, the workshop was a transformative experience: while I didn’t burn all my slide decks after taking the course (because there’s useful content in there that I can repurpose to be presented in different ways) I will never again deliver training the way I used to.  A couple of weeks ago, I delivered a 3 day Agile team workshop making heavy use of TBR principles and I received excellent feedback from the participants about the interactive nature of the class and the very limited use of slides.  Afterwards, a couple of people in the class told me how apprehensive they’d been about having to sit through a 3day training session, and how delighted they were by how little sitting they actually did and how much fun they had while doing some serious learning and planning.

If you’re interested in learning how to make Training from the Back of the Room work for you, I’ll be offering a 2 day Training from the Back of the Room workshop with Glenn Waters in Guelph ON on June 5-6 just before Agile Coach Camp Canada 2014.  It’ll be a ton of fun, and you’ll walk away from the experience knowing how to apply the Six Trumps and 4Cs (next post!)  to delivering your training content, two of Sharon’s excellent books, and a toolkit of activities and ideas that you can use right away to revitalize the training you deliver whatever the subject matter.


Building Your Dreams at Agile India 2014

I had a great time presenting a User Requirements with LEGO Serious Play workshop at Agile India 2014.  Sharing LSP with a new crowd is always fun, and the 100+ people who participated were enthusiastic and ready to play!

One lovely surprise from my session was the amazing graphic summary Lynne Cazaly created:

I think Lynne’s graphic is a better summary than my slides, but here they are anyhow:

If you’re curious to learn more about how LEGO Serious Play can help your team get work done or move forward in resolving a serious issue, check out my previous post on Why Serious Play Works or leave me a note in the comments so that we can chat.


Interested in presenting at Agile Tour in Ottawa or Montreal?

Agile Tour is a series of one-day non-profit Agile conferences held in 80+ cities around the world in October and November. Agile Tour conferences provide excellent learning value for not-very-much cost by bringing in top-quality keynote speakers and presenters, and are a great way to meet other Agile folks in your community.   Agile Tour Montreal has been going strong for several years now (they’re planning for 600 attendees in 2013), and I’m really excited that the Gatineau-Ottawa Agile Tour 2013 is shaping up to be even bigger and better than last year’s successful inaugural event.

Did I mention the excellent presenters at Agile Tour?  Do you have something to share that you’d be interested in getting out to an audience of energized and interested people?  Both Agile Tour Montreal and Gatineau-Ottawa Agile Tour  are soliciting proposals for presentations.  The deadline for submission is Aug 16 2013 for the Montreal event and August 30 2013 for Ottawa.  If you’ve got an Agile topic you’re passionate about, submit a proposal today!


Steward the living instead of managing the machine: Management 3.0

“..the role of leaders should include the stewardship of the living rather than the management of the machine.” Stoos Network

Management 3.0 is a class for people interested in bettering the practice of management in their organizations.  It’s based on Jurgen Appelo’s very popular book, which examines the kind of management thinking and doing needed to support complex and nonlinear work, such as — but certainly not limited to — Agile software development practices.  Supporting the evolution of self-organizing high-performance teams calls for a different approach to managing people than that which is typically encouraged through organizational culture, training, and change management practices.  The Management 3.0 book and course provide a new basis for thinking about the goals and principles of management as well as many concrete practices that can be used to begin managing in a new way, even if your organization is just starting on a transformation to a more agile way of working.

Francois Beauregard of Pyxis Technologies brought an interesting perspective  to facilitating the course material based on his experience as an Integral Development coach.  In the course of exploring the Spiral Dynamics model in the first few hours of the class, we talked a lot about the importance of compassion (a word that oddly doesn’t appear in the text of Management 3.0) when assuming the responsibility for stewardship of the living in an organization.  We also explored the possibilities created by differentiating between responsive and reactive behaviours.

Martie, the Management 3.0 Model

Martie, the Management 3.0 Model

The first morning of the class was very talk-heavy, but this was balanced by the very hands-on nature of the remainder of the material, which considered each of the aspects of Martie, the six-eyed Management 3.0 model.  Martie’s eyestalks each focus on one of the six views of management  (Appelo specifically calls these views to reinforce the idea that these are different perspectives intertwined within a complex system rather than independent principles/concepts).  We talked briefly about each view and then tried a exercise that can be used to explore how this viewpoint is instantiated in an organization.   The exercises are designed to be playful and immediately useful for taking back to the office and instigating discussion: games like Delegation Poker and Meddlars provide quick ways to delve into messy issues of individual motivation or organizational transformation and to visualize complex situations so that considered action can be taken.

I particularly liked the Moving Motivators exercise, which allows people to reflect on what motivates them, and visualize how a decision or change might affect the aspects of your work that give you satisfaction.  I can see this being a very useful tool in getting to know a new employee or in doing some pre-work to consider how an upcoming change may affect the morale of team members.  It might also be useful as an individual exercise for examining your own motivators in the context of a work or personal situation – I may run this exercise with my teenage son to help him think through some decisions he needs to make.

All the materials from this class are easily accessible outside of the training.  The content comes straight from the Management 3.0 book, and all of the exercises are downloadable from the Management 3.0 site, so there are ways to get at this goodness if you can’t get funding to attend the course.  Having said that, like most good trainings I’ve attended, the greatest value is not in the material itself, but in the discussions and interactions that take place in the classroom, sharing insights and reservations about what is being presented with other interested people.  The other thing to keep in mind is that while this is a management class, the content is important regardless of your role in the organization – management is by definition a 2-way relationship, and it’s important that people who work in a company understand what good management practice looks like and how their organization is designed to support (or block) it regardless of what their title might be.


Ahoy mateys: Swashbooking yer learnings!

I firmly believe that Sunday mornings are best observed with a pot of hot coffee and a book or two to enjoy.  So at Play4Agile2013 in February, on Sunday morning I pitched a Swashbooking session as one of the early slots in that day’s Open Space (though in my sleep-deprived and slightly hung-over state, I’m sure I called it ‘Bookswashing’ – I always get this backwards!).   I also talked about it recently during an Agile Ottawa session as a tool for hacking your thinking, as I believe it’s a great technique for crowd-sourcing booklearning regardless of the time of day.

Swashbooking is a timeboxed approach to quickly skimming books to look for anything important, which can be practiced alone or collaboratively as part of a group.  I first learned of swashbooking from Deb Hartmann Preuss (a woman who continually gets me into all kinds of good trouble), though the idea originated with James Marcus Bach, whose work as a software tester and educator has inspired me in many ways.  James’ excellent book Secrets of a Buccaneer-Scholar vividly describes his experiences with hacking his own education.  He has shared a video on Competitive Swashbooking capturing an 8-hour marathon wherein he and his brother Jon swashbooked their way through a diverse collection of 100+ books in order to produce a short presentation about what they learned.

Group swashbooking as I’ve practiced it is very simple:

  1. collect a diverse selection of books, at least one per participant. For rapid skimming, paper books offer a distinct advantage over ebooks.
  2. each person in the group selects a book and reads it in whatever way they prefer for a short period of time (6-10 minute timeboxes work well).  The reader may read a chapter, scan the table of contents or index, flip through and look at all the illustrations — whatever works for them in finding something important in the book at hand.  Recording observations as you go will be helpful, so stickies or index cards and a pen will come in handy.
  3. at the end of the timebox, each reader passes the book along to the next person in the group, who then reads it in whatever manner appeals to them as outlined in step 2.
  4. Repeat step 3 until everyone has had a chance to examine each book
  5. Have a short, time-boxed group discussion to share observations and impressions of the books being considered.

For a group of 5 people, the timing might work like this for a 60 minute swashbooking session:

  • 5 min intro
  • 30 min reading – 5 * 6 min reading sessions
  • 20 min discussion – 4 min to share impressions of each book

The outcome of a swashbooking session is that all participants get a good overview of what some of the important aspects of the book might be, and have likely learned enough to make a decision of whether it’s worth digging further into a particular book.

At p4a13, the result of the session was that we all decided we really wanted to read Turn the Ship Around  cover-to-cover, and there’s a plan afoot to set up a virtual Agile book salon to discuss it in a couple of months.  I’ve also done this with my business partners and at other events, and in every case the participants have found the experience fun and beneficial.  I can also see using this very successfully in a problem-focused situation, particularly with a diverse selection of books (bring poetry! bring picture books!)  in order to stimulate creative thinking about the problem space.

If you decide to try Swashbooking, please leave me a comment letting me know how it worked for you.


Games with Distributed Teams at Play4Agile 2013: An unexpected takeaway

One of the most vivid sessions I took part in at the Play4Agile conference in Germany last month was a session on Games for Distributed Teams.  Led by the amazing Silvana Wasitova, this discussion built on the preceding session about “Games in 5 Minutes” to explore how these activities can be used with distributed teams.  I was hoping to get some new ideas for games to use with teams that are not colocated, since in my experience it’s rarer and rarer to find teams where everyone is located in the same city, let alone the same office. While we talked about and tried some games that could be played across a group of people connected only by a phone line*, for me the fascinating part was how this experience could also be used to demonstrate why there is really no good substitute for in-the-same-room face-time for teams that need to work together.

My discomfort started with the distributed seating arrangement in the room.  Rather than arranging chairs in the usual informal circle, Silvana lined up participants along either side of the room with a row of tables in the middle.  This immediately created an unsettling sense of disconnection with half of the group, though we were sitting only metres apart and could see each other clearly.

We then played a very simple name game, where each player says their name, followed by a word starting with the first letter of their name, and then the next player tags their name and word onto the name chain alternating from one side of the room to the other: “Ellen Eggplant, Sven Serendipity, Henna Hornet….”. This was easy enough when players were seated facing each other.  But then we replayed the game with one row of players with their backs turned to the room, and a row of dividers down the middle to block the sightline from the other side.

IMG_0327

The difference in the two experiences was astonishingly visceral.  Firstly, the game suddenly became much harder, even though we had already had a practice round which helped with learning everyone’s names and the flow of the game.  Without being able to see the other players, remembering the order of names and the second words was somehow much more difficult and the repetition of names proceeded much more slowly.  The other thing that really hit home was how easy it was to disconnect from the activity once we weren’t actually looking at each other.  I stood up with my iPad to take the picture of the room and because I’d already had my turn, once the picture was done it was too easy to tune out for a moment to check Twitter and email rather than attend to the game – even though we were all still in the same room, mid-session, engaging in a very brief activity.  Embarrassing, but illuminating and all-too-familiar**.  In the debrief afterwards, other people related experiencing a similar sense of disconnection once people in the game were no longer looking at each other throughout.

We then talked about some other ideas for games for non-colocated teams, such as the excellent on-line Innovation Games that I have used successfully for retrospectives and brainstorming when participants can’t all be in the same room.  But despite all the great ideas, what I really learned from this session is how to create a simple exercise to really show team members (and their leaders) what the effects of sitting apart – even without leaving the same room – can be on intra-team communications.

________________________________________

*<rant> maybe it’s an Ottawa public-sector peculiarity, but many of the distributed teams I’ve worked with recently haven’t even had access to basic communication tools like corporate Instant Messaging or wikis, let alone high-quality video connectivity.  If securing communications is an issue, perhaps IT departments should provide alternatives to using Twitter or Google Chat on personal devices for work communications?</rant>

**<rant>I spent a year working on a dispersed team for a huge multi-national project involving three different global companies where almost everyone worked from home, connecting principally by phone/email/IM.  While I loved the experience for personal reasons (baths at lunchtime!  jeans!  flextime!), I think it was disastrous for the project in how much it slowed down getting things done.  I spent almost all day on the phone dealing with things that would have taken a 10th of the time had we been colocated.</rant>


So you want to know more about LEGO Serious Play?

Despite the slushtacular weather yesterday evening, quite a number of people made it out to the workshop I gave at capCHI last night on User Requirements with LEGO. We had a great time doing an intro to LEGO Serious Play and modelling users for an Ottawa Snow Portal. I’m always amazed by how much work can be done in a short period time using this approach.

In 60 minutes, it’s hard to do more than present an overview of the LSP process if you’re going to have time to do any building (and building is way more fun). If you’re interested in learning more about the history and methodology of LEGO Serious Play, here are a few sources of information that you can start with:

seriousplay.com – the official site for LEGO Serious Play

The Strategic Playroom – a hangout for the global network of facilitators interested in using creative, playful approaches (incl. LSP) to improve organizational performance. The site is hosted by strategicplay.ca, where you can go for information about facilitator training

User Requirements with LEGO – the guide for applying the LSP approach to collaborative gathering of user requirements for online projects.

Agilitrix.ca – Michael Sahota, an Agile coaching colleague and fellow facilitator, has published some great videos and posts relating his adventures in using these techniques in Agile contexts.

I’ll post additional materials down the road.  Some of last night’s participants asked some very thought-provoking questions about the approach and I have some research to do to find answers.  Stay tuned!


43 sleeps until Play4Agile 2012!

I’m very much looking forward to participating in Play4Agile 2012 in Germany next month.  Last year’s inaugural event was such an amazing experience that registration for this year’s unconference sold out in less than 12 hours.   I registered for p4a11 one year ago today, thinking that I would take a bit of a busman’s holiday – fly to Germany for a weekend (!?!), meet some interesting people over some good beer, and hopefully learn a new game or two to use with the teams I work with.

At last year’s event, I definitely learned a few new games.  I also helped create 2 new games with people from 4 different countries, taking challenging ideas from concept to a first play test in less than 5 hours, and learned some great stuff about game design along the way.  I experienced the magic of LEGO Serious Play for the first time. And I met wonderful people: there were many gifted coaches there who shared their wisdom and experience through Open Space sessions, during shared meals, and over beers into the wee hours of the morning.   The energy and spirit of the event was astonishing – despite having slept very little because of the time difference, I returned home revitalized, refreshed and raring to go.

So what will this year’s event bring?  The theme for this year’s event is “High PLAYformance for Agile teams”. I believe that play is a critical component for successful teams, and I’m hoping to get some ideas for how to bring more playfulness into day-to-day work.  I’m really looking forward to meeting up with the Europe-based StrategicPlay gang again and doing more cool things with LEGO.  I’m especially looking forward to the evenings in the bar at the SeminarZentrum Rückersbach, where the days will be discussed over Werewolf or Smallworld or Bausack.  I know it will be a great unconference – the only challenge will be figuring out how to get enough sleep to make the most of it.


Taking a Few Trips Around the Elephant: A quick and dirty guide to release planning

Earlier this week at a combined Agile Ottawa/Ottawa Scrum User Group joint event, Joe Little facilitated an entertaining discussion about the basics of Agile release planning. This gathering was instigated by a question at an Agile Ottawa meeting a few months back about whether any sort of release planning happens in an Agile context. Given that much of the Scrum canon just does some vague hand-waving around this topic, it’s understandable that there is some confusion out there about what kinds of release planning a team might wish to undertake before diving into the nitty-gritty of getting things done.

Some teams breeze right past release planning — I’m constantly amazed that organizations in the habit of taking months or years to collect and sign-off on project requirements balk at spending a few days workshopping a release plan before jumping into delivery mode because “It takes too much time! We need to get started!”. Others spend weeks doing big upfront architecture and detailed design in the guise of “Iteration Zero” before writing a single line of code. Neither approach makes sense. It’s well worth spending a brief period of time to take the team on a few trips around the elephant to develop a shared understanding of the problem to be solved, but the amount of time spent should be limited to just enough to develop an understanding of the big picture, get the conversations flowing, and to resolve the relatively few decisions that really must be made up front. For a release plan for 6 months of work, it might be reasonable to spend 3-5 days having a release planning workshop with the whole team: scale up or down relative to your intended release cadence.

So what do you need to do to get started?  Here are the basics of Agile release planning:

  • Introductions: Get everyone in the room together – product owner, team, key stakeholders – and do some introductions/activities so that people get to know who they’ll be working with. Even in a relatively stable environment, there are likely to be new faces on the team, which means you have a new team.
  • Why are we here?: Share the vision statement for the work, and the value of finding a solution (put into dollar terms if you can, or some other quantifiable measure of importance). What are we trying to achieve here? How much is it worth to us to solve this problem? This is a great opportunity for an Important Project Sponsor to make an appearance and explain the value of this project to the organization.
  • Create the product backlog: identify the roles/users within the system, and feed that knowledge into a user story workshop to create a release map of user stories based on roles and activities.
  • Assign business value to the backlog: Discuss what ‘business value’ means in this context. Then use Planning Poker or another relative estimation technique to assign Business Value Points (BVP) to stories.
  • Estimate the backlog: Have any upfront infrastructural/architectural discussions that may be necessary to get a big picture of where things are going and to identify technical decisions that need to be made up front (which are usually fewer than you think). Have the team agree on initial “Definition of Done” at the story and sprint levels. Then use Planning Poker to assign Story Points (SP) to the stories in the backlog.
  • Prioritize the backlog: Now you’ve got Business Value Points and Story Points for each item. With those two values, you can then do some very simple math to arrive at a crude-but-useful Cost-Benefit Analysis (CBA):

BVP/SP=CBA

Simple and rough, but very useful to help prioritize the work quickly. So now, prioritize that backlog!

  • This is also a good time for the team to start identifying the risks, dependencies and other considerations that need to be made transparent to the team and stakeholders before embarking on this adventure together.

If you’ve now got a prioritized and estimated backlog, the team can probably come up with a very very very rough release estimate of schedule and scope. This estimate will be woefully inaccurate, but should give everyone a sense of what might be possible. After 3 iterations, you can use your velocity data to revisit this release estimate.

Lastly, don’t forget about the regular care and feeding of your Release Plan: During each iteration, the team might have 2 release-focused meetings (sometimes these are called backlog grooming):

  1. Big picture backlog maintenance (can be done early in the sprint, and maybe everyone doesn’t need to attend this meeting as long as you have a good cross section of skills/views in the room). What does your velocity tell you about how much of that backlog might get done by what point?
  2. Top of the backlog maintenance so that it’s ready for the next sprint planning (1-2 days before end of iteration, everyone should attend)

Bon voyage!


…because Agile teams burn HOT!

Mishkin Berteig made a great point last week about how The Agile Planning Onion is Wrong.  Mishkin notes that “culture both surrounds the planning onion and cuts right through it” .  He goes on to suggest that we update the metaphor to at least allude to the double-loop of learning in order to foster a more conscious approach to applying learning and planning to the organizational culture as well as the product.  And then he asked for some help with creating a new diagram…

Serendipitously, Mishkin’s post came shortly after I attended Luke Hohmann’s keynote on Innovation Games at Agile Games 2011, during which he proclaimed that the Planning Onion ought to be replaced by the Planning Flame “because Agile Teams Burn HOT!”.  Having some pyromaniacal tendencies myself, my interest was sparked by the idea of the Planning Flame.  I like how it conveys a sense of creating energy and shedding light on things rather than just growing quietly in the dirt.  If you extend this notion to incorporate the idea of culture as the medium in which all of this combustion happens — or where things can fizzle out if the atmosphere doesn’t contain the right mix of environmental attributes to support the flame — you might end up with:

Quickly done in Google Draw, but it gets the point across

Mishkin also commented that the flame metaphor supports the idea of change;  flame is never static and always transforms what it touches.

Sorry planning onion – you’re cooked.