Meeting Scrum: Part 1, Make Information Flow

Concerned citizens might warn you not to stand to close: I rope nearby bystanders into the crime I’m currently committing. So when Scott Downey, the General Patton of Hyperproductive Scrum, told me he was busy crawling wineries near my Santa Barbara office, I suggested getting together. “How about 11:30am for lunch?” I asked. “Perfect,” he said, “See you then.”

Scott arrived, we had a hearty repast, and after agreeing the world needed our genius, I had to get ready to to teach the second afternoon of Scrum Training at Citrix Online. Did he want to come? “Sure,” he said. As we walked into the conference room, I asked if he might like to present some of my slides? “Why not?” he said. When we started looking at them, Scott felt uncomfortable. Could he use his own slides?

Yes, he could use his own slides, and he did. In 20 minutes, Scott and I eliminated concepts I had already discussed from his very different Scrum Training deck, and restructured slides that would be relevant for that afternoon into short blocks. Scott trained the entire afternoon solo, with me coordinating and heckling. The transition was nearly seamless. Our students liked our surprise guest, and our sparring interaction helped spice up the material.

To make this possible, I relied on a highly-adaptive meeting format I call Meeting Scrum. It can turn dreary, boring meetings into vibrant, audience engaging events. The next time you have a half-day meeting, you might give a try.

Think Iteratively

Meeting Scrum decomposes high-impact training programs and full-day meetings into  digestible chunks. It involves your audience to help reconfigure information and agendas  on-the-fly to adapt to their background, your skills, last-minute opportunities and plain old serendipity.

Meeting Scrum miniaturizes concepts from Scrum, a software management technique. Scrum produces software in short fixed-time iterations called “sprints,” and demands each sprint produces software that customers value. This requires extraordinary discipline, but typically delivers high-quality software to customers faster.

How long should Meeting Scrum sprints last? Whether in Meeting Scrum, Software Scrum or Enterprise Scrum, sprints should always be long enough to provide independent value, and short enough to allow for rapid continuous improvement. One hour isn’t always enough, especially when learning games are involved; more than a couple of hours means you won’t be able to adapt to feedback even in longer meetings.

Two-hour sprints have worked well for me. Attendees can learn valuable skills and provide useful feedback after two-hours. Agile Training at Citrix Online is 16 hours long, providing 8 two-hour sprints. All-day meetings are 8 hours long, providing 4 two-hour sprints. Even in half-day meetings, you get a chance to change the agenda mid-meeting.

Create a Topic Backlog

Before using Meeting Scrum, prepare your program for iteration. Every program can benefit from an agenda. If you are starting with a giant, unstructured Powerpoint deck, decomposition for Meeting Scrum will improve your presentation.

Work items in Meeting Scrum are called “topics”. Give each topic a clear title, put it in a document or spreadsheet, and then rank-order the list. Of course, cover basic topics first; as you build understanding, cover more advance topics.

If this is a teaching situation, break up lectures with exercises: direct, multi-sensory experiences help people learn. Each exercise is a topic of its own. Remember: you don’t have to explain a concept before you do its exercise. Sometimes an audience frustrated by an early exercise is more open to lectures that follow.

Your list of rank-ordered topics and exercises is called a “topic backlog.”

Groom Topics

Excessively broad topics take too long to keep an audience’s attention. You should be able to cover 3 or more typical topics in two hours. If a topic is too long, break it down into smaller topics and then wrap them up in a final topic. You don’t have to cover all these topics in a single sprint.

How do you know whether a topic will be too long? If your program is slide-driven and you are an experienced presenter, you may already know your approximate slide velocity (slides per hour). I can do about 8-15 slides an hour in Agile Training. I don’t like my topics to be longer than 8 slides long. Open-discussion topics and exercises require some estimation. I estimate a non-slide topic in “slide points,” roughly how much time it might take in slide-equivalents.

We had to groom Scott’s program in 20 minutes. On the first training day, I had already covered the motivation for agile and productivity fundamentals. We pulled Scott’s motivator slides out. We agreed that his “My First Sprint” slides would be a good next topic. But at 49 slides, it had to be broken down. Figure 2 shows the hierarchy we created. In the process, Scott reordered slides to fit into these topics.

Iterate

We then started the two iterations for the day, Sprint 3 and 4. They had this schedule:

In later posts, I’ll describe how we structured these sprints, the ultimate outcome of our Scrum Training, and how Meeting Scrum has changed since we started using it.

Challenge Questions

Some questions to think about:

1. How many slides do you think Scott completed in Sprints 3 and 4?
2. If you are familiar with Software Scrum, who are the stakeholders in Meeting Scrum?
3. Who is the Product Owner in Meeting Scrum?
4. What might transpire in a Meeting Scrum standup?
5. What rules might we apply to decide whether a topic could be started (the Topic “Ready Criteria”)?
6. What rules might we apply to decide whether a topic was completed (the Topic “Done Criteria”)?

With a tendency to stretch and shrink things, I remain your humble servant.