Handling Meetings with Remote Attendees

This is the third session in my brown bag series. It's not an "agile" topic really, but it was one of the things people requested a session on. 
I hoped that people would bring their questions and be willing to discuss them. There were four topics proposed, and some conversation although it was mostly people in the room. Here is the outline: 
  1. Day before, set up a Trello board as an option for people to raise topics and added a link to the invitation. Recruited a co-pilot who would watch the WebEx chat and bring up anything that came in through that. 
  2. Five minutes before the session, dial in to WebEx, start camera, ensure that screen sharing is set up and the projector is working. 
  3. Noon - official start time. 


  1. 12:05 - start session, to give people time to arrive or dial in. 
  2. Started recording. 
  3. Introduce session, let people know about the Trello board and the chat option. Explain that this is a conversation, and if I was just going to stand here and read slides as them, it's not a meeting. Invite them to bring up topics for discussion.
  4. Topics brought were:
    1. Dealing with different time zones
    2. Cross-talk
    3. Technical difficulties
    4. Using a white board
  5. The cross-talk issue was used to introduce the idea of working agreements. The best possible way to deal with cross-talk is to not have any, because the team have agreed among themselves to not do that, and they will call each other out if they break the agreement. 
  6. The technical difficulties issues was used to bring up the importance of preplanning.
    1. First of all – do you need to have a meeting at all? Can this be handled more effectively some other way? 
    2. Does everyone need to be in the meeting? The reason to have a meeting is because everyone needs to talk to everyone else; if that's not the case, don't do it. Once you involve technology, every attendee becomes a possible point of failure that can result in everyone wasting their time.
    3. Does your equipment work?
    4. Did you build in a buffer? Meeting rooms are tight, so you might not be able to arrive ahead of time to set things up. Don't fill up your entire scheduled block, but assume that a meeting scheduled for 1 will actually start at 1:10.
    5. Set up a back channel, make sure everyone knows what it is, and if you have more than a few people in the meeting, designate a co-pilot to keep an eye on it. 
    6. Of course you have an agenda, because every meeting should have an agenda. 
  7. The different time zones issue was used to bring up the issue of fairness to all participants, which continued with the white-boarding example – some people in a meeting room use the white board, which can't be seen by others. My emphasis here was very plainly that the meeting experience ought to be the same for everyone in the meeting. 
    1. If one team stays until 7 p.m. to attend a meeting one week, the other team should get up at 4 a.m. to do the next one. Spread the burden. 
    2. If one person has to dial in remotely, then everyone should dial in rather than having six people in a room and one person who can't participate effectively because they're at a handicap. (The example I used was that it was like asking one person in the meeting room with me to wear a blindfold for the meeting. How would that work?)
    3. Video is absolutely best, but if one person can't keep up a video connection for whatever reason, then no one uses video.
    4. If you're going to whiteboard something, use an online whiteboarding tool that everyone can access, because otherwise you are wasting the time of the person who isn't there and can't see what you're doing, let alone contribute to it. If that's not feasible, then don't expect them to participate effectively, and if they can't participate effectively why are they even there? 
It was fun. I got positive verbal feedback from the participants. 

Comments

Post a Comment

Popular posts from this blog

Agile Transitions as Self-Sustaining Reaction

Weird confession time? I used to be a little dubious about the long-term role of coaches and even of Scrum Masters or equivalent in an Agile organization. Once you’ve taught people the rules, what else is there to do? People are smart, and Agile methods as a rule aren’t complicated. I wondered—how could it possibly take more than a year or so to get this thing going? Then I spent several years observing an Agile transition from its initial push phase through to a kind of equilibrium, and I have gained a different understanding of the roles and the process in such a transition. I’m going to call these roles Primary Agile, because their work centers on fostering agility— and nothing else . Agile transitions can be thought of as something like a chemical reaction. The system starts in one state, and by adding some ingredients and – most importantly – energy, the system changes into a different state. For most organizations, that end state is going to be very different from whe
Read more

Shu Ha Ri Skeptic

Last year it seemed like I couldn't turn around without hearing someone talking about shu ha ri and its applicability to Scrum (it was usually Scrum, probably because other Agile techniques are less ceremonial). There's a good summary here . Although I don't practice martial arts, I do meditate and practice yoga, which I feel gives me a way toward understanding how the idea is supposed to work. When you first start practicing, after all, it takes all of your attention just to get into the poses or to glimpse a moment of still attentiveness. Why you're supposed to do a specific pose or follow a particular sequence won't fit in there until you've been doing it for a while, until the physical part has become automatic. That said, something about that metaphorical connection, about the idea of "just do the Scrum ceremonies as prescribed, and why will come later" didn't sit well with me. After a fair amount of rumination I've finally identified wh
Read more