Include All Team Members in Sprint Meetings. Yes, Them Too.

I've been in a few arguments lately. Each argument was unique but there was a common thread running through each: whether the whole team should be invited to attend certain scrum meetings.

I have a firm belief that agile teams do best when team members feel and act as one team:

  • Any feelings of "us vs. them" go away
  • Finger-pointing and CYA activities are eliminated.
  • Team members put team goals ahead of personal agendas
  • Team members become more willing to compromise to gain consensus if doing so helps the team achieve its overall goals

Agile teams should foster a whole-team mindset. For example, an agile team should not feel as though it has a programming subteam and a testing subteam. When a team acts as one team, the idea of functional subteams fades away. By the same token, agile teams shouldn’t feel as though they need to hide anything from one another, and that includes the ScrumMaster and the product owner. Teams that act as one team include every role in every sprint meeting: from planning and daily scrums to reviews and retrospectives.

The arguments I found myself in were with people who didn’t value this one-team or whole-team mindset as much as I do. I suspect that’s because they don’t realize how crucial a whole-team mindset is to succeeding with agile.

Team Member Identity

Let me back up for a moment. When I say that agile teams should not have functional subteams like a programming team and a testing team, I'm not saying that everyone should become a generalist. That's a common myth in agile. Rather, I'm saying that people on agile teams should get most of their identity from membership on the team rather than association with others with the same skills.

To see what I mean, think of a sports team. The sport doesn't matter, but I'll use baseball. A pitcher on the New York Yankees should think of himself as a Yankee first and a pitcher second.

Sure, this pitcher may occasionally get together with pitchers from other teams. And when those pitchers come together, they swap stories that only pitchers can relate to--"Man, once I turned 30, I really started to need those ice packs on my shoulder any time I threw more than 80 pitches in a game."

But even so, our pitcher should get most of his identity as a Yankee rather than as a pitcher.

Special Rules Inhibit Whole-Team Thinking

To foster a whole-team mindset, it is important to remove any special rules created by or imposed on the team that apply to only a subset of the team. The baseball team’s morale would suffer if there were a jug of Gatorade in the locker room with a sign saying “pitchers only.” And agile teams can’t thrive when there’s a metaphorical sign on the meeting door that says “Development Team Only.”

But that’s exactly what happens on many teams when it comes to two specific agile meetings: the daily scrum and the sprint retrospective.

The arguments I mentioned earlier centered largely around someone telling me the product owner (and sometimes even the Scrum Master) should not participate in these meetings.

This is wrong, wrong, wrong.

Excluding the Product Owner from Meetings

Any rule a team establishes saying, "This type of person should not participate because of their role" works entirely against the goal of creating a whole-team mindset.

To see how wrong excluding a product owner from these meetings is just because the person is a product owner, imagine a rule that said testers cannot attend. Or left-handed team members can't attend.

If those rules sound wrong then so is a rule that says product owners or Scrum masters can’t attend.

What If Your Product Owner Is a Jerk?

Sometimes I’m told that a team doesn’t want the product owner to participate in a retrospective or daily scrum because the product owner is a jerk. Well, the solution then is to do the same thing the team would do if a programmer were a jerk: Address the behavior of that person.

Don’t make a rule that says a certain role can’t attend.

Yes, some product owners are jerks. But so are some programmers, testers, tech writers, analysts, Scrum Masters, DBAs, and so on.

But we don’t change what is right just because some teams have product owners who abuse a retrospective as a way, for example, to harangue the team over why its velocity hasn’t doubled over the past month.

Agile Teams Need a Whole-Team Mindset

Establishing a whole-team mindset is an important goal for any team that wants to perform at the highest possible level. This doesn’t mean people are interchangeable or that everyone learns how to do everyone else’s job.

But it does mean everyone on the team thinks first about how to achieve the team’s goals rather than each person’s individual goals.

Tommy Lasorda, long-time manager of the Los Angeles Dodgers’ baseball team knew this. He said his job was to get players working for the team name on the front of their shirts rather than their own names on the back. This is the essence of a whole-team mindset in which everyone on the team feels they are in it together.

As agile coaches, Scrum Masters, and other agile leaders, our mission is to help our teams achieve this whole-team mindset. To do that, we need to discourage any behavior that fosters us-them thinking, such as excluding someone from a meeting merely because of their role.

What Do You Think?

Has your team established a whole-team mindset? How did it happen? Has that improved how team members work together? Please share your thoughts in the comments below.


Get Your Customized Elements of Agile℠ Assessment

Get Your Customized Elements of Agile℠ Assessment

Find out how your team is progressing in their mastery of the 20 key Elements of Agile.

30

Posted:

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.