Posts Tagged ‘facilitation’

Image result for yes but improv gameRecently my team played a loose version of the “Yes, But” improv game at the beginning of a retrospective (retro) as an icebreaker. I say loose, because we played it in a round (rather than in pairs) and did two rounds. I started each round with the same statement: “I think we should have snacks at Retro” (this is something that often comes up – tongue-in-cheek – during retro conversations).

For round one, the next person in line always had to respond starting with “Yes, but”. At the end of the round (we were seated in a circle), I asked the group to silently pay attention to how they felt and what they experienced during the exercise.

For round two, the next person in line had to respond starting with “Yes, and…”. At the end of the second round I asked some questions about how the team experienced both rounds:

  • How did the first round feel?
  • How did the second round feel?
  • What made a round difficult?
  • What did or could you do to make a round easier?
  • What does this mean for how we respond to each other as a team?

Interestingly (and unexpectedly), my team struggled more with the “Yes, and” round than the “Yes, but” round. To the extent that one team member couldn’t even think of something to say for the “Yes, and” round! At first I was a little stumped, but as we discussed further we realised that:

  1. As a team, we found it more natural to poke holes in ideas rather than add to ideas we didn’t completely agree with.
  2. When we didn’t agree completely with a statement, we got “stuck” and couldn’t think (easily) of a way to add to the statement.

As an example for point 2, above, one person responded to the statement with: “Yes, and we will need to do exercise”. The person following them really struggled to respond (because they don’t like exercise) and didn’t really come up with anything convincing. As a group, after some thought, we eventually realised that “Yes, and it can be optional” would have been a perfectly valid response. However, as a group, it took us a while to get there. So it definitely wasn’t something that came naturally to us.

For me, these were quite cool insights, and probably good for a team to be aware of, particularly when we’re struggling with new problems or trying to find creative solutions.

Have you tried similar games? What did you learn or experience? How has it helped your team?

Advertisements

6hatsThis is my take on using “Six Thinking Hats” to reflect on a period of time. You could use a light version for a retro – or the full version to review something longer like the stage of a project or a release. It’s usually most effective after some milestone event and where the learnings can be applied going forward. There is still value in doing it at the end of a project, but what you get out of it for future teams may not be as valuable as you won’t always know what will be applicable.

Preparation

In order to save time in the session, you do need to do a fair bit of preparation. Try and collect as many facts about the time period as you possibly can before the session. Facts are anything backed by data and some common “facts” one might include are:
– Team changes (people joining/leaving)
– Events (e.g. release dates)
– Sprint information (velocity; commitment; actuals; sprint goal; etc.)
– Changes in process
– Special workshops or meetings
– Any data provided by metrics

I’ve found the most effective way to use the facts in the session (and the rest of my post assumes you have done this) is to map them onto a really large timeline. I typically use a sequence of flip chart pages that can be laid out so that attendees can literally “walk the line”. I’ve stuck them up on long walls or laid them out on a row of tables and even used the floor where I needed to.

It is also useful (for the reflectors in the team) to send out a description of the hats in advance and ask them to think about each one before the session.

Before you start your workshop, you have to set up the room (also see the tips at the end of this post):

  1. Lay out your timeline
  2. Ensure there is space for people to easily walk along it
  3. Have various stationary points along the timeline with pens and stickies
  4. Don’t forget to have a whiteboard or some other space for grouping the ideas

Materials

Besides your “timeline” of Facts, you will also need:

  • Small pieces of paper that people can write appreciations on
  • Pens
  • Stickies: one colour per hat
  • *Optional* Snacks

For the different hats, I usually use the following colours

  • Facts: N/A (people write directly on the timeline)
  • Instincts: Red
  • Discernment: Blue
  • Positives: Yellow
  • Ideas: Green

Process

The process I follow is largely based on this one and, as they mention, I have found that the order is fairly important.

For an average team, I time-box each section to about 10 minutes. Breaks need to be at least 5 minutes, but could vary depending on the time of the day (e.g. you may need a lunch break). If you are going to use the data in the session to come up with actions and improvements, then your time-box for that part will depend on what technique you plan on using. Obviously these may need to be adjusted based on the size of the group, but as most of the steps are self-paced, one advantage of this workshop is that it works quite well with larger groups.

Round 1: Facts

Have the attendees “walk the line” from the beginning to the end. This is a walk down memory lane and also a chance to fill in any blanks and ensure everyone agrees that the facts are correct. There are no stickies for this step – if people want to add or change anything they do that by writing directly onto the timeline (at the right point in time, of course). Remember to remind everyone that they should only be adding facts.

Round 2: Instincts

“Gut Feel”

Hand out your “instinct” stickies. Remind every one of the definition of an “instinct”. I sometimes skip this round because people struggle to differentiate between “instincts” and “positives/negatives”.

Appreciations and Break

Give everyone a chance to write appreciations (these will be shared later – either at the end of the session or afterwards). It’s also a good point to have a short break.

Round 3: Discernment

“Devil’s Advocate”

Make sure you’ve collected the “instinct” stickies and that the next colour of stickies is available. Remind everyone what the definition of “discernment” is. Everyone repeats their walk of the timeline, this time adding stickies to the timeline for things that didn’t go well or were disappointments.

Cool off

Have another break (in case things got emotional). Have people write more appreciations.

Round 4: Positives

“Keep doing this”

This is the last walk of the timeline. Again, remind people of the definition of “positives” and ensure there are only “positive” stickies lying around for people to use. They walk the timeline one final time and add stickies for things that went well.

Lastly: Ideas

“If I did it again”

There are various ways to capture and categorise ideas. The intention of this round is that attendees use the timeline to stimulate their thinking of how they could have done things better. Or how they would do things differently if they had to do it again. This is  sometimes also described as “green fields” thinking.

And then (now or later)…

If you were using this technique for a retrospective, you would ideally get actions from the information as part of your session. If the session was to reflect on a project, perhaps the data would be grouped into things like “Good ways to kick off” and shared with other teams. I’m quite a fan of the quadrant method of grouping similar stickies to find topics to address (see photos below for examples from a retrospective I did). What you do next all depends on the ultimate purpose of your session.

quadrants

Tips

  • Only let the attendees have access to the writing materials relevant for the round i.e. gather up the stickies from the previous round and “change colours” for the next round.
  • Have a number of “stationary points” – so that people can grab stickies and pens as soon as they have a thought.
  • Related to the above, have an excess of stationary and pens so people don’t have to wait for each other.
  • When preparing your timeline, try use pictures/symbols/colours to create visual patterns and cues for repeat facts e.g. document your sprint information in the same colour and layout for every sprint on the timeline or have a bug symbol where you have added statistics around bugs.
  • Don’t forget to share the appreciations! Especially if you’ve decided not to do so in the session.

I have applied this technique a couple of times and used the output for various things:

  1. We’ve used it to gather data for a team which was unfortunately not very transparent and then used that data to paint a “real picture” for external stakeholders.
  2. We’ve used it in retrospectives to identify improvements to team / process / products.
  3. We’ve used it at the end of a project to create guidelines and lessons learned for future projects and teams.

timeline

Have you used this technique before? What worked or did not work for you? Where might this approach be useful?

download In my opinion, one way to make a team coach feel really useless, is distribute their team across multiple locations where it’s really hard to observe their interactions with one another. For me, a lot of my “obvious” work and channels disappeared when that happened and it’s taken me a while to find alternative ways to provide the insights and support that my team needs. I also had to take a step back and acknowledge that when working distributed, certain elements of effective co-located collaboration no longer matter or have negligible impact on team greatness, whereas new elements turn out to be important levers. The trick, it turns out, is to identify what exactly those are. And I suspect, as always, that they will be different for each team.

For example, the daily stand-up or Scrum. A time for the team to sync up and share what happened the day before so that they can plan and adjust for the day to come. An opportunity to celebrate achievements and adjust for disappointments. A good time to interact and build some team rapport. The standard method is everyone stands up (to help maintain focus and brevity) around a task board (for visibility) and speaks to what they achieved yesterday (speaking and moving their tasks to show progress and create psychological ownership) and what they hope to achieve today that will help the team achieve their sprint goal. The Scrum Master and Product Owner observe – and perhaps facilitate – and ask questions where blockers might be hiding in what the team has to say. And the outcome is everyone on the team walks away with a plan for how they will contribute to the team’s success today – and a commitment to each other that they will do their utmost to complete what they have agreed to do for the day.

There are some parallels when we are working distributed – the task board, for example. There are some practices that are just impractical – like standing up. And there are others that may detract more than they add (for example, in our case, it seems less confusing to have one “driver” for the session than to pass control during the stand-up). Sometimes the limitations are tool-related. Sometimes it’s just the nature of working as a distributed team.

So what changes have I tried when facilitating a distributed stand-up? So far, these ones seem to be working:

  1. I try to watch all of the faces. We use Zoom and there is a setting where you can view all of the attendees on a single screen. Whenever we have a distributed meeting – not only stand-up – I spend most of my time and attention watching the faces of the attendees. It’s a good way to notice how people are responding to the session and give clues as to when people are tired (my team can’t do distributed for much longer than 45 minutes), or confused, or distracted, or are trying to ask a question.
  2. I make a note of who has spoken or been “spoken for” in terms of the plan for the day. Basically I listen out for what each person or pair is doing today and at the end of the stand-up, I explicitly ask individuals to share where I haven’t managed to tick them off on my list of names. Note, this is less about everyone having a chance to speak, and more to ensure everyone has made visible to the team what they plan to do for the day. I’ve noticed it’s really hard for my team to keep track of this themselves in a distributed stand-up.
  3. I try to notice if people are trying to say something and find ways to ensure that they get a chance to speak without speaking over the person who is currently speaking. Sometimes this may mean providing an order for people to speak in (you then you then you) if a group happens to accidentally speak over each other.
  4. In my opinion, certain on-line tools (like a digital task board) may satisfy the superficial purpose of the physical tool (e.g. visible stories and tasks for the team to talk to), but not necessarily the deeper purpose (e.g. the psychological ownership that comes with writing and moving a physical sticky). So I’m continuously researching and experimenting with new ways to achieve these outcomes within the context of a distributed team.

For me, the following facilitation activities are still valuable when facilitating  a distributed stand-up

  1. When necessary, introducing the session to re-confirm the purpose and outcomes – especially if there are newer team members or things have started to go a little off-track
  2. Listening out for impediment words
  3. Using open-ended questions to help the team develop insights or notice information

One thing I have noticed, is paying attention in a distributed session is REALLY exhausting. It is also very difficult to split your attention between people “watching” and understanding the content. In my case, I have decided to prioritise the former over the latter, which sometimes leads to other interesting side-effects. On the upside, I’ve become great at asking “stupid questions” 😉

What have your experiences been with distributed stand-ups? What were the challenges? What were the opportunities?

I am currently working with a distributed team and we use JIRA for our sprint task board. We use it in our daily scrum (I can’t call it a stand-up) via Zoom. Over time, I’ve noticed that there are some things that come “for free” with a physical board, but are hidden or not as obviously visible on a digital board (at least not in JIRA). We have found workarounds for some and not for others and, perhaps, depending on the team, not having some of this information “in your face” might be OK. However, I thought I’d make a list of things to look out for if you happen to be using a digital rather than physical board for your team. Also this blog is all about learning 🙂

Please note, I’m only basing my observations on JIRA for this blog post because that is what we use. I suspect that most digital task boards have similar issues.

1. Who’s doing what?

My teams in the past have used personalised avatars to indicate who’s doing what task(s) for the day. We found this had two related benefits:

  1. You were naturally constrained to the number of avatars you happened to have available to you (although it was still fairly easy to take on more merely by initialing the sticky).
  2. It was very easy to see at a glance where a task had too many people, or where one person seemed to have spread themselves to thin, or where someone hadn’t committed themselves to a task.

When asking the question, “what do you notice about our focus?”, it was easy for the team to notice where they may have over- or under-committed themselves for the day. Or to notice and confirm where they were swarming for the day.

In JIRA, only one person can be assigned to a task. It’s not visually obvious where multiple people are working on a task. Also, because we usually only expand the story we’re currently talking about – and usually our full sprint of stories doesn’t fit into the view if we expand all rows – it’s very hard for the team to see good and bad patterns in how they have allocated themselves to tasks for the day.

2. Where are we stuck?

One of the tools one can use on a physical board when it seems a team is taking a while to get things done, is to start dotting tasks. The idea is that a task gets dotted for every day that it has been in progress and not finished. As the task develops measles, it’s pretty obvious where someone may be blocked or may need help.

JIRA does have the concept of task-dotting, but it’s very hard to see (it’s a light gray) and unfortunately the dots don’t stick around. They disappear as soon as someone moves the task to the next column on the board (so, for example, a task that may have been in progress for two days will suddenly have no dots when it moves to the show me column).

When dots have measles, it’s easier for the team to notice where tasks are dragging on for days and do something about it. You don’t really want tasks that have started to take more than a day to finish.

3. How big is our story?

This is probably (hopefully?) a JIRA funny. When we’re viewing the active sprint and sprint board, the story points aren’t visible. Assuming you use story points, they can be useful in helping the team notice when a story is taking too long – a supplement to the burn-down (see below) and tasks with measles (point 2 above). We have a workaround in that we add the story points to the end of the story title. It would be cool not to have to do this.

4. What’s our progress?

JIRA generates a pretty cool burn-down. But it’s not visible on the sprint task-board (which is the view we use for our Scrum meeting). How you’re doing on your burn-down is quite an important piece of feedback for how to adjust your plan for the day. Our workaround is to publish it on Slack before we meet, but it would still be useful to have it visible for the conversation.

5. What’s our goal?

I love (good) sprint goals. I find they give the team something specific to aim for that still allows for creative ways to respond to minor changes that emerge during the sprint. Goals are also a really useful way to bring the team back to the bigger picture in terms of sprint progress: “Are we on track to achieve our goal?”; “What are you doing today to help the team achieve the goal?”. So we create an awesome team sprint goal and ideally we want to have it front-of-mind when planning our tasks for the day. On a physical board, this is easy: it can be as simple as printing your goal on a piece of paper and sticking it to the board (ideally in colour and with sparkles). On a digital board, one needs to get a little more creative. In our case, we write the goal as a story at the top of the sprint and try remember to refer to it before we start our daily conversation. It seems to be working, but it does blend into all the other sprint work.

6. There are other aggregate data questions that are harder to answer

As Jacques de Vos once said: “If you have to scroll, you can’t see the whole“.

With a physical board, the team can usually notice useful things when answering questions like:

  • What do you notice about our tasks in progress?
  • Where do we seem to have the most focus?
  • What do we notice on the board about stories not started?
  • What do we notice about the state of our overall sprint in terms of stories in progress and not started?

Usually a quick glance at how stickies (whether stories or tasks) are grouped in the various lanes of the task board can provide a lot of insight into how things are going – especially if the distribution pattern is looking different to what the team is used to and/or expects to see. With JIRA, this view isn’t easily available. Expanding all of the rows creates a very busy view which is also not guaranteed to fit without the need to scroll. Collapsing the rows hides the task distribution (which may hide other things) and also the story status is represented by a word rather than the story’s location relative to the board’s columns and other stories.

7. There’s usually a driver

The way we use JIRA, someone screen-shares the taskboard in our Zoom session and that person automatically becomes the ‘driver’. What I’ve noticed about this is:

  • People are less likely to interact with the board during stand-up: they’d rather ask the driver to make updates or create emergent tasks
  • Some people are scared to drive (probably a tool thing – either JIRA and/or Zoom), so never do
  • The driver can get distracted by the mechanics of having the right story expanded, or making changes in JIRA, or whatever – so are not always fully present in the conversation
  • If the driver ends up being someone in a “leadership” position (e.g. a senior developer, the Product Owner), then sometimes they subtly control the decisions the team makes in terms of what they plan to do for the day because they can move things or assign things before the team have finished their discussion
  • All of the above means that the negative aspects of “you do it, you own it” sometimes sneak in…

I shared some of these challenges on the #zacoachclub channel in the Coaching Circles Slack Group and got some useful ideas to try out:

  • Write down in detail what information you really need the board to show so that it becomes your information radiator. Then lose all pre-conceived notions of how a board should look and how your tool sets up its boards. Based on the info you need: what could a board in your digital tool look like?
  • Try to represent the info you need in something other than your tool (i.e. JIRA) – maybe Google Draw or something. Once you have something that works, try implement that in your digital tool.
  • If the problem is too many things on the board, could your sprint/commitment be smaller to fit everything in one view?
  • Create a filter that filters out “old” done items and try to only work from the top story (limit work-in-progress).
  • Shift some of the information elsewhere e.g. Say pairs work on the story – they break down tasks in another place (Trello?) and feed back only relevant info to the greater team on the story which is in JIRA. Feedback to their mini team is much more granular and on another board/tool.

Do you use a digital board on your team? What challenges have you experienced? What did you try?

Scrum-Task-Board

AAEAAQAAAAAAAAPSAAAAJGQ2MTIzYzU1LWM0MjItNDJjZS1iYWM2LWYxZDVmNzJmY2M4ZQ.jpgI may have mentioned it before, but at the beginning of the year I went on wonderful facilitation training which led to some positive work-related changes plus a long list of ideas and possible actions for me to try. Some I haven’t got round to (yet) while others I have been actively working on. Here are some of my thoughts on the latter.

(Side note: the format is the format we were asked to use when making our list – and I quite like it.)

I will use question agendas and review these before and during the session so that there is buy-in and we’re talking about what the group feels we need to talk about

I have been using questions agendas quite actively and have found one additional benefit is that they help formalise my own thinking around outcomes and flows for the sessions, particularly workshops.

One thing I have learned is – when running through the agenda – particularly for longer workshops – don’t just read down the list. Try and tie the parts together (like a story) so that the room gets a sense of the journey we’re taking. Also keep an eye out for nodding heads (a good sign).

So far…

  • I’ve had one session where the team members actually kept each other on track with each step by referring back to where we were in the agenda (I tend to pair the agenda with a task board to show when we’re busy with a topic or done).
  • In another session, the group went off on a technical tangent, and then brought themselves back to review whether they were actually answering the questions they were meant to.
  • In a third session, the group actually added an item to the agenda (admittedly, the item was “we find out what the cake tastes like” 😉 )

I will spend more time thinking about WIIFM so that I can try create excitement for a session

(WIIFM = What’s In It For Me)

I could probably focus a little more on this one, particularly using the information to help make sessions more exciting. Since the training, I’ve tried to be more explicit about ensuring I understand all aspects of a meeting (Purpose, Outcomes & Deliverables, WIIFM, and Roles and Responsibilities), particularly when the session is for someone else. We do tend to spend more time on the Purpose and Outcomes & Deliverables. I could probably still do more here…

I will assume yes and ask the follow-up questions so that the team is involved in the conversation and it’s not all about me

I’ve found this technique so useful that I wrote a blog post about it.

I will be more aware of where I am standing so that I leverage physical location as a chicken

I’ve tried this with mixed feelings about its success with my one team during stand-up (the idea being that if you don’t have work on the board, you stand OUTSIDE the inner circle). It’s been more interesting on the other team because soon after I joined they started doing distributed/remote stand-ups, so physical location is not something one can really experiment with. It certainly is very powerful, and I’m currently part of a coaching program where I’m trying to increase my awareness of how I use my body to communicate, particularly when stressed, so perhaps there’s still something to be explored with this one.


In total, I had about twelve ideas on my list that I wanted to try. As you can see, I’ve only really worked with a couple so far. Probably time to try one or two more and see what I learn 🙂

What have you tried recently to try improve how you facilitate sessions or interact with your teams? How did it go?

top-30-open-ended-questions-570x375I’ve always been aware that open-ended questions are good. They allow someone to answer from their perspective and context rather than being constrained to the limitations imposed by your yes/no options. They also allow someone to challenge an assumption or idea (“How do I look in this dress?”) in a way that is potentially less confrontational (“Does this dress make me look fat?”).

All that said, even after some training in “better questions”, I often find myself regressing back to the good old yes/no in conversations – usually without even being aware of it. That is, until I went on some awesome Agile Facilitation training recently where we learnt a really useful trick:
1. Assume the answer to your question is “yes” (Do we have anything to share with the other teams?)
2. Ask the follow-up question (What will we be sharing with the other teams?)

Ta-da: easy peasy open-ended question! And, if you’re worried about the fact that the answer to your yes/no question may actually be no, if you think about it “no one” or “nothing” are both valid responses to an open-ended question.

I still ask yes/no questions. I am trying very hard not to (especially when facilitating). This trick seems to have helped me become better at self-correcting and gives me an easy way to figure what I can ask instead.

This trick has helped me immensely. Give it a try. Let me know what you discover.

I recently attended the regional Scrum Gathering for 2016 in Cape Town. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions. 

This key-note was done by the famous Jim Benson and actually spilled over into subsequent impromptu session. Jim is a very entertaining speaker and doesn’t pull any punches when it comes to challenging the “accepted best practices” of Agile/Scrum/Kanban.

His talk started with some context: what do we mean by systems and what should we be optimising them for? His opinion: we want purposeful systems – systems that work towards achieving their purpose. Extending from that, we should be optimising systems to achieve that purpose – and nothing else. Processes can be defined as rules of conduct (for people) that optimise a system to achieve its purpose. If we consider processes as rules of conduct, then it makes sense that an imposed process (your process) would enslave me whereas an inherent/organic process (my process) would help me. Also, the inspect and adapt loop becomes the mechanism to continuously adjust our rules of conduct (process) based on the reality in which the system is operating.

Now, before one can optimise for purpose, one needs to understand what the purpose of the system is. Jim suggested some basic questions one should be able to answer:

  • Who is my customer?
  • What problems are we trying to solve?
  • How do we engage professionalism over professionals?
  • How do we work in small batches?

As mentioned, the key-note extended into another session and I don’t recall exactly where in the talk that happened, however at some point we started discussing how, in the past, we worked in social hierarchies (good old organisational charts) whereas now we tend to operate within social networks. One downside of social networks is that they have some communication challenges, particularly between networks. One tool Jim shared with us to help with this was an exercise to create a shared story for a team (who should be operating as a social network).

A shared story is created by the team and consists of four parts:

  1. The vision of the team: Why are we doing what we’re doing?
  2. Expectations of each other: What are my expectations of you? What are your expectations of me?
  3. Boundaries: When does someone need to talk to me about something that they are working on? When do I need to talk to someone else?
  4. Victory: How do we know when we have succeeded? What does victory look like?

The shared story should be regularly updated and revised by the team.

Some other cool snippets/ideas I picked up during the keynote and subsequent continuation:

  • Using a scary scale to help prioritise stories. Teams rank a story as being either a kitten; or a crocodile; or a zombie; or a zombie crocodile (in order of scariness). The idea is that you want to be tackling and learning from the scariest stories first so that you can hopefully make them less scary.
  • When having stakeholders rank work, give them only two options: Do (above the line) and Ignore (below the line).
  • If your team is struggling with poor quality or not-quite-done stories, then inspect and adapt as stories move to done. Ask the question: how do I feel about this finished task/stories? If the person doesn’t feel happy, then unpack what still needs to happen in order to feel happy or comfortable about the story/task. Over time, these things would probably evolve into a more team appropriate definition of done.

What are your thoughts on some of what Jim had to say and share?