Sunday, October 28, 2018

Meeting hacks: playing the right cards

Some meeting run very smoothly. Others don't.
For today let's look at one special kind of meeting - requirements preparation (refinement meetings –to use scrum-inspired lingo– are one instance of this meeting type, but there are many others that fall into the same category). Those meetings share some common attributes:

  • Usually they are time-boxed
  • The intention is to talk about numerous topics of a similar nature
  • All of the discussed items should be elevated in quality, depth or detail to reach some –more or less well defined– threshold
  • [optional, but very common] Often those meeting tend to overrun and annoy a lot of the participants

How to make it better

With experienced participants or an experienced facilitator, these meetings tend to run much better - neither breaking the time box nor annoying the participants. What can we do to make this kind of meeting work better for teams without a facilitator, or those just starting of with the practice? Over the years I have seen two behaviors that seem to drive up both the annoyance-level and the time required for the meeting more than most others.

Too much detail

The first behavior we tend to fall into, is to discuss an item in way more detail than is required for the current level of decision making. A special case of this is bike shedding where almost everyone is discussing details of an irrelevant topic because that happens to be the easiest way to contribute. But even without this phenomenon, it happens all the time and with the best of intentions.

Off-topic discussions

Another driver for the discussion going ‘off the rails’ is exactly that: getting off-topic. Often by deepening the discussion on topics triggered by talking about the original item, but actually straying away from the context of the item under discussion. Even worse, many of these spontaneous discussions completely disregard the purpose of the meeting and morph into heated arguments about unrelated issues.

Cards on the table

Oftentimes, some of the people in the room may notice these effects, but due to a number of phycological barriers, it can be hard for them to voice their concern. Reasons not to speak up might be the impression that they are the only ones with that concern, past experience that trying to stop an argument only extends it, a difference in rank and many others.
Using playing cards (or planning poker cards) as a means to assist in the management of the two behaviors mentioned above, has proven to be an effective self-facilitation tool. I typically use the Aces and the Jokers from a traditional card deck or the question mark and the coffee cup from a planning poker deck.

  • Ace indicates that the discussion is lost in detail
  • Joker is used to denote the fact that the discussion has run off-topic.

When using planning poker cards I tend to use the question mark as a symbol for too much detail and the coffee cup to indicate getting off-topic.
In any case it is a good idea to post the rules visibly so that the group doesn't have to remember –or even discuss– the meaning of the cards.

Rules of engagement

Just discussing the meaning of the cards and being physically in possession of them already raises everyone’s awareness of (at least) these two ways to derail even well-structured elaborations, but some additional rules on how to use the cards make this technique even more valuable.

I suggest these three rules:

  1. If one person holds up an, card nothing happens. The discussion may continue. (This allows for a simple verification of the personal impression without interrupting the potentially important discussion and simultaneously gives permission for other people to ‘voice’ their opinion.)
  2. If a second person holds up a card of the same type the discussion is tabled for the moment, and a reminder to pick it up again is posted on a jointly visible spot. (I also reduce the time of the main discussion by a minute or so –depending on the group– for each Ace.)

    Furthermore, I tent to use two different spots for the different types of cards, because those different concerns need to be addressed differently. In most cases I find it important to make sure that the Aces (too much detail) get picked up before the meeting is closed.

    It is up to the participants whether they want to do anything about the Jokers after the meeting, but for the Aces the next (third) rule seems to be an extremely valuable practice:

  3. Take time at the end of the meeting to agree on a further course of action for each of the topics posted under «too much detail». For those items the ‘course of action’ tends to be an agreement on «who is going to clarify the details with whom until when?» (Pro tip: Don't elaborate on the details in this meeting, just schedule a follow up meeting and agree to convene again to share the results of that meeting.)

Since I started using this approach, I've seen a steep improvement in the way people conduct refinement meetings, Sprint-Plannings and other “lets discuss this number of similar topics in a fixed time” meetings.

Maybe this approach also works for you?

till next time
  Michael Mahlberg

Sunday, October 14, 2018

Negotiating changes

aka “What’s all this talk about «experiments» and «safe to fail» about?”

Inspect and adapt may sound nice, but all too often, I only see adapt. Without inspect. That’s one of the reasons I like the more systemic approach from Kanban so much:

  • the Principle: Agree to pursue improvement through evolutionary change
  • the Practice: Improve collaboratively, evolve experimentally (using the scientific method)

What's the big difference here?
Most of all, using the scientific method implies an approach based on observable effects of changes. Concepts like the Cynefin Model or the Toyota Kata include things like a ‘probe’ – a safe to fail experiment.

Let's illustrate this with an example from a “scrum by name”-team from the recent past. After some tension about a change, a friend of mine –who was responsible for organizational matters in that situation– agreed to “go ahead and implement the idea”, adding that he already knew that it would be “a waste of time.“
For me this approach was a good example for the traditional mindset of simply adapting without employing the scientific method.

Whatever one did in that situation, it should not be a waste of time. As the late Jerry Weinberg once said: “You can’t always win – but you can always learn.”

Instead of simply implementing that change, the systems thinking approach would be to run it as an experiment!

So what would that mean?

  • Firstly talk with all parties concerned about the (observable!) attributes of the work that should not change (e.g. «the Standup should not become longer») and how to measure or recognize any unwanted changes.
  • Then talk about the things that should change and how to measure and recognize these changes. And don’t forget that you need a baseline for that – otherwise it’s hard to recognize whether things have improved or not.
  • Agree upon the next time you evaluate the data and decide on whether you want to proceed with this change you're experimenting on. You might want keep the change, roll it forward or roll it back.
    Rinse and repeat. (This is by the way one way to implement a PDSA loop)

A concrete example

This may sound difficult, but coming back to an example from an earlier post –having the PO attend the daily Scrum– it may be as simple as:

  • We don’t want the daily Scrum to be longer than it is now and we don’t want an increased number of meetings with the PO. Now we have 15 minutes standups and an average of 4 meetings with the PO per week.
  • We do want the PO to be have more situational awareness. We would know that if he called us less often about the schedule. Today he calls every other day.
  • We will decide how to proceed in three weeks after we lived through one and a half iterations or if the daily is longer than 30 Minutes twice in a row (this part of what makes the experiment safe to fail, along with the small size of it).

[BTW: ‘We’ in this example might or might not include the PO - that’s a question of the individual setup and the maturity of the team and organization.]

Now if the experiment ‘fails’ (e.g. the things that shouldn’t have changed changed and those that should didn’t) that still delivered value: the team learned that they need a different way to involve the PO and can work on other approaches to include them. If, on the other hand, everything works out as desired it is just a matter of agreeing to continue with those new rules.

When thinking about feasible experiments (also called probes) I also like the question I learned from David: Is it small enough to try and safe enough to fail?

Happy experimenting!

till next time
  Michael Mahlberg