James Shore: How to Build Super-Cohesive Teams and Work with Joy

Richard:

Our guest today is James Shore. Hi James. Welcome to the podcast.

James:
Thanks for having me. I’m happy to be here.

Richard:
Yeah. Great. I’m really happy to have you here. Can you introduce yourself to our listeners?

James:
Yeah, I’m a software developer turned consultant. I’ve been doing this consulting in the agile space for about 20 years. And what I do is I help companies figure out software development effectiveness. So particularly smaller companies that are growing that are finding that as they grow, it’s harder and harder to develop software the way they know, they used to know how to do, I help them out with that. I also wrote a book called The Art of Agile Development and I co-created the agile fluency model and co-founded the agile fluency project with Diana Larson.

Richard:
All right. And I’m hoping we’ll hear more about that as we go, the agile fluency model, the agile fluency project, I’m very familiar with. I’ve known about it for a, I don’t know, I think since you guys started it.

James:
Yeah. We started it back in 2011, 2012 is when the article first came out.

Richard:
Yeah. All right. Now this is a podcast about teams and best teams, the best team of your life. As you reflect on yourself and your life, what’s your best team ever, and this is not constrained to work, this could be any group of two or more people you’ve been part of, what’s the best one of those of your life?

James:
Yeah. Well, as a consultant, particularly one who does a lot of embedded immersion consulting, I’ve worked with a lot of teams. And so when you sent me this question in advance, I had to really think about it because there I have worked with a lot of teams and the best one ever is kind of a big ask, but I would say that the best team I’ve worked with was at a company on the East Coast that developed a financial software. And they brought me in because they wanted to do a rewrite and they were going to do it right this time, that’s what everybody says when they do a software rewrite. And it ended up being a really … it was a great team to work with. I loved working with them. They sent me a nice gift afterwards actually, Guitar Hero, I don’t know if you remember that game.

Richard:
Cool. Not only do I remember it, but I’ve been dreaming about it so much lately. I want to get some Guitar Hero controllers again.

James:
Yeah, I actually just last year gave them away, like gave away the old PS2 and I regret it now, but yeah. So we got along really well and they were also just really successful afterwards. When I joined the team, there was maybe six, seven people. I don’t remember the details now, and after we worked together, their product was really successful, they grew. They grew to being about four or five teams, all working very closely together and eventually were bought out by IBM who I think killed them, but it was a great experience. And I think of all the teams I’ve worked with, they’re the ones who I think were the best. Although it’s a tough call.

Richard:
All right. And now that this is, I don’t know, this is interesting. It’s a little different, most people are sharing with me stories about a team that they were in sort of like a first-class member of, they were all peers. So this is a special one that we’re talking about today. This is where they hired you to help them be an excellent team.

James:
That’s right. Well, they didn’t hire me to help them be an excellent team, they hired me to help them do excellent software development. And like I said, I’ve been doing consulting for 20 years, so all my stories are going to be stories where I was a consultant brought in because 20 years ago, I didn’t know hardly nothing. And I know a little bit more now, but maybe still hardly nothing.

James:
But the thing is, is my favorite way to work, my first experience, so I don’t know how much your listeners know about software development and agile development and so forth, but I first got into agile development through something called extreme programming. And that was a team that I was actually hired in as a contractor, but I was still a member of the team. And that was not necessarily the best team I’ve ever worked with, but it was my favorite team experience of my life. And it sort of ruined me for doing work in any other way.

James:
And I would say that in a way, my career has been about reproducing that experience. Because when you work with a great team, with a jelled team, there’s this experience of every day you’re excited to go to work and every day you’re looking forward to working with these people. I mean, there’s some good days and bad days, like anything, but overall you’re really looking forward to working with people. And eventually these teams always break up for some reason. And there’s this model called the Tuckman Model of Team Formation, you’ve probably heard of it, it goes like this forming, storming, norming, performing, and then mourning or-

Richard:
Ajorning.

James:
Or ajorning.

Richard:
What do you say with the writing accent?

James:
Yeah. Sort of that Shakespearian ajorning.

Richard:
Ajorning.

James:
Yeah. And so when that team breaks up, there’s this period of regret. And I’ll always remember that first team. And that was my second choice, when you asked me for my best team, but I don’t think they were actually the greatest team I’ve worked with, but it was a great experience for sure. I mean, that was 20 years ago and I would say in my consulting career, what I really just wanted to do is reproduce that experience. And unfortunately I can’t really, because I’m brought in to help a team really become great and do great work. And then by the time they’re there it’s time for me to leave.

James:
But the work I do is my favorite type of work is where I’m joining a team and I’m embedding with them and I’m there as a peer. And I’m a peer who knows something that the other people on the team don’t, but they also know things I don’t and really being successful and really doing great work requires that we all act as peers. And that’s actually, I would say one of the lessons I have about being on a great team is that you can have people with different levels of experience, but you’re all there as peers, you’re all working together to create a great result.

James:
So for this team on the East Coast, yeah, I was brought in because I had special knowledge about extreme programming and software development. For those of your listeners who are not familiar with agile development, extreme programming was invented in the nineties and that’s where the name came from and I’ll just leave it at that. But it’s actually a really, really nice way of developing software despite the name, not because of the name, but despite the name. So, yeah, I had some special knowledge, but that’s not what made the team great.

Richard:
All right. Well, let’s go back to this team, if you can take yourself back to it, sometimes people close their eyes and sort of re-dream of being a part of this team. If you took yourself back to those people and the activity you were doing together, is there one word that you could use to describe the sensation of being part of that team?

James:
I would say if I had to choose one word, I’m going to choose two words to answer this in two different ways. One word would be open-minded and another word would be comfortable. The second word, that’s what I’ve seen, I’ve had the blessing to have been on several teams that were just really good teams and that comfortableness is the common factor in all of them. This one team I’m thinking of in the East Coast, I would say open-mind was what made them great. But being part of a great team, it’s this comfort and a sense of belonging and a sense of really being happy to be part, be working together on this.

Richard:
Okay. So this East Coast team that we keep telling, we’re going to call them at the East Coast team.

James:
Yeah. I don’t want to say the name of the company, because I don’t know if somebody might be offended.

Richard:
That’s cool. Subjectively, how do you know it was a great team?

James:
Subjectively, it’s really hard to say. It’s one of those things like, you know it when you see it, but it’s hard to describe. But I would say one of the things was that everybody got along really well. Some of the people on the team, I don’t know if this was true before they were members of the team or not, but some of the people in the team were friends, but they were also very welcoming to everybody else on the team to join them. And this is how I ended up with a set of Guitar Hero because we would occasionally go over to one of the team member’s houses and play Guitar Hero and so forth. Now that doesn’t mean that you need a team where everybody is interested in video games or ping pong or drinking or whatever the team activity is, but it wasn’t just that everybody got along, it’s that everybody was trying to bring the others into the group and not excluding anybody. They were really focused on creating a good result together, they cared about creating a good result. And subjectively the way I knew they were a good team as they stuck together longer than average, I think they stayed together until IBM bought them and killed them or killed the company even, I’m not sure.

Richard:
Just so listeners are clear on those, IBM did not kill the people on the team.

James:
I suppose. Yeah. Yeah. We should probably clarify that. To my knowledge most of them are still alive, yes. Yeah. So they stick together. So there’s another sort of subjective metric, but most of all, it’s the way it felt being on that team. And that’s, I think nearly impossible to describe.

Richard:
I love the way you’re talking about that, the way it felt. I’m also curious about curious about the, you mentioned the Tuckman model, you just mentioned something about, they stayed together longer than the average team. What do you think about this? What is the average team lifespan? How much longer was this team’s lifespan?

James:
Yeah, I don’t, that’s why it’s subjective because I don’t have numbers around it. But in software development people tend to hop jobs quite frequently. It’s rare to be in a job more than two to three years. And the folks on this team, they were still together when I went to visit them again, five years later.

Richard:
Wow.

James:
They had grown, but I think all or nearly all the people who were part of that core team are still there and still playing a leadership role.

Richard:
Yeah. All right. So that is unusual and special. And this is an objective thing, some sort of objective indicator that this was a special team.

James:
It is objective in a way, yeah.

Richard:
Are there any other objective signs that this was a really great team?

James:
I don’t have any concrete metrics. I’m not a big believer in metrics to begin with, which would be a whole nother conversation, but they tend to lead to dysfunction. But I would say that some objective measures or signs is that the team was very successful. I mean, they did grow. They grew into from one team to four or five teams. I think they had, I mean, I started out, there were five or six people on the team and when I went back to visit them again, five years later, I think they had 20, or maybe 30 people. They were acquired by IBM and their team developed product, this was a small product oriented software company. So their team, they were acquired by IBM on the strength of the product that they had built.

James:
And several of the team members, I still, I just gotten a bunch of them actually, coincidentally, all independently contacted me last year. So I’ve recently talked to a bunch of the people that were on that team, 10 years later and they’ve all disbanded, but they’ve gone on to become leaders in their community, leading software development meetups, and so forth and leaders in other organizations. And what they’re doing is they’re teaching people how to do what they did on that team. So I would suspect, I haven’t talked to them about this, but I suspect they are probably all regretting that that team no longer exists. Just as I regret my first team no longer exist.

Richard:
Exactly. And maybe they’re on this quest again to reproduce that, the specialness of that team.

James:
Yeah. Yeah. I mean, I think that’s one of the ways you can tell that you were really part of a great team as if 10 years later you find yourself thinking, man, I just want to create that team again.

Richard:
Yeah. I think we’ve discovered something right here. How do you know it was a great team, because we want to reproduce that.

James:
Yeah. Yeah.

Richard:
What were some of the concrete behaviors that this team engaged in that, that led to their success?

James:
One of the ones that I think was non-obvious was that they had a really good manager and that manager allowed the team to self-organize. Some managers sort of hold themselves apart or above the team and they’re there to tell the team what to do or to judge the team members and decide who’s deserving of what. And to a degree that is the job of a manager, but what this manager did was he really allowed the team to self-organize. He engaged as a member of the team, he wasn’t hands-off, he was a member of the team. He was focused on the product outcomes that the team working on. So he didn’t develop software with the team, although, and I don’t know if he had a software background or not, a software programmer background, but he was definitely a full-time member of the team, engaging full-time with a team, thinking about where’s this product going and what do we want out of it? But he did that as a peer. And he did that as somebody who respected what the team was creating in terms of their team dynamics. So that’s one.

James:
Another one was that the team members really took ownership of their process, so the way they worked, and the outcomes, the success. Again, now they didn’t necessarily have the domain expertise that the manager did, but they really cared about creating a good result. And they were all dedicated to working together to create that result. And I think that’s one of the things you see from a really solid team is they’re not a bunch of people working in vicinity all on their own projects, they were working on one thing together.

James:
And then the third thing is, and this is maybe a little egotistical of me, but I came in with all these disruptive, extreme programming ideas, not only were they disruptive ideas, they had a silly, stupid name and they agreed to try them and withhold judgment for six months, which is something I always ask the teams that I’m going to work with in this sort of immersive way. So they agreed to do this and they did it without a lot of, if we must or what I see with some other teams, as they say yes, when they cross their fingers behind their back and the next six months is pulling teeth to get them to actually try it. Now, they said, “Yeah, we want to experiment with this. It’s a little out there. It’s a little weird. We don’t know if it’s going to work and yeah, let’s do it.” And then they really did. And that sort of, when earlier you asked me what is one word? And I said, open-mindedness, and I think that wasn’t the only reason for their success, but it was really a reflection of what made them successful, may not have been caused it, but it was certainly correlated.

Richard:
All right. Now you’ve been on this quest to reproduce this best team that you were a member of from way back, your first extreme programming team. I’ve been on the same quest with similar experience, an extreme programming team. What do you think listeners could do? What’s your advice to listeners to reproduce the success of this team or any of the excellent teams you’ve been on in your life?

James:
Yeah, that’s a good question. It’s funny that you said that you had been on a similar quest and your first and that experience was an extreme programming team. So somewhat tongue in cheek, maybe the answer is everybody just needs to do extreme programming.

Richard:
Everybody has to go back in time to 20 years ago and do extreme programming.

James:
Yeah. And you got to get the nineties haircuts and the surf boards.

Richard:
All right, mullets and the white extreme programming book.

James:
Yeah, that’s right. More seriously, although it’s funny, I talked to people who were involved in that early XP movement, and I hear a lot of people saying, “Wow, that was a great experience.” So maybe there’s something to that.

James:
But if I were to separate it from the specifics of software development, I would say that if you want to reproduce that success, first thing I would do is I would pay attention to team dynamics and specifically what people in the biz call psychological safety. So make sure that everyone is safe to express their opinion, but not only that, to also experiment and to fail, because if it’s not safe to fail, it’s not safe to experiment. If it’s not safe to experiment, you can’t make things better because you can’t make things better by only doing sure things, you can make things, or at least you can’t make things great. I imagine you can make it better, but you can’t be great if you’re not willing to experiment and try new things and fail. And if it’s not safe to fail, then it’s not going to happen.

James:
And I think that’s one of the things that the manager on this team was really good at. Like I said, he was part of the team, not over the team and he made it safe for people to take ownership. And as you’re doing this, if I’m laying down advice from upon high, as you’re doing this pay particular attention to making it safe for people with non-traditional backgrounds. So people who have different demographics or went through a different college or non-college experience, or some of the great programmers have music degrees and or history degrees or psychology degrees. Or most of the programmers sadly are white males, so you might have people on your team who aren’t white males. Those folks are going to have, likely are going to have different experiences, whether it’s educational or demographic and what is makes it safe to fail for people who are, don’t have a common experience with the rest of the team is different than what’s makes it safe to fail for the people who are sort of in the mainstream of the team’s experience.

Richard:
Right. All right. Thanks for that.

James:
And I did have another one.

Richard:
Okay.

James:
Another one was, and I think this does sort of get back to the XP ideas, whatever industry you’re in, prioritize learning, skill and ease. This team on the East Coast that I worked with, they set aside half a day for research every week where people could work on anything they wanted, as long as they were going to be able to present on it the next day at lunch and it wasn’t anything related to their day job or not anything related to the production work. So typically people would do coding research, but it could not be checked in, it couldn’t be part of the software that was being built.

James:
And they also worked really hard on their software fundamentals. And this is what I came to help them with, software fundamentals are things like if you’re in software test driven development, evolutionary design, communicating through code, they really worked on being very skillful in those areas. And in software these days, if you want to get a job in software, you have to go study something called Leet Code and do all these puzzles, these coding puzzles, but that’s not what this team was good at. They were really good at the fundamentals of communicating well, not the puzzles that people do to get hired. And I think learning and skill are two of the things that any team needs in order to be really great.

James:
And then third is ease. They were constantly looking at how could they improve the way they worked as a team to reduce overhead, to make the things that were important less friction to do and less time spent on what folks in software call yak shaving. That’s where, when you want a blanket, but you realize that you’ve loaned it out to somebody and now you’ve got to do this, now you got to do that and next thing you know, you’re in Cambodia, shaving a yak, trying to get yak hair to get your blanket. Reducing that sort of friction is also something that I would recommend for anybody trying to create a great team. So the team can focus, the team really focuses on reducing that friction so they can spend the majority of their time doing what matters.

Richard:
Beautiful advice. Is there anything else you’d like to add, James? Anything you’re passionate about lately? Anything you’re working on lately? Anything at all?

James:
No, I don’t think so. Other than maybe a little bit of shameless self promotion, which is that I love doing this sort of work. I just love working with teams. I love helping companies figure out how to solve the problems that are preventing their teams from growing and being more successful. And I tend to work with the smaller companies and it’s rare to get the opportunity to really embed with a team. So if anybody’s listening to this and would like that, I would love working with you because it’s just so much fun.

Richard:
All right. And I can tell, I have an objective or subjective, I don’t know which point it is, way to gauge that you really love this. As we talk to each other, I have this sort of like feeling in my belly that I just am enjoying this conversation so much that just because of the passion that I can feel sort of coming through the screen as we talk to each other. And if listeners would like to get in touch with you, maybe take you up on that. How would they do that?

James:
My website, world’s ugliest website is Jamesshore.com. You can tell a programmer built it. And I guess I’ve just been lucky enough to have been too busy to make any changes for it. So Jamesshore.com will, there’s a contact me link, you can find out more information. Or if you want to email me directly, it’s Jshore@Jamesshore.com. I only work with software teams. If you’re in the software world and you’re not necessarily ready to take the leap of contacting me directly, but you’re interested in some of what I’ve learned from building software, check out the agile fluency project at agilefluency.org and all kinds of insights there that Diana and I came up with about how software teams tend to grow and change over time that I think you might find pretty useful and interesting.

Richard:
Definitely. I’ll second that I love the work of the agile fluency project. Thank you for sharing that with the world chance.

James:
My pleasure.

Richard:
All right, James Shore, thank you so much for joining us today. It’s been a lot of fun for me.

James:
Yeah. It’s been an absolute pleasure. Thanks for having me on.

Richard:
Hi friends. Thanks again for listening. And remember to support this podcast, visit my website kasperowski.com.