Scrum Notes 2013-20

| contents

Top 5 Scrum Workshop Don'ts ▶️

This article first appeared on Agile Anarchy, April 2012. Recent encounters and conversations reminded me that most Scrum educators are still training and telling, rather than facilitating and guiding. This article, for all its negation, speaks in praise of facilitation, and deserves a second hearing.

There is a great framework for teaching people about Scrum. It is called Scrum. Oddly, many Scrum educators forget about it, creating very incongruous experiences for the participants. We still get caught up in a training mindset, believing the trainer to be the expert, and expecting the group to hang on to our every word. But teaching Scrum is not training, it is exploration [ref]. There are many good techniques for keeping workshops open, dynamic, Scrum-infected, and engaging. There are also many techniques that should be avoided. I may write something about the former in a future post, but today I am focusing on what not to do.

And yes, I know it is usually unwise to focus on negatives [ref], but sometimes one just needs to clean out the crap before our minds are able to take on new ways of thinking and behaving. Smart readers will turn these statements around and draw out the positive. It's there, hiding :)

1. Don't plan the whole workshop.

Big upfront planning is anathema to Scrum. We seek lightweight, flexible visions and architectures that can change on the fly according to market changes or technical innovations/restrictions. Teaching Scrum from a plan is not teaching Scrum at all, it is playing safe, and it is imprisoning yourself and your group to an imperfect outcome. Instead, have a workshop goal, and a lightweight framework. Run workshops in iterations, allowing for reflection and replanning between each. As the workshop progresses, let the participants drive the direction. Allow for the workshop goal to change.

2. Don't ask questions you already know the answer to.

This technique is widely used. It is both fear-driven and patronising. Fear-driven, because the facilitator is always safe, never taking any risks, always knows the correct answer. Patronising because it treats people like children, vying to get the gold star in class (actually children shouldn't be treated like this either). Avoid putting your participants in a teacher-pleasing position. Only ask a question if the answer will help inform you, as a facilitator, to better understand the context you are working in.

3. Don't play games with predefined outcomes.

For one, you'll get bored pretty quickly after a few repeats of these. And your mind will become closed to possibilities. Play open-ended games, where the process of the game itself—different every time—will inform the participants. Catch learning moments as they happen, and allow time to explore those. Enter each game as if it is entirely new to you. Because it is. Scrum is about people, not repeatable process, and no two people, not two groups will ever behave the same under the same guiding principles, or rules. Invent variations on games as you go, take risks, be prepared to fail... and use that itself as a learning moment for all. Especially, don't play predefined outcome games you yourself have not experienced as a player. This is disingenuous, and you will only be able to facilitate with an academic mindset. Playing open-ended games you have not played yourself is fine, as you are a player and risk-taker in this process.

4. Don't answer questions.

Especially don't answer "How" questions [ref]. These are usually asked as challenges, and attempting to answer them will likely lead to positioning and entrenchment. Instead of offering answers, whether from intuition or experience, seek instead a better question—there is almost always one or more of those lurking below the surface. A classic example is the "How do we manage bugs in Scrum?" question. This is not a useful question, a better one being "Why do we have bugs?".

5. Don't talk about yourself.

Frankly, no one cares. Spend the time finding out about the group instead. Ask challenging questions. Seek to understand, rather than to be understood. Keep case studies and stories from experience to a minimum. Those tales are likely more about your own ego than any real learning. Seek instead universal myths and metaphorical stories that allow participants to make connections for themselves. Teach from a principles and values perspective, not a solutions perspective. Ask about the experiences of the group members, and use those as pivots for exploration.

Note: The photo is from an Augusto Boal self-organisation game being played at the Boston Agile Games event, May 2010. Boal's games rarely have known outcomes, which is why I consider them a "do".


Idaho Falls, 22/08/2015   comment