Facilitation Toolkit: Activities for Opening

02 Monday Apr 2012

Posted by in Agile, Facilitation, Games, Links, Retrospectives, Scrum

≈ 9 Comments

Tags

This is the second of four posts covering facilitation games for the different phases of meetings: Check In, Opening, Exploring, Closing.

The Opening phase of facilitation is the space in which the group starts to unpack the topic at hand. This is usually the “past” phase – looking at what has led us to this point in time.

It’s surprisingly difficult for us to look back at events that have passed and generate insight and understanding from them. Aside from struggling to remember everything that’s valuable, often there are deeply held beliefs or other organizational messages that sway our view of events until we look at them closely from a unbiased perspective.

The Gathering Data section of the meeting gives us the opportunity to ‘get back to the facts’  of what we’re dealing with, and with the Exploring section, has the most scope for variety, providing a multitude of ways to unpack the status of a team, project or company. And doing this in a group format allows us to combine individual memories to build up a reasonably comprehensive picture of what is happening in the environment.

In Gamestorming, the authors refer to ‘Meaningful Space’ as the use of visual space to sort our experiences, knowledge and feelings into comparative or relative areas. This is particularly valuable both for prodding our memories and clarifying areas of strong agreement, disagreement, and alternate perspectives.

Timelining:

This opening format is a great way to have team members tell their story; the narrative format grabs everyone’s attention and highlights the human side of the sprint / release etc.

  • Activities over time + emotions – A good way to see individual experiences – especially if you include personal events in the timeline. Increases team’s knowledge of each other, as well as what was significant to them in the sprint.
  • Emotions timeline – As above, but start by drawing the emotions timeline, only adding events at major points. Use a large graph with x axis showing the time period, and y axis equal amount positive & negative space, and have each person draw their line in a different colour. Can also be used as a check-in activity.
  • What was my Pace – Same format as the emotions timeline, showing when team members were balanced, cruising or overworked. Good for analysing uneven sprints, disconnected teams. Debrief looks at where people are in sync and where they aren’t, the possible reasons for this, and any other observations.
  • History Map – good for company retrospectives – a timeline showing the detail of events which shaped the company’s direction and growth over time. Fun way to share corporate knowledge and reflect on events which affected the company’s development.

Categorizing:

A nice way to dissect information and prompt the group’s memory is to categorize experiences along a theme. The Learning Matrix is the most well known of these formats, and there are a variety of others below. When I can’t find something that fits, I often make these up. *Tip: Alliteration is an unexpectedly handy tool for maintaining overall cohesion.

  • Liked / Lacked / Learned / Longed For – Clarifies current status and indicates areas of growth that are beginning to develop
  • Components / Characteristics / Challenges / Characters – Product analysis tool, ideally used with a group representing different departments, from product management to development to infrastructure.
  • Confident / Concerns / Challenges / Chocolate (i.e. the ‘sweet spot’) – Use to clarify the current state of a team / product / company etc. (used for a company retrospective and planning sessions)
  • Proud / Sorry / Grateful – For high-trust teams: promotes deep connections. The addition of ‘Grateful’ helps to round out some spiky feelings and acknowledge others’ roles in ‘my’ experience. (adapted from Agile Retrospectives)
  • Helped / Hindered / Hypothesis – Unpack how a method / improvement is working for us – useful for ‘measuring’ improvements (from Agile Retrospectives)
  • We’re Good At / I Worry About / I Wonder About – Variation on the learning matrix, with a bit more focus on team identity
  • Start, Stop, Continue, More of, Less of Wheel – Focus on process / improvements analysis – the subtle distinction between stop / less of and continue / more of invites some interesting discussions

Other shapes:

  • Circles & Soup – What’s happening that is within vs. outside our control; great for identifying actions a team can responsibly take on, especially useful when decisions seem to be out of our hands, or where blaming is present
  • Strengths / Weaknesses / Opportunities Timeline – A visual format that combines an events timeline around the outside of the page (Past) with ‘Strengths’ & ‘Weaknesses’ (Present) and Opportunities that can reliably be completed in the next sprint (Future) all in one. Completed in groups with feedback and debrief of themes.
  • Sailboat (what puts wind in our sails, what gives us direction, what weighs us down) – Creates a sense of identity and direction (combination of Gamestorming’s Speed boat and airplane metaphor in the introduction)

Other visual formats:

  • Draw the Problem – A longer drawing format similar to the Check In activity, which surfaces deep connections
  • Mind mapping: Good technique for generating related information quickly, but avoid the temptation to get hung up on sorting too early – I find it useful to stress quantity over quality and use a tight timebox.
  • Group posters & feedback: Fun collaborative activity for sharing perspectives

Conversation-based opening:

  • Appreciative Inquiry – Interview section of this retro: good for strong teams to find new areas of improvement
  • Locate Strengths (larger groups): Powerful way to get to know team members and discover unknown skills (from Agile Retrospectives)

The aim of the Opening phase is to establish the foundation from which we are building. It’s important not to start drawing conclusions directly from this data, but simply to help the group as a whole to remember as much detail as possible.

Once we have this, we move on to Exploring, where we delve deeper into extending and interpreting the data we’ve gathered.

Most of these activities come from books, blogs or training sessions I’ve been part of; some I’ve created to meet specific needs. Where I can find attributions they are noted; if you see any I’ve missed, or know of links I haven’t found, please let me know in the comments below.

Facilitation Toolkit: Activities for Check In

15 Thursday Mar 2012

Posted by in Agile, Facilitation, Games, Links, Retrospectives, Scrum

≈ 6 Comments

Tags

This is the first of four posts covering facilitation games for the different phases of meetings: Check In, Opening, Exploring, Closing.

The Check In is the initial phase of a meeting, and to a large extent is independent of the content. The purpose of this section is to bring everyone’s focus into the room and establish the collaboration boundaries, so that right from the start we are all clear on what we expect of each other, and what we expect from the session.

For regular sessions like retrospectives with teams who know each other well, I jump straight to the Metaphor section below; for teams that are new to working together, or long facilitation sessions, I try to include all three steps as time allows.

Check In:

These activities signal the general level of attention, acknowledging outside distractions and bringing attention to the current objective.

  1. Fist of Five – Adapted to show how happy / informed / focused I’m feeling right now
  2. ESVP – How committed I am to being here (from Agile Retrospectives)
  3. Form a line – participants stand in a line from left (low) to right (high) in response to a question such as ‘How I rank my level of knowledge’
  4. WIIFM – have participants write their “What’s In It For Me” (What I want to get out of this session) on a stickynote and stick it up on a designated wall space. If time allows, have them discuss this in small groups first. Revisit at the end of the session as part of closing. Defines personal objectives, generates ideas for others, and also gives the facilitator some perspective on the group’s expectations.

Create Safety:

These activities are designed to maximize collaboration. Developing personal connections between participants and setting the boundaries of the meeting help to establish initial trust.

  • Introduction Card – Pair activity: create a card for your pair stating their Name; Role; Interesting Fact; and Superhero Quality, then introduce them to the group. Fun introduction technique, creates bonds & generates laughter (from our Coaching Dojo)
  • Working Agreements – Agreement on how we’ll handle distractions, conflict, tangents etc. either long term as a team or for the current meeting (from Agile Retrospectives)
  • How can we make this (retrospective / session) fail? Round robin format – this is a fun way to surface fears and create awareness of unsupportive activities and attitudes, and agreement on how to avoid them or handle them if they come up.
  • Focus On / Focus Off – Another way to bring awareness to collaborative vs obstructive behaviours (from Agile Retrospectives)
  • Hope for the meeting / sprint etc. – Creates a shared understanding of individual objectives (from Agile Retrospectives)

Check In Metaphor:

Once the conditions of safety have been established, a quick ‘Turn the Head’ activity suffices as a Check In, providing a meaningful transition to the Opening section of the meeting.

It’s ‘disruptive’ as it challenges our thinking by bypassing the jargon we use on a daily basis, to create new associations and insights. Metaphor check-ins can also give a heads-up on underlying themes or tensions, but are quick enough to simply highlight issues without pre-empting a tangential conversation.
These ideas appear in both Gamestorming and Agile Retrospectives.

  • Describe (the sprint / release / team etc.) as a:
    • Fruit, food, drink – rich associations with wide applicability; can surface emotions
    • Car, mode of transport – drive & motivation in the team
    • Colour, sound, other senses – wide applicability; can tend towards the abstract; useful for volatile situations
  • Drawing:

While there is always someone in the room who “can’t draw to save their lives,” I’ve never seen this exercise produce trivial insight. Both metaphor and drawing can create new neural networks that help to situate each participant’s experience; drawing goes further by using a different form of language and connecting different spheres of brain activity. The debrief experience tends to be rich, and contributes to building trust within the group.

… and then sometimes I just ask for any 2 or 3 words, or a highlight and lowlight, that start the discussion. This is particularly useful when I don’t know the group, when emotions are running high, or there have been a variety new experiences.

Most of these activities come from books, blogs or training sessions I’ve been part of; some I’ve created to meet specific needs. Where I can find attributions they are noted; if you see any I’ve missed, or know of links I haven’t found, please let me know in the comments below.

Facilitation Toolkit: Working with Games

14 Wednesday Mar 2012

Posted by in Agile, Facilitation, Games, Retrospectives, Scrum

≈ 4 Comments

Tags

I’m often asked where to find facilitation games and formats for agile teams. Fortunately there’s an increasing amount of information on the web, a number excellent books on the topic and some great training courses available – and since it’s an ever-expanding world, the more you look the more you’ll find.

Over time I’ve assembled a list of favourite collaboration games covering a wide variety of applications, which I’d like to share over the next few blogs. To make sense of them, it helps to understand a little bit about the activities we call Games.

What is a Facilitation Game?

The idea of games being inappropriate or irrelevant in a business context is fast losing ground as we begin to understand the value of collaborative and innovative approaches to problem solving.

Games are designed, interactive experiences in a variety of formats, generally following an ‘Opening – Exploring – Closing’ structure. I distinguish between ‘empirical experience’ games and ‘collaborative’ games, as follows:

  • Empirical experience games are safe-to-fail learning activities that simulate real-world scenarios from which we gain deep experiential knowledge quickly, as opposed to theoretical knowledge. They have a powerful learning value which helps us act more consciously when we’re in similar situations in the real world – but many organizations still distrust their un-businesslike characteristics.
  • Collaborative activities are called ‘games’ because they follow the game format of open – explore – close; the activities are interactive, with ‘set moves’ directed towards an overall goal, and an outcome which is determined as a result of the collaboration.

Collaborative games tend to be easier to adopt in meeting agenda as they readily support business objectives, and while the level of collaboration may feel unusual at first, the quality of the interaction compared with traditional meetings quickly establishes their value.

This is where the focus of the next few posts will be.

What’s in an agenda?

We can apply the gaming ‘open – explore – close’ structure to designing the facilitation agenda as well. There are different kinds of activities for each part of the meeting, and following this format creates a balanced pace through the session to keep participants focused and engaged.

For retrospectives I generally combine this structure with activities focusing on past, present and future, as described by Esther Derby and Diana Larson in Agile Retrospectives, and a small addition of ‘disruption’ I encountered in Loop Organisational Consulting’s Team Leadership Skills course. This gives us:

Check In > Turn The Head > Gather Data > Insights > Goals & Actions > Close
which is roughly:
Open > Refocus > Past > Present > Future > Close

‘Turn The Head’ highlights the value of the disruptive element to adjust our viewpoint so that we can see our world through different lenses.

I also use this overall structure for other sessions, with a greater emphasis on the specific area of focus, as well as icebreakers or empirical experience games as appropriate.

Sharing the Agenda

I’ve learnt to start meetings with a discussion of the agenda and how long we’ll spend on each section, and keep this visible for the duration of the meeting. Initially I resisted the idea, with worries like “what if it goes wrong; what if people don’t like it, and I want to change direction?” but I’ve been amazed at how much collaboration improves when participants can see the overall context of each activity … and I’ve also learnt that changing direction with the full awareness of the group is far more effective than rigidly holding onto the plan or appearing unprepared when circumstances change.

Developing a wide and deep toolkit gives us the flexibility we need as facilitators to respond to our changing circumstances. Each of us builds up a unique set that works for our environment, and which also evolves with time.

In the next few blogs I’ll be sharing some of the tools I’ve enjoyed using for each of the major sections of a facilitation:

* Links will become active as the posts are published.

What is Agile Facilitation?

05 Monday Mar 2012

Posted by in Agile, Facilitation, Retrospectives, Scrum

≈ 4 Comments

One of the more distinctive differences between agile software development and its traditional counterparts is the wide-spread adoption of group facilitation techniques by agile practitioners.

This is largely due to the high degree of collaboration demanded by agile methods: we have to learn effective ways of sharing information and making decisions together – so much so that it’s become one of the Scrum Master’s major responsibilities.

I see facilitation as a foundation support for self-organization, and critical to new management practices: the fundamental understanding that an informed collaborative approach to problem solving involving those closest to the work will consistently yield better results than a plan designed by a single expert.

So what is facilitation?
As a field, facilitation is hard to define. Wikipedia and Google give us a view of the wide range of contexts in which the term facilitation is used, from business to neuroscience.

These give us a good overview, but I worry about definitions that tell us facilitation is ‘making things easier’ (from the root ‘facile’). Because while facilitation is a significant aid to collaboration, as experience tells us, collaboration is not easy. Good facilitation provides ways to address this and make it more comfortable in the long run, but it’s neither a magical panacea for problem resolution nor a superficial fix we can use to avoid conflict.

To clarify my understanding of the field, this is my take on facilitation (I won’t claim it’s the most elegantly worded):

Facilitation is the “art” (an informed blend of techniques and insight) of aiding groups to collaboratively interpret their (project) context and identify the most valuable path forward.

From a continuous improvement perspective, we know that having clear and attainable goals set and agreed on by those doing the work is a fundamental factor in both motivation and team success. Coupled with the short cycles of Scrum, this provides an excellent mechanism for teams to improve incrementally while responding to changing conditions.

But we also know from complexity theory that there are situations when it’s just not possible to see up front what the desired outcome might be, and setting predefined goals or actions can be meaningless, or even damaging if they lead us in the wrong direction. In situations where work emerges as we go along, a facilitator needs to be able to help the team clarify the boundaries in which exploration can take place, and understand how to navigate these waters.

In either circumstance, the facilitator ensures that teams reflect regularly on the process, either to clarify whether the activities undertaken are leading them to the intended outcome; or to ensure that they are conscious of the steps they’re taking, the results generated and the kinds of patterns emerging – and what these indicate about next steps (Cynefin‘s Probe – Sense – Respond model). The detail of what and how to proceed is a product of the facilitation itself, not a predetermined formula.

From this perspective, agile facilitation is about reaching a new level of understanding; surfacing valuable insight that will get the group to their next stage – whether it’s a vision, the next sprint, or a new team dynamic.

Outside of continuous improvement, the Scrum Master facilitation functions include planning well for meetings, using time-boxes effectively, and ensuring good communication flow both within the team and across organizational boundaries. At a process level, it’s ensuring that coming work is appropriately groomed and that everyone is aware of constraints so that the right expectations are set.

Here the facilitator function is making sure that the time utilized and the effort expended are appropriate and valuable, and that there is as little as possible waste in both meetings and normal day-to-day activities.

And this is part of the ‘art’ of facilitation: how do we know what is wasteful and what beneficial? What level of noise is required for us to have sufficiently investigated all areas?

In different contexts, discussing a tangent or exploring an alternate technology could be beneficial, harmful, or irrelevant – but if it’s important enough to come up, we need to ensure that we explore sufficiently for the first two possibilities, and avoid the last. Again, this call must be guided by group input. Facilitation involves making sure everyone involved with a decision has a voice, is clear on both the constraints and possibilities, and is able to proceed in an informed manner.

It’s well noted that the facilitator does not provide answers, and as a rule does not contribute to the content. What they create is the most conducive environment for each individual to contribute their knowledge and clarify their concerns, such that the group is to be able to choose the best route for their situation, as a self-organized team responding to business needs.

And do to this well, we need a wide and deep ‘toolbox’ of techniques, from idea sharing to consensus activities, which allow us to respond in a contextually relevant way to the range of challenges with which software development so regularly furnishes its practitioners.

What I’m learning about coaching from learning to surf

26 Sunday Feb 2012

Posted by in Agile, Facilitation

≈ Leave a comment

I’m always eager to learn new things, as I find it a useful way to maintain a ‘beginner mind’ approach to life. Usually my focus is in the agile and/or creative area, but earlier this year I had an opportunity to go for a surf lesson at a discounted rate, and on a whim I booked the lesson. Unsurprisingly, while I managed to stand up on the (large, beginners) surf board, I didn’t really feel a passion for it.

But after a while it dawned on me there was another reason for learning something completely out of my comfort zone: agile methods are by definition about continuous improvement, and therefore about continuous learning. By slowing down and paying close attention to my own learning experience, I could try to apply what I notice to agile coaching.

I’ve now had four lessons, three in a dedicated “group”, and to date all with different coaches. This is what I have so far:

  1. Fear of failing manifests as doubts and naysaying – what we know as ‘resistance’. This has been present at every lesson (“maybe I can skip this one, I’m tired & have a lot of work to do” etc.) and I wonder if it ever truly goes away. But ignoring that voice is immensely satisfying – I’m beginning to think ‘ignoring’ is the key to overcoming resistance, rather than motivation or rationalization.
  2. For the most part my coaches don’t tell me what to do, aside from basic info before we get into the water. They just help me get going and let me at it, knowing each person will find their own way.
  3. There’s a lot more to learning a new skill than just the main objective – it’s familiarising yourself with a whole new environment (language, orientation, techniques, constraints).
  4. My coaches don’t judge when I fail, or tell me what I did wrong. Sometimes they offer other information – ‘try this’, ‘what you should know about the water (environment) is that’ – but as a beginner there is so much sensory overload that it’s hard enough to make sense of what you are doing without someone telling you what you’re doing wrong.
  5. Once I’ve made a mistake often enough to realise it’s a pattern, I know what to ask. Then I can focus on learning how to do it right. So I’m really committed to that improvement, and I do so at my own pace. Yes, some of my questions are dumb, and sometimes I do feel dumb. But I still own gaining that piece of knowledge.
  6. When I do follow a suggestion rather than work it out myself, I’m never quite sure what I was doing before. But then I usually go backwards again, and find out the hard way anyway.
  7. A small word of praise goes a long way – both from peers and from the coach.
  8. It’s important to get out of early comfort zones quickly – as a beginner, you’re likely to be working within unrealistic ‘safety-harness’ boundaries that allow you to conquer the basics. Once you’ve done that, the safety net quickly becomes a limitation, and staying in that zone keeps you struggling with the wrong things. So you need to be able to stabilise, then move swiftly to more challenging ground.
  9. Different coaches know different things – it’s great to be exposed to a variety of perspectives.
  10. The community of experts are a lot more forgiving of an outsider once you’ve given it a shot, and come back again for more.
  11. No matter what your skill level, a good dose of humility and a recognition of others’ achievements is what engenders friendship and encouragement – and these are what create a sense of “team” out of a group of individuals.
  12. Learning something new redefines how you see yourself and your skill sets. A new skill might extend your current grouping to include the new one (i.e. ‘more sport skills’), or open up whole new avenues (‘now I’ve done this, perhaps I could also do that’). I think both of these are things to celebrate with team members as they happen.

I’m hoping that over time these and other observations will help me to be more attuned to the agile teams I work with, and to address similar issues as they arise with a deeper insight into what’s going on.

So why is this on a facilitation blog? Because a lot of agile facilitation happens outside of the time-boxed and clearly defined meetings: as a Scrum Master skill, coaching is both helping people adapt to agile methods and aiding the process of team transformation. To do so with as little “telling” and as much understanding as possible is one of the definitive aims of facilitation.

Appreciative Inquiry: Facilitation Lessons from an On-the-Spot Retrospective

27 Friday Jan 2012

Posted by in Agile, Facilitation, Retrospectives, Scrum

≈ 4 Comments

I’ve been reading recently about teams who only focus on positive retrospectives – never asking “what did we do wrong”, and focusing instead on “what can we do better” – with great results. While the idea makes sense to me, I wasn’t sure how I could introduce the concept to my team.

But today the team decided to bring the retrospective forward by half a day, to this afternoon instead of tomorrow morning.* And being a “last responsible moment” kind of planner, as well as a “Don’t prepare, just show up” kind of improvisor when the situation dictates, I headed off to the shops to grab snacks & ponder which format would be best for the team. They’re doing pretty well, and the sprint review was a success, but nothing in particular sprang to mind on the walk.

Armed with my prompt-list of retrospective activities and a vaguely related transcription of activity formats, I headed to the room & got going, praying that inspiration would strike. It didn’t – or at least, it didn’t seem to.

Fortunately I follow a pretty standard format which the team knows well, so we got started with the sprint metaphor followed by review of the sprint artifacts. By which time I was sure inspiration would strike. Still no. Except for the nagging idea to ‘put it to the team’.

So when we got to the “Gather Data” section of the retrospective, I turned to my list of standard activities, and read them to the team, saying “this is the list I usually work from, let’s see what makes sense for us today”.

“Try appreciative inquiry

Instead of looking at where to improve, look at what’s working well and how you can build on that. Use short, pair interviews to explore questions such as, “When were you at your best on our last sprint?” “Who else was involved?” and “What conditions were present?” After the interviews, put the pairs together in groups of four or six (two pairs or three pairs together) to find common themes.“

From Esther Derby’s blog 7 Ways to Revitalize Your Sprint

I explained each one as I went along, and watched the team weigh up each option. Top of the list was Esther Derby’s Appreciative Enquiry (see right) – a technique I hadn’t used with this team before.

Another format that seemed valid to me was “We’re Good At / Worry About / Wonder About” since there are changes afoot, but one of the members pointed out we’d done that about three sprints ago – I love that they respect variety! – and asked about Appreciative Enquiry. This team is pretty logic-focused and also contains quite a skeptic, so I was surprised when they all agreed – essentially to work in pairs, ask each other nice questions, and feed back on their pair’s behalf.

I’m pretty sure that if I’d planned this activity without their input, it would have bombed. But because they’d chosen it, everyone got stuck into the exercise. There was a brief moment as they wondered what they’d got themselves in to, with a bit of ‘do we have to answer all of the questions’ but since the questions are simple and follow each other well, it wasn’t much of an objection. And what was really interesting was how consistent the answers to the questions were – with variety indicative of personality rather than differences of opinion. This really emphasised how well they work as a unit.

To take the leap of making all this ‘fluffy stuff’ actionable, I had the team answer the question “How can we apply this knowledge to future sprints?” in round-robin format. From this we generated some very concrete goals and actions – concrete enough for the team to feel comfortable committing to two – a change in work patterns (limit WIP) and a specific action to change their environment setup to reduce external dependencies.

So my facilitation lessons from Just Showing Up today were:

1. It’s okay to just show up – when everyone knows how to make an informed decision
2. Fluffy stuff can go down well with an outcomes-focused team – as long as we work towards clear and concrete goals
But most importantly:
3. As always, the best way to make sure everyone’s engaged in the process is to include them in the decision making.

I think the team needs to have a relatively good understanding of the retrospective process for this to work (“Ha” in the Shu-Ha-Ri scale), but it’s magic to see.

* We usually have the retro straight after review, but the post-holiday period for work and school had meant some parent-focused rescheduling.

Activities for Retrospectives – Collected Links & Lists

08 Sunday Jan 2012

Posted by in Agile, Facilitation, Games, Links, Retrospectives, Scrum

≈ 4 Comments

Once we move beyond the normal “What Worked Well / What Didn’t / What Can We Improve” retrospectives, there’s a whole world of interesting activities to engage and focus participants – and it’s growing fast :D

These sites provide a good starting point:

Retrospective Wiki: Retrospective Plans
This section of the wiki includes quite a few complete retrospective plans such as 6 Thinking Hats; Everyday Retrospective; ‘Start / Stop / Continue / More of / Less of’ Wheel. Even if you don’t use the plans in their entirety, they give a good idea of how to structure a retrospective, from activities to timing. I like this whole site – it’s worth looking through.

Extract from Agile Retrospectives – Making Good Teams Great
This PDF extract of Esther Derby and Diana Larson’s classic, kindly provided by the publishers The Pragmatic Bookshelf, includes the following games: Timeline, Triple Nickels, Team Radar, Force Field Analysis, Fishbone.

Partnerships and Possibilities
Diana Larsen and Sharon Buckmaster’s blog, containing a variety of agile writings. Filter on Retrospectives for quite a long list of activities – either blogged or linked to other blogs. I particularly like Circles and Soup, as well as the Appreciative Retrospective – I’ve used both ;-)

vinylbaustein
Thorsten O. Kalnin invents really interesting creative retrospectives. Try Agile Speed Dating, Agile Olympics (Golf, Tennis and Bowling have been added so far), or the irresistible StrategicPlay® simulations using Lego.

Gamestorming Games Wiki
This site is has a variety of facilitation games, and is more of a general facilitation resource, but I’ve used some activities in retrospectives to great effect. It’s a particularly useful site if you’re looking for ‘out of the box’ ideas.
I strongly recommend purchasing the Gamestorming book – it’s a fabulous resource to have on hand to flip through when you’re looking for inspiration.

Other links:

This conversation on the LinkedIn Certified ScrumMasters Group: Creative ways of conducting retrospectives has some interesting ideas from contributors.

Why I Care About Retrospectives

08 Sunday Jan 2012

Posted by in Agile, Facilitation, Retrospectives, Scrum

≈ Leave a comment

As a Scrum Master, I care about all the Scrum “events” – Sprint Planning, Daily Standups, Sprint Demo / Review and of course, the Retrospective. Do I care more about the retrospective? I’m not sure – but I certainly put a lot of effort into each one.

Partly that’s because I think it’s really important to make the most out of every meeting, and since each sprint is different, I try to make sure that the retro fits the overall needs of the team. And partly it’s because in my experience retrospecting has been a sorely neglected part of project management (in all industries, not just software) so there’s still a lot to learn about it. But since it’s arguably the most valuable tool we have for continuous improvement – to look back, identify strengths, clarify areas for improvement, and set plans in place to do so – I figure it’s worth putting extra energy in.

The retrospective is at the core of the Agile principle “Inspect and Adapt”. (Marc Bless unpacks this principle very nicely).  It’s particularly valuable in complex environments, where there’s a high degree of uncertainty and teams must be able to adapt to changing information and changing needs – which happens to be the realm of most software projects.

As an ex-Project Manager, I’ve been on projects where everyone knew we were veering off-course, with a collective feeling of “why doesn’t anyone do anything about this” hanging in the air – but we were always too late or under too much pressure by that time to do anything other than hold our breath and hope we can avoid disaster.

The ability to pause regularly to assess our overall progress, identify corrective action and implement it, seemed like an impossible luxury – or the final straw, when in extreme cases we had to go cap-in-hand to the client and explain why we couldn’t meet the time / scope / budget commitments. And while necessity may be the mother of invention, in these situations very few team members have much creative energy left.

Of course, when we had delivered a project on time & in budget (it’s a rare but not entirely mythical thing), we were immediately put under pressure to deliver more in the next project, with little opportunity to review what made this project different and be able to harvest that learning.

As I moved into an Agile environment, the focus of my retrospectives naturally shifted from projects to teams, and to me this is where the most value – and greatest challenge – lies.

Developing strong teams is one of the greatest assets a company can invest in. When a team is collaborating openly, sharing collective knowledge and engaging in constructive disagreement, it becomes increasingly easy to identify and eliminate blockages, smoothing the ability to complete work, and move on to the next challenge in a continuously improving – and highly functioning – team.

A lofty goal, and frequently considered the “snake-oil” of agile salesmen, this can only really be achieved when teams become dedicated to owning their improvements in an organization that supports and participates in the changes identified, over a sustained period of time.

At their heart, I see regular retrospectives as a key tool for team transformation, which help teams move from being a fragmented group of individuals reacting to corporate pressure, to trusting, self-organizing, motivated and directed teams, contributing to corporate discussions.

Yes, I have lofty ideals. Fortunately Agile provides me with a lot of practical ways to implement them :D

All About Retrospectives – Collected Links & Lists

27 Tuesday Dec 2011

Posted by in Agile, Links, Retrospectives, Scrum

≈ Leave a comment

The sites below contain a wealth of information about what agile retrospectives are, how to conduct them, and how they fit into the broader agile picture.

If you’re new to retrospectives, take your time browsing sites that look interesting to you, from basic to advanced. If you’ve been doing this for a while you’re likely to be familiar with a few of the sites; I hope you find some new gems or interesting combinations that spark new ideas for you… would love to hear if you do!

Refactoring your Development Process with Retrospectives
A thorough introduction by Rachel Davies on why retrospectives are important for teams. The article covers learning from experience, the structure of a retrospective, and how to do them well.

Insights You Can Use
Esther Derby’s blog, which is aptly named :-) Filter on Retrospectives for insights specific to retrospectives, how they work, why they fail, and ways to make them stick. For reading and re-reading.

Resources on Retrospectives
Comprehensive links list covering the basics of conducting good retrospectives – what to do and what not to do – as well as interesting variations and experience-based discussions.

Agile Advice – Recommended Materials
A great set of links to all things agile, with retrospective and facilitation concerns featuring under headings like Team Building, Corporate Culture and Self Organizing Teams. Worth trawling.

Agile/Scrum Retrospectives – Tips and Tricks
InfoQ’s useful set of collected tips and techniques for conducting retrospectives – and like many agile blogs, the content continues in the comments section ;-)

The Retrospect Prime Directive

27 Tuesday Dec 2011

Posted by in Agile, Retrospectives, Scrum

≈ Leave a comment

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

This quote is what we know as the Retrospective Prime Directive. It comes from Norman L. Kerth’s “Project Retrospectives: A Handbook for Team Reviews” – one of the earliest books specifically on the subject of Retrospectives, written in 2001.*

I hold the Prime Directive to be true in every situation, even when the product is below standard, or it seems that team members are not contributing their best. I find it useful to remember that it’s the best given the resources available and the situation at hand. Retrospectives are the tool we have for surfacing underlying issues that stop us from producing the best of all possible work – from technical to budgetary to interpersonal.

By holding this principle to be true in all situations we get away from blaming and move quickly to searching for the source of problems. It’s also is a significant factor in building trust, and it’s only in a truly trustful environment (safe space) that team members are able to get to the real issues affecting project success – or indeed, feel comfortable sharing their ‘secrets of success’ to enable everyone else to achieve great results.

* Norm Kerth is often referred to as the Father of Retrospectives – his site is at www.retrospectives.com