This week, Dan Neumann is joined by Quincy Jordan, who is a Director, Innovate-executive advisor, and a recurrent contributor to the Agile Coaches’ Corner. Today Dan and Quincy are exploring a very interesting topic often brought up by organizations: Which team is the Rock Star Team?
In this episode, you will hear about how to identify the best team, avoiding common mistakes such as measuring teams on their velocity or delivery rates, and also, how to understand what an organization really wants when they ask for the best team.
- Which team is the rock star team?
- It depends. But first, ask yourself which problem you consider you will solve with an answer to that question
- Is the best team the one that delivers the most? Not necessarily; you need to keep on asking questions such as: Why are they producing the most? Does it have a healthy culture? Is the whole team working or is there one person doing it all? Remember that volume of output does not dictate value
- It takes time for a team to function well; we are human beings, not robots
- What are the drivers behind the question from organizations asking for the best team?
- Organizations want to know how to invest, what to look for in terms of return, and how to save
- Organizations might be looking to reward teams the right way
- What are some classic ways in which organizations try to measure a team’s productivity?
- Velocity is a way of measuring a team’s performance but it can easily get dangerous
- A rock star team uses velocity to improve itself
- A team that improves in diminishing the number of carryover stories keeps on getting better
- A great team hits the Sprint’s goal and counts with some level of consistency
- Volatility: How is the team’s velocity changing from Sprint to Sprint?
- Possible impediments for a team:
- Is the team really challenging itself? A rock star team challenges itself if they are achieving the goal too early it can be a sign of them not pushing themselves enough
- Watch out that the metric does not become the goal
- The top people will not always create the top team
Mentioned in this Episode:
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:17] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host Dan Neumann, and joined today by Quincy Jordan, a director in the innovate line of service here at AgileThought and a frequent contributor to the podcast. Thanks for joining me, Quincy.
Quincy Jordan: [00:31] Yeah, happy to be here. Dan. Always glad to be on the agile coaches corner of podcasts.
Dan Neumann: [00:36] Awesome. Thank you. Today we’re exploring a topic that you had brought up as we were talking and we’re going to be exploring how do you know which team is the rock star team? And I’m kind of curious what, what’s the context for that question?
Quincy Jordan: [00:54] Yeah, so, you know, when we go in and we’re doing agile transformations and you know, we come in, we do some assessments oftentimes upfront and we’re often times asked the question by certain leaders, you know, Hey, you know, they kind of pull us to the side and say, Hey, which team is really the best team? Like which team is the rockstar team. And, and it’s always an interesting discussion to me because it depends. And then it also gets into thinking about, okay, well, why, why do you, why do you want to know, like, what are you really trying to get after? What are you trying to find out? What problem do you think that’s going to solve by determining who the rock star team is? So that that’s kind of a bit of the context of, you know, where the thought came from around that.
Dan Neumann: [01:52] That’s, it’s really interesting, right? So when you metaphors can get kind of complicated and rockstar team could mean a lot of different things. Are you looking for individual rock stars? Are you looking for the one that just kind of out shines everybody else? I’m not sure if you’ve had different perspectives on that.
Quincy Jordan: [02:11] And so I do, and I agree you know, more often than not, I think the perception is the rockstar team is the team that delivers the most, you know, like that’s what oftentimes they’re looking for. Okay. Which team has the highest velocity and puts out the most stuff. Now what’s interesting with that is that doesn’t say anything about, you know, how healthy that team is, how well that team works together. It doesn’t say why they’re producing so much. I mean, who knows, you know, like you said, maybe there’s a couple of rockstar team members that are, that’s really carrying the team. Like maybe they’re the ones that’s really getting all the stuff done. So yeah, I think it really depends a lot on what the desired outcome is. And again, you know, what problems they’re really looking to solve is not always about volume of output, volume of output, as we know, does not dictate value. It can contribute to it, but it is not a direct correlation between the two.
Dan Neumann: [03:24] Yeah. How many times are you using the rockstar metaphor? Do you have rock stars or bands that, you know, drug-fueled, you know, whatever or lots of conflict going on with him that, that eventually tears it apart. And you can see that maybe not the drug field barked quite as much with software, but you can see the team dynamics where people aren’t clicking with each other, where there is a lot of leaks of dysfunction in the team and it’s not, not a sustainable situation. Yeah. So when organizations,
Quincy Jordan: [03:59] No, I was just going to say I’ve seen it before, you know, as well where a team did not start out as being a, you know, a very well functioning team. And they matured into that. And then there was a change in the program and then a change in a program, dictated a change in the team composition. And so when the team composition change even though you had some of the same people, but they all got mixed up around different teams they struggled, you know, to get back to that place of that really high performing team that was working really well together. And that’s one of the things I think that I really like for leaders to understand and really appreciate that when you mix up a team like that, even though you take, let’s say you have you have 30 folks across four teams and for one reason or another, those teams have to be recalibrated into a new team formation. So the teams get mixed up for one reason or another. They were performing really well before now they’re mixed up. Well, there, it takes time for those teams to normalize in jail and, and become, you know, high performing teams. Again, it’s not just that, well, on these four teams, we had all really good developers. Now we need to mix them up for some reason or another, that they’re just gonna function great. You know, from the beginning, it, it takes time. We’re human beings, we’re not robots. So it takes time for us to, you know, learn one another, get accustomed to each other’s habits and, and learn how to respect each other’s, you know, strengths.
Dan Neumann: [06:04] Right, right. Okay. I’ve heard of a metrics somewhere around a sprint or more for every individual that’s changed on a team. And I feel like that could be conservative kind of to get back where you were to performing. I think that might actually be a low estimate from,
Quincy Jordan: [06:23] Yeah, it is. It’s a, so to my recollection, it is for every, for every team member that you switch out, it takes two to three sprints to normalize.
Dan Neumann: [06:39] Yeah. So it’s, it’s a while, you know, there’s, you’re doing month long sprints. That’s, that’s a really big chunk of calendar and it still is even basic two week sprints. So when organizations start to ask questions about, Hey, who’s the really good team, who’s the rockstar team. What are some of the drivers that you’re seeing behind that question?
Quincy Jordan: [07:03] So oftentimes they’re looking for how they can forecast. I would say hands down, the number one thing is to looking to see how they need to invest money, but it’s just the bottom line. They want to know how to invest in how to save. So they’re trying to figure those things out now that also translates into a head count team makeup. So they’re trying to figure out, okay, do we need to bring on six more developers or do we need to bring on two more QA is in the inner asking, well, what should the ratio of developers to QA be, you know, for us to have a really well-performing team and you know, by the way, we’re doing Scrum. So can the Scrum Master just go ahead and take on like five teams, you know, those types of questions. And those are the kinds of things that they’re looking for. And of course, you know, the square master should not do that. In my opinion, they shouldn’t. But those are the primary drivers I would say is they’re really trying to back track into how much should we invest when should we look for return and what are ways that we can save.
Dan Neumann: [08:25] Sometimes I get a sense in addition to those things that they’re also trying to figure out well, is it something we can cookie cutter? Can we take what that team’s doing? And somehow distill the magic out of it can install that into another team. And because we’re talking about teams and there’s so much interplay with dynamics and all the different backgrounds and the nuances and the experiences those people have, I feel like that’s not, not necessarily achievable goal.
Quincy Jordan: [08:56] And that’s part of where, you know, some of that forecasting or the desire to forecast, you know, it comes in because they’re not only trying to forecast for those couple of teams, they’re trying to forecast for, okay. If we need to introduce a new program and that program has, you know, 15 teams, 10 teams, 20 teams, whatever the case as you said, that cookie cutter, they’re looking for a formula really in that, in my opinions where the breakdown happens, they’re trying to use a very logical formula on human being behavior. And that doesn’t always work really well. So it works in some ways, but in the ways that they want it to work, to translate into those numbers, it doesn’t always work really well.
Dan Neumann: [09:46] Yeah. I had some windows installed with the house, which I’m loving, cause I don’t hear the road noise outside anymore. A hundred year old house. The windows didn’t really keep the the noise or the wind or the anything out. But I had a team of window installers show up. It was probably five guys. And, you know, they kind of have the run of the house and we, we, as people have been installing windows for awhile, there’s a good way to do it. Yeah. There’s some nuances in my old house versus somebody else’s old house, but you can get measures of throughput and some fairly predictable forecasting on something that’s that repeatable. With software, where you’ve got knowledge work, you have hopefully teams creating things they haven’t created before. The ability to forecast gets a lot more challenging. That’s where the empiricism part of scrum or of any good agile approach, you can inspect and adapt. How are we performing? What does that tell us about where we might be going is super valuable.
Quincy Jordan: [10:47] Yeah. That, that, and you know, as well as I was just thinking about how you know, the really good leaders are also looking for ways to reward, you know, teams as well and to reward to people, to help keep the motivation up. And, you know, the team, the team collaboration, the team energy, like all those things are looking for ways to keep those things up. And so obviously one of the ways to do that is to reward teams. But then sometimes they struggle with, well, which teams do we reward and how do we decide, you know, which ones to reward and how to reward them. So they’re looking for metrics, they’re looking for ways to determine that. But it is an important thing. So that’s, you know, just kind of thinking about one of your earlier questions around, you know, some of the motivations and why, but but that’s another reason is they’re looking for ways to reward teams as well.
Dan Neumann: [11:56] For me, that one, the, of the reward and how do you motivate? And scent recognize often gets fairly perilous cause I’ve seen, you know, I think the Daniel pink video has been around, I don’t know how many years at this point, but right. The autonomy mastery and purpose. And most of the time I see organizations when they talk about that, they’re trying to talk about money and money’s good. I’d rather have it than not have it. But at the same time, yes, money is good. Once the bills are paid though, and you’re at a certain spot, it’s more than that, right. It’s bonuses are nice, but that’s not necessarily helpful. And sometimes it’s harmful. I had a situation recently where there was some, some public attaboys given in like on LinkedIn and the team was like, wow, I would have never thought I’d get recognized publicly. Even just private inside the company, Hey, congratulations. You know, this team, here’s the awesome thing they did and why it was awesome, you know? And it doesn’t have to be the output, but hopefully it’s the, what they did. Somebody stepped out of their comfort zone and try to think, and maybe it worked, maybe it didn’t, but they learned somebody you know, somebody helped somebody else on the team quietly in the background. But yeah, that, ah, the reward, when you start talking about, Hey, let’s reward teams based on X, Y or Z can get poisonous pretty fast. Yeah.
Quincy Jordan: [13:23] Yeah. And, but it is important, you know what I mean? It’s important to figure out ways to reward. And as you said you know, oftentimes just a verbal acknowledgement is, is sufficient, you know? And, and I don’t want even just, maybe I shouldn’t even say sufficient. It’s actually good.
Dan Neumann: [13:46] Yeah. Yeah. When I was a kid, there was the book, it’s something, a warm fuzzies and cold pricklies like, it was about like how you talk to each other or whatever it is, those little warm, fuzzy, those nice comments. They don’t do it timely. Do it. And move on to the next thing. I’m kind of curious then, as organizations are trying to figure out who the rock stars are, one of the ways that we measure teams, sometimes is velocity, it’s not, again, using velocity to measure the team is, is a dysfunction. Using velocity to forecast is good. So what, what are some classic ways you’ve seen orgs try to measure?
Quincy Jordan: [14:29] Well, as you mentioned, velocity is definitely one which gets really dangerous quickly because it is in my opinion, unintentionally weaponized, you know, oftentimes I don’t think people really intend to weaponize it. I think that they’re so accustomed to having a number to use in the in velocity. That’s like the first number that they come across. And, and it’s easy to understand, you know, as well as easy to look at a burndown chart. And, and it seems like the kind of thing that you would use to say a team is doing well or a team isn’t doing well. So that happens often and we have to help readjust to thinking around, you know, how to adequately use velocity. Now I would say that one of the characteristics of a rockstar team is a team that uses velocity to improve themselves. So not the leaders trying to do it, but they see that the teams are using velocity correctly and forecasting and you know, and so forth for themselves. So that I think is a really good thing.
Dan Neumann: [15:49] I love that. So, so, so, sorry, sorry. Real quick. I love that I wanted to apply it. So a team that uses their velocity and looks at how they’re performing and goes, what do we see? What did we learn? What contributed to doing better or doing worse stabilizing, not, you know, whatever the case might be. So a team that is continually improving might fall into that category of a rock star team, not the exact quote, but the fact that they continue to get better.
Quincy Jordan: [16:18] Exactly. Yeah. And the same thing with, you know, carry over stories, you know, so carry over stories. That’s another one. It’s always good. When you can see that a team looks on their own and they say, you know what, wow, we’re having a lot of carry over stories. I don’t think we should have this many carry-over stories. And they take it upon themselves to start doing a root cause analysis and figuring out, you know, in the retro or, or some other time, depending on the severity of it. And then, you know, from an outward perspective, looking in if you see that a team has a carry over story or a couple of carrier stories, and those same stories have carried over like a few spreads, all right. That warrants, you know, so I’m looking at, so that’s, that’s an indicator in my opinion, that the team is maybe becoming a little lackadaisical on maybe not all their stories, but on whatever that particular story is, you know, it, it’s becoming, it’s going from a carry over story and it’s turning into tech debt, you know, at that point, it’s, it’s turning into a different animal, you know? So at that point, it’s, I don’t know, you know, is that thing in your house that, you know, you need to fix that you just keep walking past every day, you know, it’s turning that kind of thing.
Dan Neumann: [17:50] Turns into wallpaper after a while. Yeah.
Quincy Jordan: [17:52] And that’s, that’s not a rockstar team moment, you know, to do that. That’s, it’s more of a rockstar team moment to say, Hey, we need to go ahead and fix this and, and take care of it.
Dan Neumann: [18:15] Well, and it can lead to some, some hard conversations about what, what the actual impediment might be. And then I know what some of the latest changes to the scrum guide. There’s a lot more focused on sprint goals as opposed to, you know, a hundred percent delivery of the backlog items that will fold into the sprint. But at the same time, when you have a piece that you continually forecast and continually fall short on delivering that’s a chance to pause and you probably have stakeholders who are hoping that that increment of value gets delivered and repeatedly disappointing, you know, stakeholders, users, et cetera, is, is not a sign of a rock star team.
Quincy Jordan: [18:56] Yeah. And so that just kind of caused me to think, you know, a couple of other things. So one of the things that I would say is a son of a rockstar team, are teams that hit their sprint goal, you know, on some level of consistency. And you know, she said, maybe not hitting everything in the backlog, but achieving that goal. Now that being said, if a team is hitting their sprint and goal, and let’s say they have two weeks sprints and they hit the sprint goal and there’s three days left in the sprint and they’ve already hit their sprint goal, on the surface that seems good. But it’s not in my opinion, because if you hit your goal that early, right. So what are you now doing for the rest of the sprint? So now you’re just pulling the extra stuff. So my point is at that point, it causes me to think, well, maybe the team isn’t quite challenging themselves enough because they’re possibly giving themselves too much cushion too much really contingency kind of what it is. They’re giving themselves too much room for error and not pushing themselves quite enough. Now they’re finishing and they’re hitting the sprint goal like a day, you know, ahead. Yeah. Okay. All right. I guess that’s fine. But I mean, literally if you’re like three or four days out and it’s a two week sprint, you’re hitting your goal almost mid sprint, little after mid sprint. So I would say they’re probably actually not taking on enough. And so a rockstar team to me would be one that challenges itself a lot more. And you can see that challenge being evident by they’re hitting their goals, but you’re not hitting the goal too early, similar to the carry over story. You know, if they never have any carry over stories, then that causes me to question, are they actually challenging themselves and taken on enough? Or are they always taking on, you know, what, they are 100% sure that they can get done, which is generally not something that’s going to consume the sprint.
Dan Neumann: [21:13] Yeah. I think it’s interesting to think about the spread goal as those steps towards the product goal. And you’re correct. What happens once it’s achieved is the team, I know there’s a concern that teams won’t do anything. I’ve never met a team that is kind of like, yay, we’re done with the backlog items. And now we’re just going to kind of sit here for awhile. But yeah, collaborating with your stakeholders, what is the most valuable sprint goal that we might have in the next sprint and then working to make sure that that is, is delivered and Matt it’s kind of an interesting, interesting thought exercise to go through for sure. So let’s talk about any other measures that come to mind as we’re trying to divine what might be good or not good from exploring who the rock stars are?
Quincy Jordan: [22:03] So volatility is another one that, that I favor towards which is the deviation within their velocity. Like how small is their velocity changing from sprint to sprint is the expectation that they should hit it hit the velocity every single time. No but if their velocity let’s say is, you know, 31 sprint 32, another sprint 31 and another sprint 29, another sprint, okay. That’s not too bad. But if their velocity is 31 one sprint, 40, another sprint and 32 30, 22 a different sprint. You know, I mean, that means they’re all over the place. And if they’re all over the place, then they are not doing a good job of forecasting. What they can accomplish during the sprint. And the bottom line is the better they can forecast and anticipate what they think they can actually get done. And the smaller that the, it deviates from that then the better others outside of the team can forecast what that team can probably accomplish, you know, within a given sprint, which could easily translate into a given program increment which, you know, could easily translate into some really top line business objectives that need to be hit.
Dan Neumann: [23:38] Yeah. I think it’s interesting with, with forecasting that’s that’s, for me, the thing volatility is useful for, and then when that number doesn’t vary a lot, it makes the math pretty straight forward on where my, the team got through the backlog. And hopefully the teams involved in that forecasting, not some, not some outside entity doing the forecasting for them. And then when there is deviation, if it’s big, you know, that, that cone of uncertainty, it’s hurricane season in Florida right now that cone of uncertainty about where the, the effort might land over time gets wider and wider quickly with a lot of, a lot of variants. So definitely can see some reasons why more predictable delivery has helpful yet at the same time kind of the, the double-edged sword is we don’t want stability for its own sake or weird behaviors taking places so that there isn’t variance.
Quincy Jordan: [24:35] Yeah. And I think that’s always the danger in any of the metrics, at all that the metric I’ve thought we always have to be on guard to make sure that we don’t allow the metric to become the goal, because once the metric becomes the goal, then it’s to me, you’ve lost the game, you know, it’s, it’s all where you’re now headed towards a target that is not, you’re not even on the, on the right course anymore. And then as far as you know, it just causes people to start gaming the system and all that stuff. And, you know, those are not the types of things that you want to look for, you know, in your rockstar teams. And you know, I don’t even know if I would say, I think that you should look for the rockstar teams. I think you should just look for the healthy teams because in many ways the rockstar team kind of gives the impression that this is a team full of all your best developers, all your best QA folks all your top people are, you know, on this team. And, you know, I, I know before, before the podcast, well, before we started, we were talking about the relay US relay team. And, you know, it’s, it’s not always that if you take all the top people that you end up with the top team, it does, it just doesn’t always work that way. And oftentimes you get a lot of different dynamics and then even if you look at it and say, well, let’s just focus on a rockstar individuals, you can have a rock star individual that kind of carries the team and actually prevent unintentionally prevent other teammates from maturing in growing in, developing more, because everyone becomes accustomed to throwing all the really hard, complex stuff to this person, because they’re always willing to take it. So I just think there are a lot of different dynamics, you know, that goes on when people are trying to seek out, you know, that rock star team and pattern all the other teams after that rock star team.
Dan Neumann: [26:54] Yeah. And I you touched on several good things are just going back a little bit farther when the metric becomes the goal, the metrics loss no longer serves its purpose, right? So it could be people, people are smart, they will figure out how to hit that goal or make the numbers look like that goal was hit. And that’s a dysfunction for sure. And then to your point, it’s great. If you have a team that’s just really killing it, but to then expect every other team to do the exact same thing becomes unreasonable. So how do you help all the teams be helpful? How do you help them all be successful and, you know, help help the business schools help everybody make business impact as opposed to expecting normalization and standardization and kind of doing the cookie cutter those, all those schemes. So as we get here towards the back part of the podcast, I guess maybe any, any closing thoughts on these rockstar teams?
Quincy Jordan: [27:54] So I would probably just say, you know, I think rockstar teams can be okay, but those are, those are probably not, I would not rely on the rockstar teams being the bulk of your program or the bulk of your let’s say, portfolio of teams. I think about it as I wasn’t in the military. But I think of it as my concept of as I understand it, that, you know, different outfits within the military, you have like your general soldiers and, you know, they’re very equipped, they’re trained. They can do really well, you know, and so forth, you know, but when you need precision you know, you may go to your special forces, you may go to your seals and so forth. And those teams, they’re the top of the top of the top, but they’re not doing most of the stuff they’re doing very strategic precision work. And so if you have those rockstar teams and you put them on like those really complex things that requires that type of team, I think that’s good. And, and that’s okay. But as you said earlier, you know, it’s not really fair to expect everyone in the military to be special forces. Like that’s not, you know, everyone isn’t going to be that top team. So you should not model your organization after that because there’s always going to be, you know, the, what do they used to call it, the creme de LA creme, you know, of, of the group. So so you really want to base things on the teams that are consistent, the teams that are reliable, the teams that, you know, they’re very skilled and equipped and so forth, but not base your on what we sometimes refer to as unicorns.
Dan Neumann: [29:45] Yeah. I, I think the thought that comes to whether you want fit for purpose, you want the team and the team structure to be applicable for, you know, doing the work. Are you, are you trying to have a team regularly make the same airplane over and over, or are you doing a skunkworks thing where you’re trying to make, you know, a new stealth aircraft, those are really different animals. So that’s wonderful. Thank you for, thank you for that. And since our theme is rockstars, the Encore question then is, is anything on your continuous learning journey right now?
Quincy Jordan: [30:18] Well, you know, I am still reading reviewing to pull it out every once in a while. So to say same book from, from what we’ve talked about before God is my CEO following God’s principles in a bottom line world. And you know, there’s a, there’s a very consistent theme in the book from all of the top CEOs that they interviewed and try to make sure I remind myself of that consistent theme and, you know, surprisingly with all did they accomplish the theme is not about business. It’s actually very consistent that they all say the same thing that they wish when they’re asked the question, what would they do differently now that, you know, they’ve accomplished so much and every single time? It, I will spend more time with my kids. I will spend more time with my family. Truett Cathy and a number of other, you know CEOs were all asked that same question. I think Warren Buffett may maybe one, two, I don’t remember for sure, but it was all, it was all the same thing I would spend more time. So so my continuous learning, you know, right now is that, yes, I enjoy the agile space. I enjoy transformation. I enjoy all those things. But also want to make sure that I stay focused and grounded and balanced, you know, in all that I do.
Dan Neumann: [31:44] Sure. No, that makes sense. And especially now, I think it’s a challenge with the work from home and you’re in proximity maybe to the family. A lot of times, not you personally, but people are in close proximity, but proximity, isn’t the only part to making sure that there’s presence and quality and, and you know, real value from that time together. So thanks for sharing that nugget. Quincy appreciate it.
Quincy Jordan: [32:06] Absolutely. Thanks for having me always a pleasure to be on the Agile Coaches’ Corner podcast.
Dan Neumann: [32:12] Perfect. Thanks Quincy. We’ll look forward to doing it again.
Outro: [32:16] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.