Can you hear me now?

I'm relatively active on twitter, and sometimes my tweets generate some thoughtful, interesting or humorous replies. For instance, here's an image from my timeline:

What I found funny about this is that I'm talking about Scrum (you can see the hashtag) as well as referencing a specific activity that occurs.

Luckily, Sprint customer service was ALL OVER that and wanted me to reach out to them to elaborate on what my issue was. This generated a little bit of humor with respect to my colleagues and friends who got a chance to see it in real-time.

This tweet reply got me to thinking of how often I encounter folks who want to talk about Scrum or any other framework.

Sometimes they jumble up random terms and principles in some sort of amazing word salad that makes it tricky to follow what they are actually talking about!

While at one point of my agile career I would get into "correct them" mode, really nowadays I do my best to figure out what they are talking about by asking them about the activities that happen in the session they are speaking about, or facets of the role they are describing (even more awkward if they are talking about themselves!).

It's one thing when it's a simple misnomer, but often after digging a bit you can find that the concept was vastly misinterpreted rather than just labeled incorrectly.

Here's a question - how many different terms have you heard when used to reference a Scrum Master? Or even a Product Owner? Maybe both? Here's a few zingers:

  • Agile Project Coordinator

  • Scrum Project Lead

  • Agile Project Manager

  • Sprint Backlog manager

  • Agile Product Scrum Owner

  • Customer Product Scrum Lead

  • Contractor Scrum Master

  • Agile Management Lead

Here's what I'm getting at:

People are going to hear what they want, and apply a label that is something they are familiar with.

This spills over not just to Scrum Roles, but the specific Sprint events as well. Think about how many times you heard one of the events called something really creative, or even explained to you in a way that really doesn't seem to line up?

"The way we approach Sprint Planning is that the Agile Project Coordinator delivers the requirements in the form of a Spin Backlog which the team will Iterate on for the next 4 weeks"

"Our Data Meeting happens once a week where we give our project status to a few of our internal product owners so they can pass along information to other parts of the coordination"

"Our Retro Huddle meeting is where we bring the customer in and ask them about what they don't like about the team, normally with the team on stage in front of an audience."

"Our Sprint Demonstration is where our team members show up to demonstrate the stories they were assigned earlier in the sprint so the Product Owner can sign off on them."

"What I like the most about our Lessons Learned Retrospective Meetings is when people start to yell at one another, that's how we know we are getting to the heart of the matter plus it's entertaining"

<< This is probably about what you look like reading these quotes, or recalling a time when you've heard something similar to this or potentially explained things to a colleague in a similar way.

As a reminder, the three legs of Empirical Process Control are:

Transparency Inspection Adaptation

Think about transparency as an environment where everyone involved understands the "rules of the road", where all aspects of the process that affect the outcome are visible and understood by everyone involved in the process.

Expanding off of that concept, these "rules of the road" may in fact be misunderstood by those subjected to these activities I gave as examples above (the silly ones that might not be that silly). If you are running into a similar situation where overall some of these activities may be a little further away from their original intent, try this exercise:

Create a one-page worksheet for team members to fill out, with an empty box at the top where you can fill in what meeting you'll be discussing in this session. Then give them space to write down answers for the following questions:

  1. What do you think the goal of the identified meeting is?

  2. Who do you think should be in attendance?

  3. How long do you think this meeting should take?

  4. Can you describe the overall intent of the meeting?

At the start of the session have your participants fill this sheet out at the beginning of the talk on their own. This way you can get a read as far as where their heads are and start to uncover some potentially interesting conversations.

Once you have the sheets gathered, start with the first question and share the different answers with the group. Maybe you build a quick slide, write them on a whiteboard, or fill out a quick electronic survey. Whatever is easiest for the group to view the responses at the same time. Starting with the "goals" question, have an honest discussion about what the different responses are and why there may be misalignment.

For this first pass, you should hear a lot of "oh I thought this meeting was...." or "I think that this meeting is...". That's just fine, you want people to share their interpretations. Only by putting these ideas out in front of everyone can you start to create that environment of transparency where everyone understands the "rules of the road".

Prior to the session use the resources at your disposal (the Scrum Guide, some training material, books, articles, etc) to fill out ANOTHER copy of the worksheet with the Goal, Roster, Timebox and Intent of the meeting. Mark down the Source you got it from, and have it at the ready.

Now, let's say you are like the many organizations that have a desire to use Scrum, and the meeting you are talking about in this example is Sprint Planning. This session involves the crafting of the Sprint Goal in addition to the creation of a sufficiently detailed plan called the Sprint Backlog. You sheet may look something like this:

  1. Goals - Gain mutual understanding on backlog items, agree upon a Sprint Goal, team selects items to accomplish in the upcoming Sprint, team creates Sprint Backlog

  2. Roster - Team, Scrum Master, Product Owner

  3. Time-box - No more than 8 hours for a 4-week sprint

  4. Intent - to create a plan in a collaborative manner for the short term

Source - CSM training material from July 2016

The source of your information can also uncover some interesting conversations. Say the research that you did prior leveraged some internal training material, a past brief someone outside the team built, or some blog post you found online. If your team based their activities on concepts that may be off from the original intent, you can have that hard discussion right then and there.

Have discussions on a per-question basis, working toward a scenario where everyone is on the same page with respect to each element of the meeting. As a facilitator, you are trying to get everyone on the same page with respect to these "rules of the road", where team members may not be in alignment.

Only through having these conversations in a focused manner can the team get to a place of mutual understanding. By establishing an environment of transparency where everyone understands things in the same way, can you begin to have discussions about how to take a hard look at things and make the necessary adjustments.

It all starts with what words we use, what labels we put on things. They may mean different things, and only through conversation can we really get on the same page. Give this worksheet a try with your teams and see how close (or how far) they are on understanding each other. Work together to get on the same page, and then start to have the discussions about how to inspect how the team is doing and how to adapt their activities.

Featured Posts
Recent Posts