So you want to know more about LEGO Serious Play?

Posted: January 18, 2012 | Author: | Filed under: Agile, Lego Serious Play | Tags: , | Leave a comment »

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!

Posted: January 5, 2012 | Author: | Filed under: Agile, Lego Serious Play | 1 Comment »

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.

Think with your hands!

Posted: September 23, 2011 | Author: | Filed under: Agile Coach Camp, Lego Serious Play | 2 Comments »

Is your team is interested in new approaches to encouraging meaningful discussion about big opportunities or challenging problems? Playing with Lego can help! Serious fun can result in serious work getting done in not a lot of time, with a lot of laughter along the way.

Lego Serious Play is a playful approach to tackling challenging conversations about individual professional development, team dynamics and organizational strategy and planning. Through playful work, you can engage the creativity and enthusiasm of employees who may not be contributing everything they have to offer. Strategic Play with Lego Serious Play always includes 4 phases:

1) Building a model
2) Giving meaning to the model
3) Making a story to share the metaphor and meaning with others
4) Reflecting upon the knowledge that emerges and considering how to proceed.

Everybody builds. Everybody talks. The result is the emergence of a truly shared understanding that incorporates every participant’s point of view. It’s hard work, but it’s also a lot of fun, which helps people stay in the flow zone where they are the most engaged in the work at hand and creating the most valuable insights.

Working with Michael Sahota, I’ll be co-facilitating some Strategic Play with Lego Serious Play this weekend at Agile Coach Camp US in Columbus OH. I’ll tell you more about how it goes in my next post.

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

Posted: July 28, 2011 | Author: | Filed under: Agile | Tags: , , , | Leave a comment »

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!

Posted: April 27, 2011 | Author: | Filed under: Agile | Tags: , , | 3 Comments »

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.

Steps for creating a new game

Posted: March 6, 2011 | Author: | Filed under: Uncategorized | Tags: , , | 2 Comments »

Play is powerful stuff. I had the tremendous good fortune to take part in Play4Agile, an Unconference on games for Agile teams held near Frankfurt, Germany two weekends ago. It was a tremendous amount of fun and a really intense learning experience — there were so many skilled and enthusiastic people there to learn from and create with that a goodly number of new games were generated over the course of the weekend.

One of the (many) really helpful sessions I took part in was a session on designing games organized by Antti Kirjavainen and Ole Jepsen. I’d already started collaborating on a game with a small gang of people, and we all attended this workshop in order to figure out where to go next with our ideas. Annti gave us a road map for developing a new game:

1) Vision: Why should people play this game? What will they learn? What will they achieve?

2) Identify:

  • Objectives – what are the intended outcomes of the game?
  • Constraints – what the limitations for the activity (how may players, how long might it take, what supplies are available)?
  • Use contexts – who will use this game and how?

3) Brainstorm! – generate a pile of ideas for building a coherent activity

4) Define the game concepts:

  • what do the players do?
  • what is the goal of the game?
  • when does the play end?
  • what are the game objects?
  • what are the main features of the game?

5) Generate test questions to evaluate the game:

  • Is it fun?
  • Are the players engaged?
  • Is it scalable?
  • Is it potentially viral?
  • Do players get the intended ideas?

6) Create a prototype

7) Play test

8) Consider the answers to the test questions based on experience, and go back to step 4.

While this map is simple, creating a game itself is not, thought an idea can grown into a game quite quickly.  My next post will get into the nitty-gritty of how we put together the first version of “Nobody’s Perfect” in about 5 hours.

Recommended viewing: The Biology of Business

Posted: September 17, 2010 | Author: | Filed under: Uncategorized | Tags: , , | Leave a comment »

Hat tip to Thom Kearney for drawing my attention to this great presentation:

Meeting Expectations

Posted: September 10, 2010 | Author: | Filed under: Uncategorized | Tags: | Leave a comment »

A member of a team I’m working with recently observed that the team’s design workshops were much more effective when she (and everyone else) came to the meeting prepared with an agenda, examples of the problem space and some other concise reference materials related to the design discussions. Having this pre-work (and pre-thinking) in place made the meeting flow smoothly and helped participants understand the context for the decisions being made so that a lot of ground could be covered in a relatively short working session.

The observation that meetings will be more effective with some thoughtful preparation seems like common sense, but somehow I still find myself attending too many meetings that waste people’s time and energy because the intended outcomes aren’t clear and/or necessary info & decision makers aren’t in the room. I sense that because Agile favours lightweight processes and documentation, some teams have formed the impression that you shouldn’t be worried about things like agendas and preparing for meetings/workshops/whatever kind of group session, because you’ll do it all “just in time” (i.e. “making it up as you go along”); this is a misunderstanding, as Agile work practices place great value on identifying desired outcomes and how you’ll know you’re done before you dive in to a piece of work, as well as timeboxing work to help make sure that something of value gets delivered in the time available.

There’s a lot of really good advice on facilitating effective meetings readily available. I go back to Jean Tabaka’s book Collaboration Explained repeatedly for guidance on how to facilitate effective meetings while fostering collaboration and creativity. One technique from this book that I’ve had great success with is building agendas using a set of questions; rather than just identifying a topic for discussion, phrase the agenda item in terms of the specific question(s) on that topic that the group needs to answer. This technique has three advantages:
• people are prepared for what specifically needs to be discussed/decided
• there is an clear outcome to the discussion identified from the outset so that participants know when the topic is “done” for the meeting (“have we answered this question?”)
• it limits rat-holing by redirecting focus back to the specific aspect of the topic to be addressed
Agendas might also include timeboxes for each topic/outcome in order to keep the group on-track. It’s astonishing how much can actually be accomplished in a few minutes of discussion when the team is prepared and focused.

You can help tighten up your team’s meetings even if you’re not the meeting facilitator. Esther Derby provides a great list of suggestions that any meeting participant can implement to help improve meeting discipline, including :
• ask for an agenda ahead of time
• send only one person from your team
• politely decline the invitation
• offer to take notes
• facilitate from where you sit
• ask for progress checks
• help others participate
• summarize
Lastly, don’t be afraid to ask questions about the proposed duration of a meeting. Microsoft Outlook has conditioned us to schedule meetings in 30 minute increments, but different meeting purposes require differing amounts of time (often less than 30 min or 1 hour). Using arbitrary timeslots because that’s what the scheduling app gives you by default leads to Parkinson’s Law. Be bold and schedule a 15 minute meeting if you think the objectives can be met in that time. And rather than waiting several minutes to begin in order to accommodate latecomers, start your meetings right on time and end them after 25 or 55 minutes to allow participants time to get to their next engagement (of course, if your team is dedicated and co-located, this is a non-issue).

Watching the garden grow…

Posted: July 21, 2010 | Author: | Filed under: Uncategorized | 1 Comment »

I had the rare delight today of participating in an Agile lunch and learn at a client’s site.  There have been a series of successful lunch and learns there over the past several months, but this one was different in many ways.

An Agile lunch and learn attended by a few dozen people, despite the fact that no lunch was provided.

An Agile lunch and learn that (as an Agile coach) I had no part in organizing or running because it was completely organized and carried out by people I’ve been coaching over the past several months.

A lunch and learn on Open Space – complete with a small series of lightning talks!   A beautifully-orchestrated lunch and learn that was rigorously timeboxed so that everything unfolded within 90 minutes.

A lunch and learn attended by senior executives who took an active part in the proceedings and openly expressed considerable enthusiasm for setting up a larger Open Space event for their entire IT organization.

Some days are very good indeed.

Playing to Learn

Posted: July 19, 2010 | Author: | Filed under: Uncategorized | Tags: | 3 Comments »

Learning can be fun.  Heck, let’s just get straight to the point and state unequivocally that learning should be fun, dammit!  Learning through play is also a powerfully effective way for people of all ages to acquire and accumulate new concepts and practices.  Current neuroscience suggests that using a variety of approaches to concretize ideas and create new neural networks through a variety of sensory engagements is the best way to for people to learn.  Take a moment to go read Mark Levison’s  InfoQ article “Learning: Best Approaches for Your Brain” for an introduction to neuroplasticity — it’s a fascinating topic.

As an Agile trainer (and in my never-ending experience as a student of Agile), I find that the most memorable elements of the typical 2 day Agile workshop are the games and exercises.  Games like the Penny Game, Mr. Happy Face, and the Multitasking Exercise help people take in new and challenging ideas  in a playful context.  I’ve also observed that time spent playing in the workplace, whether participating in a structured game in a training course or informal kibitzing around the team dartboard/foosball table/Carcassonne board, repays the organization in fostering more fruitful and successful working relationships.  When pressed to get a new-to-Agile team ramped up quickly to work on a new endeavour, I’ve sometimes been tempted to replace the fun stuff with exercises designed around the team’s actual work (and some students have suggested this in workshop retrospectives).  My principal reservation is that as soon as you use real work as a basis for trying on a new idea, the focus is firmly placed on a successful outcome rather than exploring and experimenting with the idea and potentially failing in the process.

There are many resources out there if you are interested in finding games to use in the workplace to teach new Agile concepts and build the team’s collaboration muscles.  I put together an interactive session for the June 2010 Agile Ottawa meeting where participants played several great games, including Colloborative Origami, the Chair Game, and the Marshmallow Challenge:

 

Agile Games: Playing to Learn on Prezi

Much fun was had and no lasting damage was done (the Chair Game can get quite, um, lively).  As this was my first Prezi and I couldn’t figure out how to embed multiple links, here are my sources in easy-to-click form:

Since the presentation to Agile Ottawa in June, I’ve learned a few new games at AgileCoachCampCanada and joined the new Agile Games Google Group, which is a fantastic resource.

I’d love to know what your favourite game for teaching is – leave a comment and share your experiences as a teacher/trainer or a student!

← Older Entries
Follow

Get every new post delivered to your Inbox.