Soul-Sucking Death Marches from Hell

I just examined Jeff Patton’s post on backlog grooming and his total discomfort with it as typically implemented in typical agile adoptions. Backlog grooming is implemented as a very bad meeting in his story, which you can examine via the above link. Save that for now, and just examine what I am telling you:

I have the solution here, and it’s all very simple. Game your meetings. Specifically, game your backlog-grooming meetings.

It’s not backlog grooming that is the issue here– it’s the game mechanics. I have written about this in my book, THE CULTURE GAME, and in blog posts. I’m providing more background links at the end of this post. Your meetings are already games. And they have very bad game mechanics.

The “backlog grooming meeting” that Jeff describes is either explicitly stating or strongly suggesting the following:

  1. Everyone attending is mandated to be there; attendance is not optional
  2. The meeting is 2 hours long
  3. There are no breaks
  4. There are no ground rules; the meeting is diluted and polluted by a weak ambient culture (people are diddling phones during the meeting he describes. Others are clearly checked out/disengaged)
  5. The goal of the meeting is probably very vague
  6. There is a focus on tools and processes over people and interactions
  7. I suspect there is an ‘overlord’ feeling regarding how authority is handled in this meeting.

The goal, the rules, and the feedback mechanics are vague. In addition, as previously stated, attendance is not opt-in. People HAVE TO BE THERE.

This is a recipe for a soul-sucking death march from hell. The story he tells is consistent with and strongly suggests the organization is also engaging in mandated collaboration, aka “forced agile”.

Your meetings are games. And they are games no one wants to play. Scrum is also a game, and we usually “make” or “mandate” that the folks play it. And they say “yes” when they mean “no”, if they are asked at all, which they usually ARE NOT. So guess what?

No one wants to play your seriously flawed agile adoption game, no one wants to play your Scrum game, and absolutely no one wants to attend your soul-sucking ‘backlog grooming’ meeting. Why? Because the games you are offering to people to “play” deliver a very low sense of control, a very low sense of progress, a very low sense of belonging, and a very low sense of purpose. It’s all very simple. Your games suck!

The way we are implementing agile/Scrum is seriously flawed. With the best of intentions, we force “agile collaboration” with the predictable, deplorable results of doing that. Then we implement Scrum without asking people what they think or feel about it! Then we force people to attend our soul-sucking “backlog grooming” meetings.

Then we say Scrum doesn’t work. We can do better.

  1. Coaches can explain the concept of invitation and opt-in participation to the management that hires them. Coaches can explain the links between invitation, engagement and productivity.
  2. Management can use invitation to increase engagement.
  3. Coaches and management can inspect game mechanics of all meetings and STOP doing things that do not work. Meetings display a fractal instance of the overall company culture. Long meetings with infrequent breaks, autocracy, weak facilitation and poor game mechanics are the culprit here– not Scrum, and certainly not backlog grooming.

What to do about the backlog grooming? Very simple. Use game mechanics to engage people. Deploy the meeting as a learning ritual to manage liminality and the liminal state of being.

NOTE: This is NOT gamification. Repeat: this is NOT gamification. By definition, “gamification” assumes there is no game! Therefore: You cannot ‘gamify’ your meetings, because your meetings are already games, they are simply bad games with deplorable game mechanics.

Now: What are we to do about this backlog-grooming-from-hell scenario?

Here is the A-B-C “prescription” for refactoring the “backlog grooming from hell” meeting described in Jeff’s post:

  1. Start over. Frame the new way to doing this as an experiment. Call the meeting the “Backlog Timeout” meeting, or make up some other name. (clear goal)
  2. Do it for N sprints or N weeks. State that we will inspect this experiment AS A GROUP at the end of the trial period. (clear goal and sense of belonging)
  3. Meet every day for 25 minutes. The goal of the meeting is to answer the question “what do we know about the backlog today that we do not know yesterday?” (clear goal and sense of purpose)
  4. Co-create working agreements for cell phone use, laptop use, breaks and interactions. (clear rules, complete with a sense of belonging)
  5. Attendance by the PO is mandatory. The PO is the Convener. (clear rules)
  6. Attendance by the SM is mandatory. The SM works in service to the Convener. This is spelled out. (clear rules with sense of control)
  7. Attendance by Team members is optional. They are invited. They can opt-out with no consequences or sanctions. (clear rules with sense of control)
  8. Facilitator keeps group on task answering the question: “what do we know about the backlog today that we do not know yesterday?” (clear goal, sense of purpose and belonging, managing the liminal state of “not knowing”)
  9. When the 25 minutes are up, the meeting is over. (clear rules, sense of progress)
  10. PO adds the freshly-generated EXPLICIT KNOWLEDGE to the PB each day. The most recent PB changes are reviewed at the start all subsequent meetings. (clear sense of purpose, belonging, progress)
  11. Consider scheduling the meeting daily, immediately after the Daily Standup each day, every day. (clear rules and sense-of-control)
  12. Always thank the people who opt in to participate each day (sense of belonging and purpose)
  13. At the end of the “experiment”, be sure to follow through by conducting a formal retrospective that you promised (clear sense of belonging, purpose and progress)

These concepts are drop-dead simple and spelled out in this blog post, and in the links at the end of this post.

To be successful, you must:

  1. Make sure the practices you create are in alignment with the Agile Manifesto’s 12 principles, and
  2. Make sure the practices you create are in alignment with the Gaming Happiness framework discussed in my book, and supported by the principles, patterns and practices found in this post and the links below.

The Backlog Timeout is an object example of a good design.

I have experience implementing the 25-minute Backlog Timeout Meeting and I can tell you it works absolutely great.

The folks participating appreciate the clarity and brevity of the meeting, and the ability to opt-out. In typical (weak) agile agile implementations, there is a death march at the end of the Sprint and attendance at the Backlog Timeout wanes until the Sprint is over.

And that’s OK!

Note that this is just one instance of applying specific principles. Don’t “radar lock” on this practice. Practices change, principles don’t. Anyone can use these principles to get better agile-adoption results. Those principles are:

  1. Good game mechanics: a clear goal, clear rules, a clear feedback mechanism to depict progress, and opt-in participation.
  2. Nominalization. This is useful for sense-making. Give the activity a specific name. Always refer to an activity by its name. This is essential for sense-making.
  3. Frame Experience as Experimentation. Encourage “act as if”, and “pretend”. Frame every new policy as a temporary, experimental, game.

To completely understand this post, you must carefully examine all the supporting links that follow:

Related Links:

Game Your Meetings:

Mandated Collaboration: The Total Oxymoron:

Leveraged Learning: Learn fast as a group by doing very short recurring-every-day meetings instead of those long meetings! Those long meetings are stupid!

Practices Change, Principles Don’t:

Sense-making explained:

Nominalization explained (for sense-making):

I invite you: Call me at 203 915 7248 if what I am saying is resonating with you.