Agile, Business Analysis, Facilitation

Remote Facilitation Tips

4 Comments

I’ve been asked several times about how to conduct remote facilitation of various agile ceremonies.  Remote facilitation used to come up quite frequently when I worked with business analysts trying to perform requirements elicitation, but now-a-days I’m finding a renewed interest in this topic due to distributed agile teams.

Here’s a simple list of things to keep in mind that may just make your sessions easier for you and more valuable for your participants.

Preparing for the Session

  1. Ensure you have a clear agenda that allows for ~ 5 minutes of start-up time. Someone will always call in late or have to download the online meeting software, etc.  Note: this doesn’t mean you start 5 minutes late.  You always start on time.
  2. Ensure you know how to perform the basic functions of the online meeting software such as:
    • Share applications, files, and/or your desktop
    • See list of participants
    • Read status messages (e.g., speed up, slow down) from participants
    • Post and answer questions
  3. Decide which, if any, special features of the online meeting software you will use. Ask participants to be familiar with these features or plan to spend time in the meeting reviewing them.
  4. Practice running the session with another participant so they may tell you how the graphics look, how slow the screen redraws, etc. This is especially important if you are sharing graphics or animation, conducting Sprint Reviews, or online training. During the real session you will not want to your participants to miss important information because they are waiting for the screen to re-draw even as you move to a new topic.

A Few Minutes Before the Meeting Begins

  1. Open all documents and login to all applications needed for the session so participants do not have to watch you search for files, bookmarks, etc.
  2. Login to the online meeting using the presenter URL
  3. Dial into the conference call as the leader
  4. Share an appropriate document or welcome message so people are confident that they have logged into the proper meeting.
    • Consider turning off email notices, IM, Skype, or other applications that may pop-up during the meeting.

Tips for Large Groups

  1. Determine if the conference line limits the number of participants. If so, verify that the number of expected attendees is within the limits. If not, schedule multiple meetings, encourage people to join from conference rooms, etc.
  2. Turn off the conference call line’s joining and leaving the call announcement feature.
  3. Determine if the online meeting software (Live Meeting, GoTo Meeting, WebEx, etc.) limits the number of participants. If so, verify that the number of expected attendees is within the limits. If not, schedule multiple meetings, encourage people to join from conference rooms, etc.
  4. Determine if you will take questions & comments via the phone and/or online meeting tool. If taking questions via the online meeting tool, it is helpful to have someone else monitoring the questions to feed them to the primary facilitator. This way, the primary facilitator can keep presenting the meeting’s content without having everyone view the online questions.

Running the Session

  1. Welcome people to the call as they join the conference line.  Note: Once you have started presenting do not interrupt your presentation & flow by welcoming people who have joined late.
  2. Set ground rules such as:
    • Ask participants to put their phone on mute if they are not speaking. This will reduce background noise.
    • Explain how to mute and unmute their phone (often *6) if you do not have a mute button
    • Ask participants to not put this call on hold because often their hold music will be heard by everyone and make it difficult for people to hear the discussion.
    • Explain how to submit questions.
    • Ask participants to state their name before speaking (e.g., “This is Bill from Philly…”)
  3. If participants do not know each other or if there are many people on the call, ask the questioner to state his name, role, and location (or whatever info would put the question or comment into context).
  4. When handling questions, read or repeat the question to ensure you understood the question & to ensure that all participants heard it, too.
  5. You may want to take a snapshot of the meeting participants for future reference.
  6. If some people are in the room and others are on the phone, do not let people in the room dominate the conversation. Explicitly ask people on the phone for their input and questions. If the line is silent, ask them if they are speaking while the phone is on mute.
  7. Near the end of the session, tell people how to logout of the online meeting.

After the Session

  1. Follow-up on any action items, etc. just as you would for any other meeting.

Good luck!!!  And remember, “Inspect and Adapt!”

Agile, Books, SAFe

Scaled Agile Framework (SAFe) Reading List

2 Comments

After successfully completing my Scaled Agile Framework Program Consultant (SPC) certification at the beginning of the year, I’ve been asked several times by colleagues and friends what they should read if they were going to pursue this certification from the Scaled Agile Academy.

Here are my recommendations.

First I recommend that you go to http://www.scaledagileframework.com website and peruse the information that is publicly available there.  The benefit of this site is that it’s constantly being updated with new content.

The following books I made sure I was very comfortable with:

  • Scaling Software Agility by Dean Leffingwell
  • Agile Software Requirements by Dean Leffingwell

I read Scaling Software Agility first and then I read Agile Software Requirements.  I found this to be very interesting reading it in this order because I could see the thoughts and ideas mature as I moved between the two books.

I also read:

  • The Principles of Product Development Flow by Donald Reinersten (this book and the author are referenced a good deal by Dean
  • Implementing Lean Software Development by Poppendieck
  • Scaling Lean & Agile Development by Larman & Vodke

For agile background (if you haven’t read these, I recommend the following):

  • Extreme Programming Explained by Kent Beck
  • Agile Project Management with Scrum by Ken Schwaber
  • Test-Driven Development by Kent Beck

Good luck with the test!

And remember, don’t just “Do Agile,” “Be Agile!”

Agile, Ceremonies, Stand-Ups

Story-Based Stand-Ups

Leave a comment

Many agile teams have become accustomed to conducting stand-ups, but there are times when the basic stand-up may not be as effective and efficient as communicating progress and aiding team with work re-synchronization.

The basic Stand-Up typically follows this protocol:

  • The team recognizes the Stand-Up is about to start;
  • In a clock-wise fashion each team member, as well as the scrum master, answers the following questions:
  1. “What did I get done yesterday?”
  2. “What do I plan on accomplishing today?”
  3. “Do I have any impediments?”

This type of stand-up works fine, but for team members that are remote this can be challenging for a variety of reasons:

  • Team members often don’t speak up during the tele-conference call.
  • Team members tend to fail to indicate which stories they are working on.
  • The continuity of a story and its completion is broken up as we go around the team room during the Stand-Up.

If you are experiencing this problem, or want to experiment with something different, I have had some teams change to a story focus during their Stand-Ups.  Instead of having the organizing principle be the individual, the organizing principle shifts to the story.  As Larman and Vodde state in Scaling Lean & Agile Development, “this allows us to focus on the baton and not the runner”.

A Story-Based Stand-Up would proceed as follows:

  • The team recognizes the Stand-Up is about to start;
  • Based on story priority, with the most important story going first, each team member working on that story or planning to work on that story, answers the following questions:
  1. “For this story, what did I get done yesterday?”
  2. “For this story, what do I plan on getting done today?”
  3. “For this story, do I have impediments?”

Since it is story based, if a team member is working on more than one story he will address his progress when it comes time to discuss the other story.

Pro(s) of this approach: Shifts from individual to story.  Keeps the team focused on trying to finish a story.  Helps to not confuse effort with results, keeps the focus on delivering business value – the story.

Con(s) of this approach: Team members will speak multiple times, but only when their work lines up with story.  All work needs to be accounted for in stories (some would argue that’s a good thing.

Give it a try.  See if works for you.

Remember, don’t just “Do Agile,” “Be Agile!”

Consulting, General IT

You Are What You Measure or Don’t Measure!

Leave a comment

In my role of IT consultant, employee, small business owner, and parent I have come to really appreciate, understand, and live the  article that was written over a decade ago by John R. Hauser and Gerald M. Katz entitled “Metrics: You Are What You Measure!”

Companies, clients, and colleagues have often asked “Bill, why are we unable to change?” or they’ve implied it when they said “that’s just the way we are, so get used to it.”

You’d be surprised how often I engage with companies that express a desire to change, but they don’t change how they measure the success of their people or projects.  Organizations fail to tie the behavior being exhibited by their people or projects to how they are being evaluated or rewarded.

In one example, I worked for a company who predominantly measured the success of their consultants by how billable each consultant was.  While this seems to be a reasonable measure when taken in isolation, it may not have the results they were intending.

This company had a consultant, let’s call her Karen, who was always very billable, but when you looked at the history of Karen’s projects she had a tendency to always be the last person engaged with the client.  Through some discussions with other consultants, and anecdotal information, we found that Karen had a tendency to “poison the well” and compete against the other consultants from her own company to assure that she was the client’s “top dog.”

So was bill-ability a good metric?  No, good metrics should promote a win/win scenario and as Hauser and Katz’s stated, “good metrics empower the organization.”  I’ll even take this one step further which is good metrics empower the organization and the employee.  This company’s metric was unknowingly empowering the consultant at the cost of the organization and the client.

A better measure in this situation would have been to not only consider bill-ability, but also the ability to grow the client and create a demand for more services beyond just Karen.

In closing, what I learned in the process was this company expressed a desire but didn’t change anything.  To para-phrase Michael Anthony, a noted sport psychologist, he said, “Desire to accomplish something without a plan to do it is just a wish.”

I wonder how many employees and companies are wishing things would change without creating a plan to put desire into action?