Episode 122 – Power Your Agile Teams

Episode #122
Original Air Date: 02.01.2021

36 Minutes

Listen Here

Our Guest This Episode: Kupe Kupersmith

If you want a self-organizing, dedicated, stable team, this episode is for you. Our guest Kupe Kupersmith, talks with us about creating healthy Agile teams. One of the first challenges is when your team is too large. Hear Kupe’s story about a team of 36 members he was tasked with managing, as he explains the strategies he applied to divide this team into more manageable, efficient sub-teams. Kupe’s advice is to determine your team’s skills and strengths, select an approach, try it, analyze your results, and tweak it as necessary.

Kupe shares his unique approach to RAM or RACI, and the importance of starting initiatives with a clear understanding of responsibility to avoid conflict. In this conversation, we also run through foundational steps to a healthy team as laid out by Patrick Lencioni in The Five Dysfunctions of a Team. Kupe offers some practical steps to build trust in your team. Kupe explains his “One Team” approach, and the unique technique to reduce unnecessary talk in meetings called ELMO. (Try it – ELMO works!) When you have One Team that is focused and stable, you are closer to achieving that winning team performance.

From Accountant to improv comedian, to IT Consultant and back to improv comedian, Kupe’s goal in life is to make you more awesome. Onstage, Onsite, and Online, Kupe helps individuals and organizations achieve business value focusing on professional skills, business analysis, project management and leadership skills.
Kupe is the author of an InSite course: Overview of Lean Business Analysis and he is the author of a new InSite course: Remote Agile Delivery.

Learn More Kupe’s InSite Course "Remote Agile Delivery"

Learn More Kupe’s InSite Course "Overview of Lean Business Analysis"

Favorite Quotes from Our Talk:

"... team members feel that everybody has their back; that, if I do something wrong, someone’s going to swoop up and help me and be there, that I can be transparent and ask for help and feel comfortable that nobody’s going to throw me under the bus."

- Kupe Kupersmith

"...is your team pointing fingers at each other? Or are they acting as one team?"

- Kupe Kupersmith

Share With Others

The podcast for project managers by project managers. Kupe Kupersmith, talks with us about creating healthy Agile teams. Trust, healthy conflict, commitment, and peer-to-peer accountability build healthy teams which produce winning results. When you have “One Team” that is focused and stable, you are closer to achieving that winning team performance.

Table of Contents

01:03 … Meet Kupe
02:21 … Splitting a Large Team
05:24 … Assessing How to Split Teams
07:30 … Reactions to Team Splitting
10:15 … Responsibility Diagramming
14:27 … Adding Remote Complexity
15:20 … The Five Dysfunctions of a Team
16:31 … Lack of Trust
18:18 … Steps to Build Trust
20:45 … Healthy Conflict
22:40 … Being Comfortable with Conflict
26:16 … Commitment
28:32 … Peer-to-Peer Accountability
29:43 … ELMO
32:41 … Producing Results
34:57 … Get in Touch with Kupe
35:36 … Closing

KUPE KUPERSMITH: …it’s about that team members feel that everybody has their back; that, if I do something wrong, someone’s going to swoop up and help me and be there, that I can be transparent and ask for help and feel comfortable that nobody’s going to throw me under the bus.

WENDY GROUNDS:  Welcome to Manage This, the podcast by project managers for project managers.  Just a little update about claiming your PDUs.  The steps to submit a PDU for our podcast as well as for our InSite courses to PMI has changed.  Our PDU claim page has been updated with the new instructions.  Make sure not to use the autofill, but type in Velociteach and the title when you are submitting your PDUs.  We do apologize for the inconvenience.  But thank you for listening, and please contact us if you need any additional assistance.

I’m Wendy Grounds, and with me is Bill Yates.  This is our opportunity to talk with you about issues that project managers are facing today.  And sometimes it’s working remotely, sometimes it’s working on teams, and sometimes it’s all of that together.  Our guest today is somebody we’ve had on before.  He is Kupe Kupersmith, and he was on Episode 62, where we talked about BAs and PMs, decision-making for superheroes.

BILL YATES:  I’m excited about this topic.  I think at a macro level it’s all about healthy teams.

Meet Kupe

WENDY GROUNDS:  Yeah.  Kupe is the coauthor of “Business Analysis for Dummies.”  He’s had quite an eclectic career path.  He has been an accountant, an improv comedian, IT consultant, business analyst, and a project manager.  He has collaborated with us on some courses.  One was the “Overview of Lean Business Analysis.”  And currently he’s working on a course on remote Agile delivery.  Kupe, welcome to Manage This.  Thank you for being our guest today.

KUPE KUPERSMITH:  Thanks for having me.

WENDY GROUNDS:  I have a quick question, before we get into our discussion.  It was 2018 when we had you last on the podcast.  So what have you been doing since then?

KUPE KUPERSMITH:  Wow, has it been that long?  I feel like…

WENDY GROUNDS:  It’s been that long.

KUPE KUPERSMITH:  I feel like I was in your office; and then, poof, you asked me to do another one.  But I guess it’s been two years.  Well, prior to 2020 I was doing a lot of keynote speaking.  And we talked some about improv, I think, and the improv work I do, and how I talk about improv and how it helps people be better collaborators, communicators, team players.  So doing a lot of that.  I’m also an IT consultant, so I’m out there with companies kind of implementing Agile practices and other practices to have effective teams and get teams to deliver the great products that our customers want.

Splitting a Large Team

BILL YATES:  You’ve been partnering with us on courses, and there are so many nuggets.  I just wanted to have a conversation about being a healthy team or creating a healthy team.  One of those I thought was really unique, and you talked about when your team is too large.  I think in the example you gave you had 36 team members that were needed to get the job done.  And you’re like, we’ve got to split this up.  I think that’s something a lot of us face.  I want you to describe the issue and the setting, and then let’s get into some of the strategies that you took with that.

KUPE KUPERSMITH:  So, yeah, that example, there was a team of 36, and I was asked to come in and help deliver a project and do it using Agile principles and the kind of way I approach projects in general.  So in Agile, as you guys know, they talk about small co-located teams, and “small” meaning five to nine people.  Well, yeah, I was thrown into this where I didn’t have five to nine, I had 36, so it’s really four teams of people.  So you can’t let that stop you and be like, oh, well, we can’t use Agile principles or Agile practices because we have 36 people, not nine.

And so what I did was just think of, okay, what’s going to be the best way for me as at the time a coach, scrum master?  How do I break this team up so that we do have manageable teams?  I mean, the whole point of having a smaller team is it’s easier to control, the team feels comfortable together, working together, and can be more effective.  When I did join the team, they were split into two teams, but that even wasn’t effective.

And what I noticed with this team, and I think with most teams, they’re not getting the work ready for teams in a sprint.  So we were working in sprints, two-week time boxes.  And but work would get into those sprints, but there was all these questions.  Nobody knew exactly what was going on, and there were still design issues.  And so there was all this back and forth, and a lot of churn, and the team wasn’t getting done with their commitment.

So I identified the areas that we had to do a better job of readiness; all right?  That was the first thing.  So there was UI work.  There was data work.  So I initially got the people that were focused on UI work, just created a UI team.  So in this case there was like five people that became a UI team.  There were four people or so that became the data team.  And then the other folks were the two scrum teams, the ones that were going to be actually implementing and testing the work.

So by doing this, it was easier for me then, like I could keep track of a team of five on the UI work and the things they had to do.  I can keep track of the data team and the four things they had to do.  And that led into the teams, like, okay, here’s all the data, the information you need to get the work done.  Now let’s start lining those up in sprints and start you guys doing the work.  And then we had two sprint teams that were kind of going through scrum-type activities on a biweekly basis.

Assessing How to Split Teams

BILL YATES:  First question regarding that is you could have taken a different approach and said, okay, I’m going to take these five UI team members and split them across five teams, you know, one per team, one data person per team, et cetera.  When you were looking at it, what were the pros and cons to doing the approach you did versus an approach like that?

KUPE KUPERSMITH:  In this case, kind of my mindset was is there reusable content; is there reusable stuff.  So, yes, I could have said, okay, we’ve got 36 people.  Let’s create four scrum teams, nine people each.  And, yeah, put data people on each one, put UI people on each one, and just flow the work to those teams.  But the UI work there was, in this case, like style guide stuff that, regardless of the work, there was some basic stuff that had to be done that would be used across all the teams.  So who do I give that to, then?  Do I give it to Team 1?  Do I give it to Team 2?  Team 3? 

So it’s like pull them together, and same thing with the data.  We’re going to bring in the data once, but not necessarily only use it for one epic or one feature.  It was going to be used across multiple features, so which team would I give that to?  So it was easier just to kind of split them out.

But you bring up a good point.  There is not one way to skin the cat; right?  As a leader, as a delivery leader on teams, you have to assess your team and see what’s going on.  Where are they efficient?  Where are they not efficient?  And then determine, okay, how do we break this team up so that we can start to get more efficient and get more throughput?

BILL YATES:  Yeah, I love your point there, which is it’s not a one-size-fits-all.  There are different ways to skin the cat.  So you have to look at it, and you have to look at the needs that the project requires, and then look at the skill set that you have.  So if I’m on that UI team, and I know there are things like a style guide that I’ve got to abide by, then I either want to create it or be a part of the team and continue to have conversations with those who are creating it.  And so I think it’d be frustrating if I was a UI guy on one team and all my peers were spread throughout the other teams because we’d constantly be communicating anyway.

KUPE KUPERSMITH:  Right, absolutely.

Reactions to Team Splitting

BILL YATES:  So why not put them together, yeah.  And then the other teams, the scrum teams kind of come to them for their UI needs.  They go to the data team for their data needs.  That makes sense, so there needs to be flexibility with that.  So when you walked into this, there was already two large teams that had come from one.  So you have to break up the squad and reconfigure.  How well did that go?  Were people pretty receptive to that?  Or did you get a lot of resistance?

KUPE KUPERSMITH:  It was a combination.  I think overall when I’ve run into these situations where the team hasn’t been meeting deadlines and commitments and, you know, teams are struggling, then people are looking for new ideas and, yeah, yeah, I’m still on the team.  I didn’t get kicked off.  So okay, they need me.  Let’s do something better.  So for the most part it was good.  But there was a handful of people that were trying to lead it before, and those are the ones that had to kind of get on my side to, okay, troops coming in.  They’ve been trying to do things, and they did a lot of good things.  It wasn’t like everything was thrown out.

So it was like, okay, let me get them onboard first about how we’re going to approach this, and get them to be champions with the rest of the team.  But initially with them there was some resistance because they were like, you know, we were doing it this way, and that wasn’t the problem related to why we were not being as effective.  Where my assessment coming in was, no, this is an area we have to take on.

One thing I used to help, though, to get people comfortable, is it’s all about experiments.  Right?  I might come in and say, hey, here are some key things we have to do.  Or even if other team members, like I’d promote, hey, you guys are in the day-to-day on the ground.  If you have an idea to make things better, let’s bring it up.  Let’s try it out.  If it works, great, we keep going.  If it doesn’t work, we change it.

So that was my thing, I was like, I know based on my experience and what I’ve seen and what I’m seeing here on this team, I think if we do these three things, that’s going to help us elevate to the next level.  If it doesn’t work, we’re going to change it.  And actually I gave you kind of the end result of our team splitting.  That was our second generation.  We had some other thing that we tried first, and it still didn’t get us – it was a variation of the end result.  We had more of the UI people in some of those teams, so we had to pull more people out.  But that’s the whole thing, it was an experiment.

And I think this is what happens with too many teams.  They sit around and talk about how are we going to do this?  What are we going to do?  Everybody’s bantering back and forth.  We just keep going around, instead of saying, you know what?  You know, Wendy, your idea is as good as any.  So we’re going to take that, let’s try it out, if it doesn’t work, we’ll change.

Responsibility Diagramming

BILL YATES:  Kind of transitioning into this idea of a responsibility diagram, so now we have several distinct teams.  We’ve taken our 36 team members, and we’ve broken them into teams.  And, you know, you kind of go through that Tuckman stage of, okay, we’re forming, we’re storming, we’re norming.  We’re trying to figure out what we’re supposed to do as team members.  This responsibility diagram concept, it kind of reminded me of a RACI chart or something like that.  But it’s got a different twist to it, just describe how you came up with that. 

KUPE KUPERSMITH:  I’m a big believer in – and we might have talked about this in the last podcast.  RACIs to me, even to this day, I don’t know the difference because responsible and accountable; right?  And I think a lot of people confuse that.  And then it’s like, are you informed?  Consulted?  There’s too many variations.  And then you have a line or a task or a responsibility that at least four people are listed.  So I’m a big believer in having a person responsible for something, like directly responsible for something.  That doesn’t mean at all that people aren’t asked to chime in that are consulted, that have to be informed.  I’m not saying that.  It’s not like I have a group of kings and queens that make decisions on their own about stuff.  But somebody has to be ultimately responsible for something.

You know, and some of my teams, what I find, especially when I try to move teams to a more Agile manner, we often have resource managers that are over multiple team members.  So sometimes QA has their own resource manager.  Sometimes the developers have theirs.  The BAs have theirs.  So I’m working with a team that has three or four different management layers. 

And it’s hard, when I’m coming in trying to work on this project, if I’m not in sync, and if I don’t have clear responsibility breakouts between me and all those managers, starts to put a lot of pressure on the team.  Right?  Because the manager of those people are coming, asking them to do stuff.  And I’m like, “Why are you listening to your manager?  We need to get this project done.”  And they’re like, “Well, my manager pays me my money.  They give me my raise.”  I don’t; right?

BILL YATES:  So who are you, Kupe?  Yeah.

KUPE KUPERSMITH:  So what do you give me, a T-shirt?  Like, I’m going for the big raise.  So it’s really important to work with, at least at first, with the management layers.  Like if I’m the delivery lead, I’m responsible for implementing this project.  Let’s talk about my responsibilities versus the manager’s responsibilities and, you know, most cases like product owner responsibilities or key stakeholder responsibilities.  And make sure everyone’s clear on those levels, and if you have that, I mean, I constantly have it in front of us.  So when we run into a conflict, I don’t bring it up as, hey, you know, we agreed five months ago that this is my responsibility.  So why are you taking it?  It’s just to bring up the conversation, like hey, what’s happening here?  We had this agreement that we were going down this path.

BILL YATES:  Oh, I’m sure.  Because, to me, I could see, let’s say you and I are both leading different aspects of it.  There may be a topic that’ll come up, and I think I’ve got a clear understanding of that topic, and it’s your responsibility.  And you’re looking at it going, “No, no, no, Bill, that’s yours.”  So we have to look at that line item and kind of go, wait a minute, what does this mean?  Let’s redefine it.  Or maybe it needs to be broken into two pieces.  So, yeah.


BILL YATES:  It’s kind of a living document.

KUPE KUPERSMITH:  Yeah, I think overall this is a big thing that gets missed.  And people just assume, especially by title, that we know what everybody’s responsibility is.  We just jump into the work, and then we get into all these conflicts.  And you brought up, not a conflict, but a gap; right?  Like I didn’t think it was mine.  I thought it was Bill’s.  And Bill, you thought it was mine.  So now something gets dropped.  So it’s really important to start these initiatives off where you have clear responsibilities. 

And not that it doesn’t evolve over time, and that it’s perfect, but if you get 90 percent of them nailed, it’s just so much easier and smoother.  So now, talking about effectiveness, the team focuses on getting the work done, not who do I go to for this?  Who’s making that decision?  I mean, that just takes up so much time during the initiative.

Adding Remote Complexity

WENDY GROUNDS:  I think it’s an important thing for the remote teams to really have that, that they can look at and say, this is exactly what I need to be doing, and what Bill needs to be doing.

KUPE KUPERSMITH:  Yeah, the remoteness, that adds – it’s just a level of complexity.  It’s not like, to your point, Wendy, it’s not that it doesn’t get done in a non-remote situation.  But in a remote, we’re not there talking to each other.  If we were all in the same room all the time, and there was a question of that, it’s like, hey, guys, I thought this was Coop’s responsibility?  No, it’s Wendy’s responsibility.  Okay, cool.  Well, if you’re remote – and especially I deal a lot with offshore team members working in India.  So if they have questions, they then have to send me a chat.  Twelve hours later I pick it up.  You just lose so many days.  And today’s environment we’re asked to push and do more.  So it’s like, how do you reduce those gaps in days?

The Five Dysfunctions of a Team

BILL YATES:  I want to transition into a topic, and it’s related to an author that I’ve got a ton of respect for.  And Kupe, I know I got excited when I was reading through your script for the course, and you got into Patrick Lencioni and “Five Dysfunctions of a Team.”  I’ve talked a lot about his book, “The Ideal Team Player,” as well.  I think this is the first one that he kind of hit the workspace with, “Five Dysfunctions of a Team.”

And we’re talking through the aspects of a healthy team. Now we’ve got our teams.  How do we make sure they’re really top-performing great teams?  You go through these foundational concepts that Lencioni brings out, and at the very bottom of, you know, that foundation starts with trust.  So whether you’ve got an Agile team, a traditional team, a hybrid team, you’ve got to have trust.

KUPE KUPERSMITH:  Yeah.  So I’ll step back and just talk about Lencioni.  I saw him speak years ago.  It must have been maybe the release of the book, “Five Dysfunctions of a Team,” saw him speak on that.  And I was like, I love this guy; right?  Instantly became my business idol.  But this concept just stuck with me for years, and I just incorporate these concepts in everything that I do with my teams.

Lack of Trust

So yes, the first dysfunction is lack of trust.  So you need trust on the teams.  And those that have read it know like the trust he’s talking about is not trust in that Wendy sent me notes about this session that she trusted that I was going to show up on time for the podcast; right?  And so you need that trust, but that’s not what it’s about.  It’s about that team members feel that everybody has their back; that, if I do something wrong, someone’s going to swoop up and help me and be there, that I can be transparent and ask for help and feel comfortable that nobody’s going to throw me under the bus.

And I look at this as, you know, is your team pointing fingers at each other?  Or are they acting as one team?  So when I talk about trust, and every email I send to my team I end with “One Team,” like we have to be in this together, regardless of what happens.  It’s nobody’s fault.  It’s our fault.  If something didn’t go well, let’s not sit there and talk about for hours, like, well, you know, Wendy’s the one that sent me a note, and she said it was going to be at 1:30, so it’s Wendy’s fault I didn’t show up on time; right?

It’s like, no.  So what happened?  So Wendy sent me the wrong time.  That’s fine.  Next time we do a podcast together, how can we get better at that; right?  Rather than bashing Wendy.  Because now Wendy’s going to be guarded.  Like if she gets bashed, or people talk about her in a way, then it’s like everything is just going to take longer because she’s going to be so nervous that, if I make a mistake, then Bill’s going to come down on me.  Well, you can’t work like that.  You have to feel safe.  The prerequisite to any team is safety, psychological safety.  So we have to feel comfortable.  And that starts with teams that are trustworthy.

Steps to Build Trust

BILL YATES:  So what are some practical steps that, as a team leader, that we can carry out to build trust?

KUPE KUPERSMITH:  So I’ll start answering that by, as a leader, you need to look for opportunities where trust is being broken down.  That’s why I go back to the pointing fingers versus acting as one team.  And that’s when you can identify those.  So if you, like as a leader, when you hear people talking about or complaining about other people or coming to you as the leader, you know, Bill, if you came to me and said, “Hey, yeah, I’m really having a challenge with Wendy, she’s doing X, Y, and Z,” as a leader my first thing – and this is a classic; right?  The first thing is always, okay, have you talked to Wendy about it?  If you guys can’t work it out, if you’re still having conflict, then come to me, and I’ll try to help work through that.

So that’s the first thing is to push all the conversations down to the team members to try to work it out.  And this is interesting because in scrum, it always talks about the scrum master as the one that helps the team remove impediments.  And I was working with a team, standing them up, getting them ready to work in an Agile manner.  We were talking about team agreements.  And one person said, “Oh, well, Kupe’s going to be our scrum master.  So if I have an issue with so-and-so, I’m going to go to Kupe.”  And I was like, “Oh, no.  No, you’re not.”  Like I’m the last person you come to; right?  I mean, you guys are a team.  You’re working together.  So constantly work things out.  And then if you can work things out together, you start to gain more trust.

And there are so many, especially in our world, I think ideally people want these teams of generalists that can do a bunch of everything.  But we still live in a world of specialists, where you have someone that’s a developer primarily, someone that’s a BA primarily, someone that’s a QA analyst primarily, they have to support each other. 

But we have these kind of breakouts.  So when you start hearing the developer say, “Well, I coded it that way because the BA wrote it that way in the story,” or “Hey, QA analyst, you’re testing it wrong.  That’s why we’re having a problem.”  Then it’s like, whoa, okay, guys, we are not acting as one team here.  So let’s focus on the process and the work to be done and try to focus on that rather than pointing blame.  And always come back to the process and getting more efficient with the process.

Healthy Conflict

BILL YATES:  That leads me right into the second foundational step, which is healthy conflict.  And fear of conflict is the dysfunction that Lencioni brought up.  He talks about you need to have conflict.  You need to have conflict.  You have to have trust first, and then you can have healthy conflict.  But there are proper ways to do it; right?  I don’t want to call you out in front of the team and go, “Kupe, that requirement you wrote was just – it was awful.  I couldn’t even start to code it.  You’ve got to do better than that.”  There’s a better way for me to do that.  But back on the topic of conflict, what does healthy conflict look like, and how do you build that in the team?

KUPE KUPERSMITH:  Yeah.  Over trust, I think conflict is my favorite one to talk about because you need the basis of trust.  Back to, if we were pointing fingers at Wendy all the time and, “Hey, Wendy, that’s a crappy idea” every time she brought something up, she would stop talking.  So Lencioni talks about the continuum of conflict like you were talking about the bad conflict.  It gets really nasty, name-calling, finger-pointing, rudeness.

And hopefully most of us don’t have that in our workplaces.  I think what most of us do have is the other end, which is no conflict.  Where someone of title or someone in the room is like, hey, I think we need to do this.  And everyone doesn’t say anything, or is like, oh, okay, great, awesome.  And then they leave the room, yeah, I call it “the meeting after the meeting.”  It’s like, can you believe what Kupe just asked us to do?  That is the stupidest thing; right?  So they’re undermining the process.

So I know, even if I have the greatest idea and nobody challenges me on it, I know that there could easily be a problem.  Which gets to the next item, which is commitment.  I really think as a leader you need to spark conflict.  And the goal is actually to get – Lencioni talks about getting right in the middle.  So in the middle of the bad conflict and the no conflict, you’ve got to get right in the middle.  So before I go into ways, the one thing you have to be comfortable with is actually going over the midpoint.

Being Comfortable with Conflict

BILL YATES:  I’m glad you brought that up because I thought it was really cool.  When I was reading through the script, I was like, ooh, people are going to cringe on this.  So explain this more.  It’s stepping over that line.

KUPE KUPERSMITH:  Yeah, and now I don’t even know if I had it in the course or not.  So I’ll just say it here.  But one of the pieces, and I tend sometimes, because I get passionate and excited about something, that I could seem to go over that line.  And if you do go over the line, it’s conditioning yourself to realizing, whoa, I’m sensing people are getting put off by me, so I need to tone it back.  But you have to be willing to go over, or you’re not going to get close enough to that line.

So like an example I always use, I was in a meeting, it was a board meeting for a nonprofit.  And we were talking about this topic that I got really excited.  And I was like, in the meeting I was standing up and trying to influence the group, right, to go my way.  So at the end, we kind of came to a decision.  I don’t even know what the decision was, whether it was mine or not.  But at the end I was like, wow, that was amazing.  We just had a great working session to work through that decision.  And someone’s like, really?  I thought you were mad at us.

I was like, oh, my, you know, sometimes I don’t even recognize, but I’d probably stepped over the line.  But you know you stepped over the line if everybody totally gets quiet and just shuts down and is like, no.  And that’s happened to me.  People have shut me down, where they’ve gone on the rude side of conflict; and I was like, okay.  But I’m just not going to say anything.  Even if you’re on that, you have to be cognizant or conscious of, wait, I just shut down.  I really, I do have ideas, and I need to give those.

BILL YATES:  Yeah, and a quick note on that, just in the remote setting that so many of us are in today.  That’s even more difficult today.  I could say something, not realizing that it just – it landed like the candy bar in the punch bowl, so to speak, and I didn’t even notice it.


BILL YATES:  Normally I’d be in a room, I could see it in maybe the body language.  People are crossing their arms or looking at their phones or not making eye contact or something.  But now let’s say we’re all on a conference call, or maybe we’re on a Zoom, I can’t pick up on some of those signals.  So I think we have to be even more aware today with the way that we’re communicating as to when we are stepping over that line, or when we need to push it further to get there.

KUPE KUPERSMITH:  Right.  You’re right on.  I mean, early on, when COVID hit, we had video on all the time, and then all of a sudden, I don’t know when it hit, but like nobody puts video on anymore.  And you know that the multitasking is going on like nobody’s business these days because we have a lot to do, and I can’t tell you how many times I hear on calls, like, uh, “Repeat that?”  And now, I mean, we’re so open as a team, everybody’s just like, “Oh, sorry, I was multitasking.  You’ve got to repeat that if you need me to answer it.”  Right?

BILL YATES:  You have the foundation of trust.  That’s good.

KUPE KUPERSMITH:  Yeah, I’d rather you say that than be like, “Oh, I couldn’t hear you.  You were breaking up.”  Come on.  I haven’t broken up for the last hour.  So all of a sudden when I ask you a question you can’t hear me?  But everything remote in that way you have to be more direct or focused on asking questions.  So in a room I could tell that, hey, Bill hasn’t been responding that much, or Wendy, I could see Wendy’s getting nervous.  She looks like maybe I’m going overboard, so I need to pull it back a little.  You know, you have to make sure you’re always checking in with the team.  And if nobody is responding, it’s like, okay, guys, why are we not responding?  Someone chime in.  Tell me are you really bought into this or not?  If you’re not, I need to know now.


BILL YATES:  So that brings me to the third and fourth.  I see these as really going hand in hand.  If we have a team that the foundation is trust, we’ve got healthy conflict.  Then we’ve got commitment, and from commitment comes peer-to-peer accountability.  So first of all, step three, commitment.  What do we mean by this?

KUPE KUPERSMITH:  Yeah, so this is buy-in, like they are committed, and they’re going to make it happen.  So I always talk about there’s trust, conflict, and then a decision gets made of some sort with that conflict.  At that point then we have to make sure everybody’s bought in.  We can all think about this.  Bill, if you’re the decision-maker, if I’m listened to, and even if you go the exact opposite of what I was talking about, at least the way I try to look at it, I had the opportunity to influence Bill.  I didn’t.  But I’m still going to buy in and go with his approach, and next time I’ll try to figure out how I can influence Bill to this.

So most of the decisions we make, and this is something critical to share with people to get buy-in, most of the decisions we make can be reversed or changed.  They’re not so critical that, if I decide to split the team up into these four teams, that we can’t change that.  So if people are giving their ideas, and somebody’s sharing with me, “Hey, Kupe, I think we actually need six teams, and we should do it this way,” and I’m like, okay, heard all the feedback, I think we’re going to go with these four teams, at least that person should be comfortable, one, Kupe listened to me; two, that if four teams doesn’t work, we’ll probably come back to this, and I’ll have another opportunity to bring up the six teams.  But you need that.  Especially when you’re remote.

And I talked about “One Team” before.  It’s like, we had one goal.  Our goal was to deliver this product.  And, you know, the next, the fifth dysfunction or function is results, right, focusing on the result.  That was our one goal.  So along the way, if I don’t get commitment from people, or if we don’t have commitment to do stuff, it’s just going to take that much longer.  If we get everybody to jump in, try it, then we’re going to find out really fast if it worked or not.  If we have half of the people resisting and pushing, we’re never going to get to the point that we actually get through that thing and say, yes, it worked or it didn’t work.  So it just elongates everything.

Peer-to-Peer Accountability

BILL YATES:  So the fourth level, if you will, is peer-to-peer accountability.  We’ve made decisions.  We’ve committed to them as a team.  And we’re charging forward.  To me this one can be really challenging, I believe, which is…


BILL YATES:  …getting a team to call each other out.  And I’m not saying, you know, not like I can’t wait to go to work today so I can call somebody out for screwing something up.  It’s not that.  But it’s having that courage and confidence in the team and the trust of the team to actually be able to bring things up in a timely fashion.  Yeah, how do you get team members to do that?

KUPE KUPERSMITH:  Yeah.  So a quick example here or statement about it is, if the team is like, hey, we are committed, so they trust each other to have this conflict now, are committed, well, if somebody is going around that and taking a different approach, then somebody should call them out; right?  It’s like, wait a minute.  We committed to taking this approach, this process.  So why are you not doing that?  But this is very hard.  A lot of teams are built on this hierarchy of I report to this manager, this other person reports to another manager, so I’m going to go talk to my manager.  That manager will talk to that person.  Yeah, and eventually we’ll work it out; right?  Yeah.  Never happens.


So again, the one thing I did, I, one, tried to put mechanisms in place that maybe are fun to hold people accountable.  And I talk about this in the course, about ELMO is a technique:  Enough, Let’s Move On.  So one of the challenges we had on our team, because we had so many people, was we had meetings.  And again, the meeting times for everybody is not convenient.  Either it’s not convenient for the people in the U.S., or it’s not convenient for our India team members.  So we want to make sure we have the right people in the meeting.  And then let’s be as efficient as possible because, if I’m up at 11:30, I don’t want to go on and on about something till 1:00 a.m.  Like if we can get it done in 15 minutes, let’s get it done; right? 

So we did, our team kept coming up in retros that, you know, meetings aren’t effective, blah blah blah. And so I’m like, okay.  Well, here is a way we can try to do this.  So I introduced – and I didn’t come up with this, it’s been out there, but ELMO, Enough, Let’s Move On.  So anybody at any point in the meeting can yell “ELMO” and say, “Hey, I think we’ve talked about this enough.  Let’s move on.”  And then we can do a quick pulse of the team, like hey, everybody agree that we need to move on?  Yeah, yeah, yeah.  Let’s do it.  So what I found on my team, they kind of just put it in the chat window.  You know, so we’re on Teams, and they won’t say it, but…

WENDY GROUNDS:  I like this.

KUPE KUPERSMITH:  I’ll be like, hey, so-and-so just threw ELMO out there.  We good to move on?  Right.

BILL YATES:  Yeah, yeah, yeah.  It’s funny, when I came across that, I actually just I think in the last two years I was in a meeting.  A guy was facilitating it, and he was using that.  It’s the first time I’d seen the technique used.  Very effective.  This was face to face.  It’s cracking me up thinking about a chat window or IM or something.  But in a face-to-face setting, the first person would say “ELMO,” and then kind of look around the room, like do people agree with me?


BILL YATES:  And the way it worked in a room was people would either go “ELMO, ELMO,” or they’d say, “I need to hear more on this.”  So it was really helpful.

KUPE KUPERSMITH:  Yeah, that’s great.  That’s a good addition to it, yeah.  So, I mean, it’s things like that on the accountability side.  But it’s not, again, there’s no silver bullet.  I talked about this earlier.  If you’re having a problem with someone else on the team, as a leader you have to be very diligent and keep pushing those team members to have that conversation to work things out.  So when someone comes to me with a challenge, it’s like, okay, we’re going to be in a meeting with them in an hour.  If it comes up, I will support you when you yell “ELMO” or whatever it is.  But you have to do it.  And then the more they get comfortable with that, the better.

And a lot of this is predicated, I feel, you know, one of the key Agile principles is having a dedicated stable team.  For me, with this team, we were together for a little over a year.  And as the weeks went on, they got more and more comfortable with each other.  I would call them out and make them get comfortable with each other.  So now – it’s almost like they don’t need me anymore, which is good.  It’s like, that’s really about self-organizing, when they don’t need a delivery leader to help orchestrate, that’s kind of the perfect time.

Producing Results

BILL YATES:  That’s awesome.  So that brings us to the top of the pyramid, which is results.  Healthy teams produce results.  And that’s, I mean, honestly, that’s one way you can tell  whether a team is healthy or not is what are they producing?  So talk about that.  You said you end your emails with “One Team.”  One team, one result.  So one trophy for the whole team?  Or do you have individual trophies?

KUPE KUPERSMITH:  I do think, I mean, I like to get a good pat on the back, too; right?  So it’s not like people aren’t rewarded for their work.  But our goal, it’s removing the egos from the equation.  And I think in a lot of the teams we work on there’s the concept of the hero mentality.  Like Joe came in, and he worked all night to fix something and save the day.  This project would have failed if it wasn’t for Joe, I never want to have that.  I don’t want Joe on my team because then Joe is rewarded – and sorry for all those people that are named Joe out there.  I would have you on my team.  It’s just this one Joe.

So if you have the Joe, if they get rewarded, then that becomes the mentality, like I’m going to wait until everything kind of starts to fall apart.  I’m going to swoop in.  I’m going to fix it.  And poof, now I get rewarded again.  Rather than that is not what I’m rewarding.  I’m rewarding people for helping each other and jumping in, taking on tasks that might not be in their comfort zone and moving kind of the ball forward.

BILL YATES:  To me, this is such a powerful, simple construct for healthy teams.  And it was great hearing those examples, too, that are both Agile or traditional; it’s a remote team or a face-to-face team.

KUPE KUPERSMITH:  You know, I mean, my approach is – and even the whole Agile movement started, it wasn’t anything specific.  It was, hey, what do good teams do?  And let’s just do that going forward.  Right?  So that’s always been my attitude.  So the conversations of Agile versus Waterfall, traditional versus nontraditional, it’s like, that’s waste-of-time conversations for me.  It’s like do what works best.  You want to be efficient.  And there are great concepts that have come out of the Agile movement.  So use them; right?  That’s my attitude.  So it’s what’s going to be best for our team, our organization?

Get in Touch with Kupe

WENDY GROUNDS:  I’ve been waiting to do this.  I’m going to shout “ELMO” now.

KUPE KUPERSMITH:  Come on.  Wait, wait.  There’s three of us.  Bill and I are not done yet.  So, sorry, Wendy.

BILL YATES:  We’re not done.

WENDY GROUNDS:  It’s been excellent.  Thank you so much, Kupe.  I really appreciate you being here today.  And I also look forward to the course coming out.  I think that’s going to be excellent, too, for those who would be interested in finding out a little bit more.  If people want to talk to you, how can they reach out to you?

KUPE KUPERSMITH:  The best way is on LinkedIn, so Kupe Kupersmith, K-U-P-E and then K-U-P-E-R-S-M-I-T-H, that’s probably the best way to get me and continue this conversation.  That would be awesome.


WENDY GROUNDS:  That’s it for us here on Manage This.  The good news is you have just earned some Professional Development Units by listening to this podcast.  To claim your free PDUs, go to Velociteach.com and choose Manage This Podcast from the top of the page.  Click the button that says Claim PDUs and click through the steps.  Thank you for joining us.  Until next time, keep calm and Manage This.

2 responses to “Episode 122 – Power Your Agile Teams”

  1. Avatar Jill Unterberger says:

    The comments regarding the RACI really resonated with me.

  2. Avatar Anne-Sophie Drouin says:

    Thanks for this timely podcast! I have recognized what my division has gone through during our Agile transformation journey. We are in an inspecting and adapting phase in one of our scrum teams.

Leave a Reply

Your email address will not be published. Required fields are marked *