Meeting Facilitation, Training

Instant Feedback Meeting Artefacts

What are Instant Feedback Meeting Artefacts (IFMAs)? 
IFMAs are artefacts that help meetings to get instant feedback in meetings from participants.

Why would you use IFMAs?
All participants should feel responsible for a successful and meaningful meeting; it is not the sole responsibility of the meeting moderator or facilitator. Most reasons why meetings do not produce successful and meaningful results are either endless discussions, lost focus or dwindling concentration.
IFMAs can help to address those causes in an entertaining and easy way by participants themselves.

How to use IFMAs?
IFMAs are introduced at the beginning of the meeting or the workshops. Each IFMA has a name and a meaning. Whenever a participant feels the urge to use the IFMA she grabs it, holds it up high and shouts the name of the IFMA.

Example, please…
Here we go! I experimented with different IFMAs in the last years. Those are my favorites:

Instant I need a break clown Feedback Meeting Artefacts

(I need a) Break-Clown

Instant Focus-Police Feedback Meeting Artefacts

(I need more) Focus-Police

Instant I'm lost - Feedback Meeting Artefacts

(I am) Lost-Professor (please rewind that conversation)

It is important to introduce the IFMAs at the beginning of the meeting. It will raise the willingness of the participants to ask for breaks, focus and orientation and thus help your meeting or workshop to be more successful. You will most probably earn some smiles as well, when holding up those Playmobil® figures when explaining their meaning.

Of course, you don’t have to use Playmobil® (although those are fun). LEGO® might be a bit small here, but a buzzer (on a mobile phone application) or a hotel bell or simply some colored cards will work as well.

Instant Feedback Meeting Artefacts

Advertisements
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?

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

Kanban, Scrumban

Visualizing Kanban Lead Time

Measuring the lead time is one of the three core means of Kanban (next to Workflow visualization and WIP limitation).  But whereas Workflow visualization and WIP limitation are easy to understand for the team, I experienced that nobody really cares about what to do with Measuring the Lead Time. This week I tried a different approach visualizing the Lead Time and got instant feedback from the team. 

One of our team is working with a two tier Kanban with an additional fast lane for immediate support tickets (similar to a bug line).
It looks like this:

kanban team board

We measure the lead time for the orange tasks as well for the blue tickets; Lead time clock starts from the moment the tasks/tickets are moved to In Progress and stops when they are moved to Done (blue tickets) / Done-Done (orange tasks).
We are not starting the clock when the ticket or task has been created (as described in Stefan Roocks Post), although this seems very reasonable especially for requirements from other teams.
Why measuring the lead time?
In theory, the goal is to make the lead time as small and predictable as possible by optimizing the process.

In reality, nobody here really seems to be interested in the lead time, even though I’m sending out a report every 4 weeks that is also printed out and pinned to the team’s board. It shows an overview of all finished tasks/tickets visualized in some charts. Most probably my report doesn’t make sense to them.

As a consequence I tried a rebrush of the report this week.

It now starts with a chart like this:

visualizing lead time in kanbanI got fast and positive feedback from the team: What does the lead time say exactly? … Interesting number! It’s good that we have a number like this! … Now I understand why all tasks should have about the same size and why we have to break down the tasks into smaller batches …

It seems as if it only needed a (simple) visualization of the lead time to get the team’s attention. Now that I have the team’s attention we can start to make the lead time as small and predictable as possible.

BTW: A much better agile coach than I am suggested to use the median of the lead time and not the average. This defintely makes sense!