Episode Description:
In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by AgileThought colleague Eric Landes to discuss real vs. fake teams. Landes, who comes from a DevOps background, originally started out as a developer. Currently, he serves as a senior DevOps consultant, ALM director and solutions architect. In his roles, he helps clients deliver value to customers in their software delivery pipeline, and he has extensive experience in leading organizations in adopting agile and lean frameworks like Scrum and Kanban.
In today’s discussion about real vs. fake teams, Dan and Eric talk about what distinguishes the two teams, the benefits to having a real team vs. a fake one, and how you can help enable teams to move from “fake” to real. Tune in to hear it all.
Key Takeaways
What distinguishes a real team vs. a fake team?
- Real teams collaborate while fake teams cooperate.
- Fake teams are groups of individuals that are not behaving together and do not have a shared goal or outcome.
- Real teams have a collective focus; they are catching defects before they happen and there are code reviews happening in real-time.
- Fake teams observe rather than code in real-time (so they end up with really delayed feedback).
- Fake teams generally have lots of individuals working on lots of different problems at the same time (therefore, they’re not really building on each other’s ideas).
- Real teams have an interest in continuously improving together, whereas fake teams may have a rockstar or two who go after self-improvement when the rest don’t.
Benefits of having a real team:
- Faster delivery pattern with higher quality.
- A real team collaborates and keeps the whole team’s focus in check.
- It’s a lot more energizing than working in isolation.
- Benefits of quality and speed and delivery.
- The focus from the accountability you get from being on a team helps eliminate brain distraction.
- Happier employees.
How to enable teams to move from “fake” to real:
If you’re management and the team wants to hone their craft, help enable that.Defining the goals for real collaboration beforehand with your team can help enable more effective collaboration.Does the team have a goal that makes sense for them? If they don’t, then start in establishing one.When you do have a goal for the team, look at the product backlog and make sure it is structured in a way that enables collaboration.In the Retrospective, help the team see some things that might be opportunities for improvement and would encourage a collaborative focus.
Mentioned in this Episode
Eric Landes’ Book Picks:
Transcript
Intro: [00:01] 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 am your host, Dan Neumann and today Eric Landes and I are going to be exploring the topic of real versus fake teams and as usual these will be the opinions of myself and Eric and not necessarily those of AgileThought or other folks or other companies. Thanks for joining.
Eric Landes: [00:36] Hi, thank you for having me. Dan. Excited to talk about teams and we talked about real versus fake teams and just interested to discuss that with you and hopefully bring some value to folks.
Dan Neumann: [00:50] Yeah. At Agile2019 conference in August of this year. Actually, depending on when you’re listening to this, it could be as soon as just a week ago, Eric and I had the pleasure of sitting in three hours worth of session with woody Zuill on mob programming and really had some interesting insights and things to reflect on based on the content that woody was sharing and especially as it started to relate to, do you have a real team or not?
Eric Landes: [01:18] Yeah. And I think that session really got me thinking about what does that mean real teams? You know, there was a, something Woody had said just to kind of trigger that too, you know, the team is really collaborating together in mob programming. I’m not necessarily saying we have to do mob programming, but I think there’s a lot of good benefits to using that to trigger kind of that real team of collaboration. There’s probably a lot of other ways to do that as well. Um, but when we talk about real team collaboration, for me, one of the biggest benefits I see to having a real team is typically a faster delivery pattern with higher quality. Uh, and, and we’ll get into, I’d like to get into why that is, but to me that’s a benefit of a real team. And I’ve seen with what we’re calling fake teams, a bunch of individuals and a lot more delay. What about you?
Dan Neumann: [02:23] Yeah, I see a lot of organizations, they want the benefits of agility. They want to collaborate with their customers more, deliver more of the stuff that customers want. And I think in a lot of cases there are impediments to delivering frequently and consistently with high quality. And when you start to look at why that is, it can start to get into the fact that the team often isn’t a team. It’ll be, well, one of the, one of the differentiators to start talking about real team versus fake team is kind of fake teams are groups of individuals that aren’t behaving together. They don’t have a shared goal or an outcome that everybody succeeds or fails together with.
Eric Landes: [03:11] Yeah, that’s a great point, Dan. And, and I think a lot of the agile terms we’ll talk about, so in our teams, we’ll talk about code ownership and the team owns the code. The team owns delivery. We’re thinking as a team, that’s what we want as a real team. But, but to your point on, on other teams, we’re a collection of individuals. Let’s take Scrum for instance. We’re in a sprint planning. We plan what we’re gonna work on and I’m the UI guy, so I’ll, I’m going to go and grab UI stuff and I’ll work on that this sprint and you guys just leave that up to me and we only talk together and the daily Scrum, you know, those to me are signs of maybe this is not a real team. This is a fake team, a collection of individuals not really trying to work together, if you will.
Dan Neumann: [04:10] One of the sessions that I went to, actually coincidentally it was right after all that time with Woody was one by Gill Rosa and it was about how to make real collaboration possible. And Gill does a great job with some of the books that he’s written and he did a great job with this presentation as well. And he made the distinction between collaboration, which we would consider real team and cooperation. So yeah, maybe the DevOps person, uh, in the, your scenario, Eric is still doing things that are helpful to move the initiative forward, but it’s a relay race. It’s a handoff. So we’re cooperating, but we aren’t truly collaborating on that particular piece of work.
Eric Landes: [04:51] Right. And one example I’ll give a as, as a differentiator to that, uh, is as a team, when, when we looked at the mob programming model that Woody had talked about, there were four or five team members working on one problem and they were there to solve one problem. And as, as we heard about that, the idea is we solve that problem. We have very smart people looking at this problem, working together. We’re focused, we have a lot of, we have a collective focus. We are catching defects as before they happen. Um, code reviews are happening in real time or not checking code in and having somebody else do the code review. So there’s a lot of benefits. Uh, the idea is not that there’s four people observing that again would be a fake team, right? Uh, but a real team is, we’re engaged, we helping write the code as it’s being coded in this mob programming model. Whether you use that or not, you know, you could use pair programming, uh, anything else, but the testers there are talking about, well I’m going to write the test this way. Did you code for that? You know, it doesn’t look like you’re going to catch my test. So to me those are the benefits and why that model works and and shows kind of how a real team is working together rather than the test or waiting till somebody hands them the code and then they test that and then it comes back that there’s a lot, like I said, a lot of handoffs there for the DevOps person, hey, let’s deploy that now.
Dan Neumann: [06:40] Yes, I think you made a distinction between a couple of different things. I wanted to go back and highlight. So one of those is in a real team, we’ve got the team working to solve one problem, deliver one increment, deliver one backlog item, something of value. And what I see a lot of times with the fake team is we have lots of individuals working on lots of different problems at the same time and they’re really not building on each other’s ideas. Um, who Woody referred to when we work on things individually? Yeah, you might get the best of me, but you’re also going to get the worst of me in that result. And when we are truly collaborating as a team, you are going to filter out some of those worst of ideas, well collaborating effectively. We should get the best of everybody’s ideas and weed out a lot of the worst things. And then the second piece you mentioned that that jumped out to me, you alluded to it was we’ve got real time feedback on the tests, on the quality, et Cetera. And with these, the fake team, you end up with really delayed feedback. So I might work on a problem and need some help from somebody and they’ll get back to me hours or a day later or I build something and check it in and wait for a code review for a day. And it’s just all this delay, which allows risk to build up in the system and leads to lots of context switching.
Eric Landes: [07:59] Absolutely. And when I look at a, a fake team, you know, a couple of behaviors to look for, right? That I’ve observed. So we’re in the daily Scrum. It’s my turn. I have to say, this is what I did, this is what I’m going to do. I don’t have any impediments. And then I immediately go back to coding. I’m sure you’ve never seen that on any of your Scrum teams. I have actually seen that on multiple Scrum teams. The team should actually be focused and engaged. So a real team that is collaborating, they’re listening for, oh, you’re working on that. Guess what? I’m, I’m already did that. Or, you know, contribute something to that. Uh, what the team’s focus is, or even a, you know, one of the behaviors I see in real teams in just a daily Scrum is, wait a minute, why are you working on that item? We’re not finished with this item. Our focus is this particular goal. So let’s come back. Let’s all work together. And maybe we’ll start swarming, right? That that was the swarming. Again, if you see your team swarming and working together though, that’s, that’s, hey, maybe we’ve got a, a real team. Um, you know, the other thing, and it may be, you can talk a little bit about this Dan. We talked about energizing and that fatigue. Uh, and, and I think that’s kind of interesting cause I know when I’ve been on teams that are working together and collaborating, I feel really energized at the end of the day.
Dan Neumann: [09:33] No, I do too. And it’s also far more energizing to be, you know, you talked about the daily Scrum and when somebody is talking about just their tasks and it reminded me that in a daily Scrum, if, if folks are doing Scrum, that’s cool. If you’re not doing Scrum, that’s cool too. But even if you’re not doing Scrum, when people are talking about the work they’re doing and how it impacts the overall group is, are people listening, are they engaged or have they checked out? You know, are they looking on their phone? Are they counting the ceiling tiles? Are they staring? But not really listening. Um, and then with the fake teams, you get the indifference to the update that somebody else is giving or the information they’re providing. And I think on a real team, you’ll, you’ll see things like accountability. Like, wait, no, that’s not part of this product backlog item. Or No, we can’t cut that corner because here’s the impact or what if we tried this. So there’s a lot more accountability within the real teams. But for, for real teams when it relates to energy, yeah, I know, I mean there, there are days where you’ll leave work exhausted regardless I think of what you’re doing. Um, but it’s a matter of trending over time and, and seeing, you know, are people generally leaving work energized or are they leaving work fatigued? And you know, metrics is another conversation within the agile community. And that’s not something we’re going to dive too deep on here. But you know, maybe starting to find a way to track over time the trends of energy and the degree to which people are feeling fatigued or not. And for me, being on a real team is a far more energizing type of a situation than strictly having to work in isolation
Eric Landes: [11:16] And to be on a real team if we’re talking about metrics, I would expect we, we would have a real team determining what metrics they’re measuring themselves with and and the real team in a Scrum context, I’m going to include that as the Scrum team. That’s product owner included along with the development team. So if the real team is determining all these kinds of things, you know, that to me that’s what, that’s how you get that feeling is that the team itself has taken ownership of collaboration. They’ve taken ownership of how they deliver and they’ve taken ownership of how we get better. So in other words, you know, I, I think you and I probably both know this story. This was from a while back, but I was very energized at a, this was a few years back with a team when we started doing coding Katas to, to learn how to actually code better to practice coding. And that included all the team members, testers, BAs, even even project manager, Scrum Master-ish types. So when we get the whole team learning and practicing, that’s, that’s also another thing that I think really helps energize a team and brings a lot of collaboration to the team.
Dan Neumann: [12:52] As one of those Scrum Master-ish project manager, like types who used to develop. I, I do remember being excited that I could, um, it was an opportunity to intentionally practice in a safe way. Some of the coding activities we were actually doing red, green refactor as opposed to a pattern of just bolting unit tests on after code has been written. And for me it was a nice opportunity to kind of reattach to some of my software developer roots when my computer science degree was more a part of the work that I did every single day. Um, and so related to improvement then for real team versus fake team, I see real teams having an interest in continuously improving together and really rising the tide of all the ships. Whereas in a fake team, you might have a rock star or two or some people who really go after personal improvement and then there may be some who don’t. And so really trying to create a culture where people are interested in growing their skills for the benefit of the overall group that they’re in for the overall team that they’re in.
Eric Landes: [13:58] Yeah. And I would say, you know, to get to this, how, how do we enable teams to, to move to that real team kind of place. I mean, I would say, I dunno, what does the team want to do, you know, I mean that’s kind of a classic thing. I have some ideas what might be helpful. Again, those coding katas or you know, you heard about coding Dojos making that a regular thing for a team. If the team wants to, let’s encourage them, you know, if your management, okay, they want to do this, how do I make that happen so that they can practice their craft. And the reason why I wanna do this is there’s going to be benefits to speed of delivery. I believe there’s going to be benefits to speed of delivery, there’s going to be benefits to quality that will come out of learning to do things better. Uh, and it’s really, I think it’s kind of a cheap way to get to get folks education and Cross collaboration.
Dan Neumann: [15:23] Agreed. There’s the opportunity to participate in improvement and like you said, to be optional. And I liked what he did a nice job of really talking about and as I say that I’m like we have to find a way to get Woody to come here. Well we’ll have to invite him. I will invite Woody, um, to participate. Cause he, it was a, it was really an enjoyable time and we touched on a number of different things, but one of them was we aren’t compelling people on the team to participate in a mob. It and he didn’t set out to do mobbing. Mobbing was an emergent behavior based on other factors that were there and really trying to foster an environment where people are working together and they were amplifying the good things that were happening and mobbing emerged. So that’s like a lot of frameworks. It’s not appropriate to just take a framework and go install it or jam it down some other organization’s throat, it’s saying, hey, here’s a thing that we did, here’s some of the principles and here’s what emerged. And so making improvement opportunities optional and amplifying the good things that are happening can really help you move towards more of a, a whole team approach. One of the, the the other benefits that I think I see with real team versus fake team is in kinda how to get there a little bit is really that that focus can eliminate a lot of the, the brain distractions. So if I’m an individual on a team and I’m doing a thing or I say I’m going to do a thing during the daily Scrum, it’s so easy to let the next email or the next emergency or the next tap on the shoulder from somebody who wants something kind of derail that whole effort. And the mutual accountability of being a team, will make that much less likely to happen if we’re holding ourselves accountable for being on task. The other session that I went to, um, with uh, Gill Rosa also was really focused on real collaboration and really defining the goals for collaboration. So do we have a goal that aligns with us or that fosters collaboration for us? And so he did a really nice job of walking through, here are some prerequisites for collaboration and then here are some deterrence for collaboration. So if you don’t have the prerequisites collaboration in his opinion, and he said it’s his professional observations, it’s not scientifically backed with studies and data, but from his experience, if the prerequisites aren’t there, collaboration won’t happen. But it could happen if they are. And then as long as the deterrents aren’t inhibiting it and you can deal with the deterrence. I really thought that was a nice, um, takeaway for looking at and enabling collaboration.
Eric Landes: [18:17] Yeah, that’s some good stuff. One thing I’m going to ask you Dan, uh, so let’s say, let’s say I’m a Scrum Master or a agile coach and I want my team to, I’ve noticed some fake team behaviors. I want them to move towards a more real team behavior. How would you handle that? I have my ideas and I’ll, I’ll answer them after you answer.
Dan Neumann: [18:48] Ah, yes. Sandbagger. I mean, so one of the places I start a lot of times is really looking at the product backlog and the way the items are structured. So, well let’s, let’s even back up. Do we have a goal that makes sense for this team? So if there isn’t a goal that makes sense where everybody can align around it, that would be the place to start. But assuming we have the goal for the team then I start to look at, is the product backlog structured in a way that enables collaboration? Is it written down so that it’s an increment of value that the team can, can aggregate around and deliver? Or is it like, well Eric, I’ve got a thing for you. Let’s say you’re the database guy. Okay, we’re gonna um, set up a, a view and some tables and we’ll add some stuff to the data model and then somebody else’s working on the presentation layer for a different backlog item and somebody’s thrown in some, some business logic for an API and yeah, maybe someday that’ll get used. And so the product backlog can have a huge influence on how the team, when they get into sprint planning, if they’re a Scrum team, when they get in there, how are they orienting themselves? Because let’s face it, if I’m a front end guy and you’re the database guy in the stories about database, I might be off on Facebook while you’re talking about the blah, blah, blah. This stuff you’re going to do in oracle cause I just don’t care. I’m now, if it’s a a product backlog item that’s about a slice all the way through the system and I need to pay attention to what’s going to be presented so that I can start thinking about where it’s going to be either stored, retrieved, updated, how we’re going to structure the database to enable that. Now all of a sudden I actually care about that backlog items. So that’s the place where I would usually start.
Eric Landes: [20:34] Makes Sense. And I think sprint planning is a great place to start as well. I would also include in the retrospective maybe helping teams see some things that might be opportunities for improvement that would encourage the collaborative focus. So for instance, and this has happened on many Scrum teams, we have one person who knows this particular tool. So, and we want some cross training across the team. How could we learn that? Let’s maybe talk that through in the retrospective and say, hey, you know, this person took on all this work. We know we want to get to this team. How can, how can we solve that problem? And you know, I would like to guide them to thinking about coding Katas and those kinds of things. Cause I like those. I think they’re very, very helpful. But I want the team to own it and you know, they may come up with the an even better solution that works for them. Right. So that’s one place I’d like to focus too.
Dan Neumann: [21:53] You touched on something pretty important, which is taking something to the team for determination of kind of where they have the energy, where they have the desire to focus versus maybe a coach or a Scrum Master or a manager’s kind of predisposition to where that person thinks they want them to focus. So that’s really important. And then bringing the data in. And so by bringing the data in you can we make visible things like where we’ve encountered delays, how much context switching was there, where maybe where defects are showing up in the system. Um, where somebody’s overloaded. Cause like you said, you know, if we’ve got an overburdened person who is working on presentation layer, yes, it’s somebody else who doesn’t know that yet will not be as expert. Maybe can’t do the most advanced parts of the presentation layer. Maybe they can start to pick up tidbits. Maybe they can start to do some of the easy things or a take on some other responsibilities that will help move that part of the product backlog item forward, even if it’s outside their specialty. In the spirit of really trying to be effective versus doing the the most, um, time efficient use of everybody’s specialty, which really relates to more slicing and more waiting and more cost of delay.
Eric Landes: [23:12] I love your, your thought of bringing metrics to help the team spot those as opposed to, hey, team, what’s our, you know, what’s our velocity? Uh, but hey, here you had some really great metrics about delay, um, you know, looking at any bottlenecks and, and, and I like that. Just bring that to the team saying, here’s some things that happened this sprint. What can we improve? Let’s, let’s talk about it. So yeah, good stuff.
Dan Neumann: [23:49] So hopefully as people go through now we’ve identified some attributes of what a real team might look like versus a fake team and people can then start migrating more towards the real team, starting to identify maybe what the prerequisites are that have gone unmet and what, what the deterrence to collaboration are and then taking it to the team so that the team can figure out how they want to move forward.
Eric Landes: [24:13] Yeah, I would say benefits certainly of having a real team as we call that include delivering faster but also higher quality and typically the teams are going to be happier going to have happier employees. So, uh, you know, to me that those are all things that we, we strive for. And if you’re looking for, you know, how do I tell if we want to move, if there are ways we can move forward, look for things like being disengaged during those primary meetings or not. A lot of collaboration between daily standups or Scrums. All those kinds of things.
Dan Neumann: [24:55] Sounds good. And if you’re listening to this and you like what you’re hearing, we’d love to hear from you. If you disagree with something, we’d love to hear from you and we’ll put links to the show notes and to some of the materials that will help you identify collaboration opportunities and to differentiate. And that’ll be on agilethought.com/podcast so Eric, what are you reading these days as part of your continuous improvement journey that’s got you a little bit inspired?
Eric Landes: [25:21] You Bet. I am reading. “How to Lead When You’re Not in Charge,” by Clay Scroggins. That’s one I’ve been reading and also, “Training From the Back of the Room,” kind of a classic as a trainer, a PST for Scrum.org I think that’s very helpful to get my classes engaged.
Dan Neumann: [25:44] I think that’s awesome. Yeah, and leadership isn’t something that’s just for the people who are higher in the pyramid and we want lots of different leaders on a Scrum team, maybe within their specialty. So I’ll look forward to hearing more about that from you and for me, I found my book backlog growing this week here at the conference and one of the concepts that one of the best conversations I had this week was was a hallway conversation after a session and it was with Chris Schenkel and the concept of thinking in bets and really how thinking in bets about your product backlog, about your strategy for delivering customer needs can really change the way that an organization decides what they’re going to work on, what they’re not going to work on and how to proceed. So thinking in bets, I got the Blinkist version of that, so I’m probably gonna listen to that real fast before I plow through the like the 10 hours of audio book. But I’ve got to start on that so. Well I want to thank folks for listening and look forward to hearing from people. If you have a topic you want to hear us discuss, certainly send that to podcast@agilethought.com or tweet it with the Hashtag #AgileThoughtPodcast. Thanks again.
Eric Landes: [26:56] Thank you Dan.
Outro: [27:00] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
