Meeting Facilitation

Agile Retrospective with LEGO® StrategicPlay®

Lucky I am, because I attended “StrategicPlay FUNdamentals on LEGO® SERIOUS PLAY™” about 2 years ago. (Read my post on it here.) My company was unbelievable and invested in the “Identity and Landscape Kit” afterwards and I had the chance to do a number of LEGO Serious Play (LSP) Workshops since (HR team, UX team, different Project teams and others). I especially use the “Exploration Bags” for team building and also for retrospectives.

At “Play 4 Agile 2013” every participant got one “Exploration Bag“:

LEGO Exploration Bag #p4a13

So I decided to do a session with those and get feedback on the LEGO retrospective I tried with teams already.

LSP is mostly about Story-Telling, creating metaphors, Constructionism, De-Constructionism. As a facilitator you try to enable “Flow” for the participants. In that state the participant is “fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.” (Wikipedia)

This is a set of activities that could be used in a LEGO retrospective:

  1. Warm-Up
  2. Build a feeling or mood that you experienced in the last iteration.
  3. Build your wish for the next iteration.

The session at “Play 4 Agile” was on Sunday morning, so we actually did a retrospective on the UnConference.
tumblr_miq2oxzy221s6e8gqo1_500

 

What normally happens is that after the third round (“Your wish for the next iteration.”) you have so many stories, themes or topics on the table. You can then simply start a discussion and create an action plan.

If you feel that the team members really liked the retrospective so far, you could finish with this activity: “Give one of the team members a gift and build this.”

I got really good feedback on the session. Thanks!
And I even got the “LEGO Rampensau Badge”. Yes!

 




 

Advertisements
Good Question!, Meeting Facilitation

Retrospective activity: Significance Story

Remind team members in a retrospective of the significance and meaningfulness of their jobs. After some bafflement they could realize again that their jobs are important and do create value.

This Monday I was inspired by the following tweet:

I tried to work with the answer (“Remind them why their jobs are important.”) in a retrospective activity straight ahead and thought it worked quite well.
Like a User Story Form (“As [role] I want [desite] so that [benefit].”) I asked each team member to complete the following empty columns by wiriting post-its:
My work as [role] has [this concrete significance] for [target group, user]. (Significance Story)

Retrospective activity: Significance Story

In the [target group, user]-column you will find several, different post-its. Ask in the next step what the expectations might be that those users have on them as a team. Let them again write their answers on post-its and stick those in a new, empty comlumn.

Finally let the team decide in a discussion which “Top 3” of the user’s expectations they want to measure up to preferentially.

 

2 3

Be surprised about the outcome.
In my case the team wanted to measure up to the exectation of being a team that creates value and that makes a difference. 🙂

Kanban, Meeting Facilitation

A Kanban Team Retrospective Activity

ticket-kanban

Although Kanban does not prescribe retrospectives (nor any other mandatory meeting) all our Kanban teams are doing retrospectives on a regular basis. As a facilitator of a retrospective you should try to create an awareness of why things went well or not so well and let the team discuss issues that hopefully lead to improvement (“Kaizen”). The following approach describes how to review finished tasks or User Stories of the last Kanban cadence and at the same time making the Spectral Analysis Chart (SAC) more vivid (especially if a team is at war with (Kanban) metrics anyway). 🙂

The team I’m working with at the moment agreed on a 2 weeks cadence: Every other Monday we meet for a retrospective to look for improvements. We collect all items from the “Done” column before the retrospective. I write the lead time (in days) on the ticket and order them according to their lead time ascending on a board (or the wall of the conference room).

Spectral-Analysis-Chart-Retrospective-1

Then visualize where the team’s average lead time is.

Spectral-Analysis-Chart-Retrospective-2

Concentrate in the retrospective on the tasks that are above/beyond the average:

– What are the reasons for the high lead time?
– What can we do to prevent that this will happened with future tasks? Can we do something about it?

Point out to the team members that the visualization on the board (or wall) is actually a SAC, only upside down. With this approach the team members create a better understanding of a SAC (as they connect it to “real” tasks) compared to just showing them an generated chart.

Spectral-Analysis-Chart-Retrospective-3

What do you think?

Kanban, Meeting Facilitation, Scrum

“Sexy Not-So-Sexy Tasks” Retrospective Activity

In one of the last retrospectives a team member complained about the “not very sexy” tasks the team had to do. Well, we all know that life is not all beer and skittles. Nevertheless I think, the team member was actually pointing out, that the “sexiness” of tasks can have impact on the general motivation of the team, of course. That’s why I was introducing the “sexy <> not-so-sexy” activity in the last retrospective. (As this idea originated in the team member’s comment I also call it “The Thomas S. Approach”. 🙂 )

sexy-not-so-sexy-tasks-agile-retrospectiveIn general, the team’s job is split in tasks on a support level (approx. 65%) and project tasks on a product development level (rest of their time). The team is working with a Kanban system and is using several Scrum ceremonies (regular retrospectives, review meetings, agile estimation for project tasks etc.).

The “sexy <> not-so-sexy” activity fits perfectly in between the check-in (“Setting the stage”) and “Gather Data” activities and is as easy as this:

1) Prepare a chart that shows a line between “sexy” and “not-so-sexy”.
2) Put all “done” tasks on the table and let the team stick them on the line accoring to the task’s “sexiness”.
3) Discuss (“Any suprises? Any patterns?”)

Why I think this acitivity works:

  • The team is reviewing their finished tasks while sticking it to the flipchart. (Reflection: “Cool, we have done quite a lot.”)
  • The team is re-evaluating the tasks. (Reflection: “Wow. That was a cool task.” or “I really hated that task.”)
  • The PO (Note: The team decided to have their retrospective with the PO.) realizes that different tasks can have different motivation.

Of course, the activity also shows the big gap between doing tasks that have value (“sexy”) and tasks that are simply stupid mechanics (“not-so-sexy”). Team members are aware of that. And it does have impact on the motivation if you are only doing “not-so-sexy” tasks.

As there will always be “not-so-sexy” tasks: Maybe there is a way to morph “not-so-sexy” tasks into “sexy” tasks? Any suggenstions?

UPDATE FEBRUARY 2013
The activity has been refinded after discussing it with one of the team members. He pointed out, that value is more “valuable” than sexiness. As a consequence I added the value dimension to the chart.

Sexy-Value-Added
Sexy & Value-Added Matrix
Books, Scrum, Scrumban, Meeting Facilitation, Good Question!

Check-In Activity for Agile Retrospectives

Fortunately retrospectives are already a standard at our company now. Not only our developers teams, but also our sales team, our team assistents and as of late also our management (surprisingly, the last.. :)) have regular retrospectives. Because it has become standard to have retrospectives there is also the chance of falling into a dull routine, both for the team members and the facilitator (mostly myself). To counteract this dull routine we try to do different activities. I tried the following Check-In activity in the last weeks:

Esther Derby and Diana Larsen suggest in their book “Agile Retrospectives” as a Check-In activity to ask every participant “In one or two words: What are your hopes or wishes for this retrospective”. No post-its, no explanation, just one or two words. This always works great.

This question inspired me to ask participants an even more general question as a Check-In excercise: “Why are we doing retrospectives anyway?” I do this as a kind of fast brainstorming and jot everything down on a flipchart. It is surprising what the participants are coming up with. I heard everything from “I don’t know.” (Oops!) and “Because you told us to.” (Ooooooops!) to “Kaizen. Continuous Improvement.” (Thx.) and “We don’t want to do mistakes a second time.” (!!!)

It is also a good excercise to remind the participants of the principles of the agile manifest, one of them is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” (Dare to ask if everyone knows and understands the Agile Manifesto… and maybe be surprised.)

And, of course, it is a good excercise to jolt the participants from their retrospective routine.

BTW: I recognized only days ago that Esther Derby and Diana Larsen book “Agile Retrospectives: Making Good Teams Great” is legally available also as eBook! Buy it!

Good Question!, Meeting Facilitation

How to Deal with Results from an Agile Retrospective?

Have you ever heard a team complaining about results of a retrospective not being realized? I have. And it’s important to change something immediately after hearing it.
Realizing the agreed improvments from the retrospective is one of the agile principles of the Agile Manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (http://agilemanifesto.org/principles.html)
So if you are earnestly doing an agile “Inspect & Adapt” and do not realize the agreed improvements of a retrospective, you are missing the whole point and are doing a simple “Inspect”.

The answers to the following questions could help to make sure improvements are realized:

  • Who is responsible to realize the improvement?
  • How can you be sure that the improvements are not forgotten?
  • How are your improvements logged?

Who is responsible to realize the improvement?
Always agree in the retrospective who will be responsible for putting the improvement into effect. This can one or two persons. Write their names next to the agreed improvement. Do not assign the responsibility to the whole team as nobody will feel responsible then.
Problems that the team can’t solve themselves are impediment and  it’s then the Scrum Master’s job to push it up to the management: fast and direct. And it’s the Scrum Master’s job to get on the management’s nerves until the impediment is solved.


visualize improvements from retrospective
How can you be sure that the improvements are not forgotten?
Visualize the results of the retrospective. What seems to be working very well with us is to put a copy of the agreed improvements on the team’s board: Everyone sees it everyday at the Daily Stand-Up. Alternatively: Improvements turn to User Stories that are done within the next (!) sprint. Here it’s the Scum Master’s job to make sure this happens.

How are your improvements logged?
With “logged” I mean the structure of your agreed improvement in the retrospective:
1) Write whole sentences and not bullet points. This may take a little longer, but you (and everyone else) will understand them also after a few days.

2) As mentioned: Assign one or two responsible persons for the improvement.

3) Agree on a deadline when the improvement should be put into effect (or at least agree on a date when the team gets feedback on the status of the improvement)

Related post:
3 Retrospectives in 2 Days

Agile Coaching, Meeting Facilitation

Agile Team Retrospective Activities: Starfish & Team Radar

Variety in retrospective activities are definitely necessary. The more retrospectives I do, the more I’m getting tired of using the same method over and over again. And hey, this will most probably bore the teams I work with as well. Therefore it’s good to challenge the team AND you with new retrospective techniques. In the last weeks I tried out Starfish and Team Radar in retrospectives.

Starfish
Starfish is a fantastic activity to get your team to re-think the basic questions:
What went well in the last iteration? How can we do better?

starfish retrospective

Starfish refines those two questions and gets more detailed information from the participant instead of just a binary view. If you know retrospectives the different categories of the Starfish are self-explanatory, for everyone else I recommend the post from Pat Kua from 2006.

You can either let the team write post-its for every category one after the other or let the team handle all categories at once.
After the team has gathered the data you can start right away with some clustering or go straight to agreed, detailed improvements for the next wees by exploiting categories: stop, start or less.

Team Radar
Team Radar is powerful if you have a communicative team. It’s not so good if team members prefer writing post-its to talking (if you know hwat I mean… 😉 ).
You can pick 4 to 5 subjects that either you or the team think are worth discussing in detail. Those subjects can be team values like Respect, Feedback or Communication. Alternatively you can also choose reoccuring subjects from former retrospectives like quality of code skills, effectivity of the team etc. If you are not 100% sure what subjects to choose, only suggest subjects and then let the team decide.

team radar retrospective
This is how you can work with Team Radar:

  1. Explain to the team what you think that every subject means and then let the team discuss/agree on that
  2. For every subject let everyone dot/rate on a scale from 0 to 10 where she/he thinks the team stands concerning this subject
  3. Discuss each subject in detail and agree on concrete improvements:
    • Be aware if dots are far away from each other on one subject. This is most probably because of misunderstandings within the team.
    • As I mentioned before: This activity is for communicative teams. Take care that everyone gets the same time limit for their opinion.

Team Radar is described in detail in still the best book on Agile Retrospective Activities: Esther Derby and Diana Larsen “Agile Retrospectives: Making Good Teams Great”.

Nevertheless, with a new team, it is important to start and train the basic chain of a retrospective before starting with alternative activities and risking to overburden the team:
1) Warm-Up: What happened in the last iteration?
2) Prime Directive and basic group rules: Explain why those are important.
3) What went well in the last iteration?
4) How can we do better, how can we improve our process?
5) Is there anything we CAN’T change by ourselves?
6) What in detail will we change until the next retrospective?

Related Post:
3 retrospectives in 2 Days