Richard Kasperowski on Building Great Teams

1. [...]In your opinion, why are technical skills important in a job?

Ben's full question: This is Ben Linders for InfoQ and I'm here at QCon London with Richard Kasperowski. Welcome, Richard. This morning we're going to be talking about a culture and about technical skills, two important things if you look at Agile. Let's start with the technical skills. In your opinion, why are technical skills important in a job?

Yeah. So I'll just start by saying, when I think about Agile, I think it has two components. You have got the technical skills and you have got sort of the social and cultural skills. Things like the Agile manifesto itself is mostly about social and cultural skills. Scrum is really about social skills and sort of tells you how to behave together in a way, like practices and events that you do together, roles that people play. This is like cultural things. And you can use that to start building a great team and once you have got a great team, you needed technical skills. You need great technical skills to be able to build these products together and that's where things like extreme programming come in.

I think extreme programming is mostly the technical skills or at least that's what I draw from it, pair programming TDD, continuous integration add onto that modern technical skills like continuous delivery, Mob programming even. It's sort of combination and social technical skills. Combine those two segments together and you get great teams that can really build really great software.

2. What are some of your favorite technical Agile practices?

Yeah. When I'm working with teams, these times I work mostly as a coach and trainer. When I share technical skills with teams usually starting with things like pair programming and test driven development, especially refactoring, clean code, these sorts of things, continuous delivery, DevOps -- if I'm just looking at a team and helping a team improve their technical skills are a really good way to do that is to think about continuous delivery. Everything that it takes to get from I wrote code on my machine to its deployed in production or its running on somebody's phone. Can you do that in ten minutes? Can you do that today? Why not? And so map out that stream from my machine to production or just into the phone of my pocket. What are the gaps? Why can't I get that done in ten minutes? And focus on those gaps, improve those areas.

3. [...]What would be the benefit that they can deliver?

Ben's full question: Some technical practices are easy to learn while others can be hard. Do you have one or more example of practices that have shown to be difficult. What would be the benefit that they can deliver?

Yeah. In a way, they are all simple and they are all difficult. Even something as fundamental as test driven development, people resist it. It's not how they learn to write a code maybe and it's even hard to get them to try it. I like to set up things like the coding dojos, coding dojos kinds of situations, or work on a coding kata together with people, have them work on a fairly easy problem so it's less stress. It's not a work problem. Again, so it's less stress. You don't have to worry about this new kind of code going into production and it helpa people build up their technical skills from there. It's sort of easy problems in group settings. It's low stress. It's social. It's a really good way to learn things.

4. Do you talk about the benefits of technical practices when you try to help people to get them done?

Yeah, sure. So benefits in extreme programming, I talk about things like if it's good, turn it up. Turn up the good. My friend Woody Zuill has always been reminding me about this. Turn up the good. If testing is good, then you kind of do it all the time, right? Turn it up. Do a testing all the time. Test first if people have been talking about this in extreme programming for 20 years, maybe more than 20 years. If code review is good, you do it all the time. So it's pair programming and everybody does code review and everybody complains about code review. So you just do it all the time. You do it as pair programming.

Integration is good. Big integration is hard, so you do it all the time. Turn up that goodness of doing little integrations all the time. Delivering to production is a good thing. It's probably the best thing of them all, right? That's where you get the most value. So try to do it all the time. It's continuous delivery. These are the benefits like you want deployment to production to be easy. Let's do it all the time. Let's do it like you commit some code and get and it runs through the pipeline or it gets to production and it's easy. These are some of the benefits.

5. Any advice that people can do to increase their technical skills? You mentioned Dojos already.

Yeah, Dojos are a great idea. It's an idea I picked up on. I'm not the inventor of practically anything. I'm kind of thinking of myself as look at the blues musician sometimes. A good blues guitarist will steal riffs from other people and start to make them his own and this is what I do. This is what I think most coaches do. When you see something good and you can take it, you take that riff and you adopt it and make it your own. So coding Dojos, create an example of that. Get people together in a social setting outside of the usual work. Have them work on a problem together, teach them some skills, some new things while they are doing it and have them build up their skills together.

I also do this with kids in Boston where I'm from, I help run a coder Dojo for kids and sort of teaching kids how to write a code well right from when they're seven years old, even younger sometimes. And I even teach them pair programming and test written development without telling them that's what I'm doing. I'm kind of getting them to use these Agile technical skills right from the start.

6. [...]Can you describe what you mean with great teams?

Ben's full question: So let's hop over to the cultural part. Can you describe what you mean with great teams? When are not teams really great.

Yeah, so great teams. What's a great team? And I kind of laugh sometimes because I'm American. Sometimes people accuse me of using the word great too much. I overuse it. Maybe I do. Maybe we do in general. What I mean by great teams is teams that can deliver great results, teams that can deliver the results they want when they want. When I launched myself into this role as Agile coaching and trainer, I didn't really know what I was going to do. I didn't really know where I was headed because we didn't know that I could do this so that I would succeed doing this. I just had this intention that I do great things with great people. That sounds good.

To take that into software, I built great software with great people. That sounds really good. Great software teams deliver great results when they want to. When they want to, they deliver incredibly creative products, incredibly creative solutions. They take the collective genius of the team. If you take every team member's individual genius and add them together, that would be good. That's a high level team intelligence but on really great teams that collective genius is sort of multiplied or even exponentially. Its way more than some of the individual intelligences of the team members, so that's what I'm talking about.

Also a lot of my culture work is influenced by the work in Jim and Michele McCarthy, so their work in the core protocols. I like to use Jim's definition of great. It talks about good. So good is the attainment of what you want. You get what you want, that's good and great. That's like abundant goodness. So lots and lots of attainment of what you want. Lots and lots of good. That's great. And when teams do that, well that's great. Things deliver great products when you do that. And you know a great product when you see it. When you see a great product rest assured there is a great team behind it.

7. You mentioned the core protocols already. Can you briefly describe them?

Yeah, sure. There has been some interesting press recently. A couple of weeks ago, the New York times, there was a news article about people analytics at Google. They started sharing some of their research and findings last Autumn. In the New York Times article and on Google's re:Work website, they talk about -- they are interested in high performance teams at Google and they have been doing research on their teams or into their teams to find out what team characteristics correlate to high performance. What they have found is they call it general psychological safety, so people feel safe on their teams. People have a high level of trust, there is a high level of empathy between team members. They have cultural norms on these teams. So people sort of know how to behave on their teams.

And in Google's findings, they have even said that psychological safety, good cultural norms things like this. They trump team -- they trump individual technical skills. A team that has high technical skills, that's good but a team that even has lower technical skills individually but higher teamness, higher team culture, higher psychological safety, those teams out perform every other team at Google. So this is what I have been reading in the press. I'm not inside Google so I don't know what people inside Google say about this.

The other interesting thing about what I have been reading in the press. I'm not inside Google, so I don't know what people inside Google say about this. They know what characteristics correlate to high performance teams but they don't really know how to make it happen reproducibly, right? So they know like if you have got team members who have high empathy, you have a high performance team but aside from maybe testing people for empathy and putting them together, they don't know how to do it. They don't know how to teach empathy. They don't know to teach psychological safety as far as I can tell.

Ben: They don't know how to develop it.

They don't know how to develop it on purpose. It's like find a manager who has high empathy skills and put them on the team and maybe the team won't be high performance. But what if you could teach these things? What if you could teach empathy? What if you could teach psychological safety? What if you could teach high trust? What if you could teach cultural norms that correlate to these high performance teams? So that's what the core protocol is. Again this is the work from Jim and Michele McCarthy. It is the work that I have been sharing a lot over the last year and more. I have written a small book on it. This is what I'm teaching later this week at QCon. This is what I teach a lot to teams. Teach teams these protocols, these behavior patterns that can learn to build this psychological safety.

8. [...]Any suggestions how to deal with that?

Ben's full question: "Ask for help" is one of the protocols described in your book and my experience is that a lot of people find it difficult or are reluctant to ask for help. Any suggestions how to deal with that?

Yeah. Ask for help is a hard one. It may be the most important skill that people can learn. So when I share core protocols with people, when I share these behavior patterns for successful teams with people. I have sort of -- oftentimes, I'm working with software teams, technical teams and technical teams understand the concept of an application stack or protocol stack. So I do it as a stack. I tell them the bottom layer of this stack is positive bias. So this is a bias toward adding on to each other kind of like improvisational theatre. Instead of destroying, we add on and we make things better. So that's the positive bias there.

On top of that, a layer of freedom or autonomy and this layer is -- this helps build psychological safety because people are free to be part of a team or not. Nobody is forced to be part of a team. Nobody is forced to play a role they don't want to play. Nobody is forced to do any activities they don't want to play or that they are uncomfortable with. So that's the first two layers. On top of that, this layer of self-awareness. To build a great team, you need a bunch of great individuals. Great individuals have self-awareness. So they know their emotional state and they can share it with each other, empathy. They know what they want and they can ask for it from each other. So this is like what's your goal? What's your purpose? It's another thing that goes into high performance teams. What do you want? Asking for help, knowing that I don't know something and that it's safe to say I don't know something on the team. And asking for that help, maybe getting it, maybe not because nobody -- because we have autonomy and freedom and not forced to give you that help and that's okay.

So those are the three foundation layers that I think that -- I do it as a six-layer stack. Asking for help is really hard in most teams because they don't have that safety. It's not safe to say you don't know something. On many teams and in many corporate cultures, if you don't know something, you get punished. If I say I don't know something, that goes on the left side of my performance review and I get punished for it when it comes time for my boss to decide whether I get a raise or whether I get fired, right? And people know this. People are trained in the culture in which they're working to know that it is safe to ask for help or it's not and in many company cultures, it's not safe to ask for help. It's not safe to say that you don't know something. That's kind of -- that makes me sad and kind of angry.

People aren't allowed to learn things in many company cultures. They are not allowed to say they don't know something. They are not allowed to ask people to help them learn something new. Those teams cannot be high performance teams. Those teams cannot be great teams. So asking for help is like one of the most important things anybody in any team can learn and making it safe to do so establishing these cultural norms maybe using core protocols as the cultural norms. This is a great way to build that psychological safety. Take that layer of self-awareness, build on top of that, a layer of connection, so you have got people who know what they want on a team, people who can express vulnerability, people who know what they want and can share what they are feeling and connect them together into it, a great team, this is what we want.

Now they are a great cohesive team. There are protocols for these behavior patterns that teams can adopt for this, fifth layer of the stack productivity. So there are things that teams can do to be very productive, very efficient and go very fast like a protocol, decider protocol for a very fast decision making together. I wanted him to be great, make fast decisions together and make them 100% unanimous consensus decisions. So everybody is in on it together. You want a team to go slow, have decisions that are not unanimous and people sort of fight against each other. There would be a lot of internal friction on the team. If you want your team to go fast, there is no internal friction. They are all going the same direction together. You can even add things like Scrum and XP there in the productivity layer.

So you have got this great cohesive collection of people all going the same direction together. Now add the other Agile skills to it and then at the top of the stack, it's at the top layers of sort of in an error handling kind of behavior pattern or it's okay to remind each other that it's okay to ask for help for example. And that ends up being a great set of behavior patterns for teams to build that psychological safety, build high empathy and so on and get into that high performance state.

9. [...]Do you have an experience for the perfection games that you can share?

Ben's full question: Another protocol is "perfection game" and I used it in Agile retrospectives and know conferences who use this to review submissions. Do you have an experience for the perfection games that you can share?

Yeah. So perfection game is the best way to give feedback to each other and it's by invitation. It's not forced feedback because again we have got this layer freedom of autonomy. Oftentimes people will ask for help. Will you play a perfection game on my code for example? I have seen teams use perfection game to do code reviews together. Here is a piece of code, let's play perfection game on it and it becomes less about the person I don't feel defensive when people are playing perfection game on my code because we're talking about the code and we're saying what we like about it, not just what we don't like about it. We have got this positive bias. So it's the foundation there and all.

So we say what we like about the code and then we say what it would take to make the code a 10 out of 10? This is totally different from saying what I don't like about the code, just what I like about the code and what it would take to make it even better. So there is a good example of perfection game. I also see teams use perfection game if they're doing Scrum for example and then do a retrospective at the end of their sprint. They play perfection game on the team for the last two weeks for the duration of their sprint. Let's get every team a score from one to ten. How close were we to being the best team ever?

Okay, so we got a score and maybe it's like seven or eight. What were we doing that worked very well than had a conversation, a list of things that was going really well for the team. Oh, and you can turn up the good on that, you can amplify those good things. And finally, what would it take to make us the best software team ever? And then you have got some things you can add to the team to make it even better. Perfection game is a great tool to use for making a thing better, for making a team better.

10. [...]Can you share some ideas for coaches to help teams that want to increase trust?

Ben's full question: Okay. Trust in teams is important and I have seen many teams at that lack trust actually. Can you share some ideas for coaches to help teams that want to increase trust?

Yeah. For a coach to help a team increase trust, consider sharing core protocols. That's the way to help teams build up trust and safety. Try modeling these things that you want teams to do. As a coach, teams are kind of limited by you in a way. Like if you are a manager, teams are limited by their manager, trained by their manager's abilities. As a coach, the teams are going to do up to the level that you show them. So if you come into a team and check in with your emotions, tell them you are happy about something or sad about something or angry about something or afraid of something. That's interesting and that will help create a space of safety for them to do the same.

If you are a coach and you come in and you admit that you don't know something and you ask them for help, that will create a space that says it's okay to be vulnerable. It's okay to say you don't know something. It's okay to say you want to learn and maybe they'll do the same and you can also share things like perfection game. You could ask them to perfect you as a coach. Hey, team. I have been working with you for two weeks now. Will you play a perfection game on me? And it's really like how can I help you more and they'll tell you, right? So you can use these tools. You can model these of these sorts of tools to show teams how they are used and to show them that it's okay to use them, safe to use them and you get better results when you use these kinds of tools.

11. What if teams seem to be unable to take action, for instance after they have done a retrospective? Any suggestions how you can coach teams to get improvements done?

Yeah. So what if teams are having trouble making improvements? I love this idea of turn-up the good. Teams are always doing something good. It's kind of like some of my initial coaching training was with children playing soccer and football. Before there were a lot of coaching certifications for Agile coaches, I used to joke with my friends that I was the only certified coach in the room. I was a certified soccer coach, right? And I learned a lot about coaching adults by coaching training for children and a lot of it is just look for what's good, look for they're doing well and tell them, help them know what's going well and they'll do more of it. If you are with kids and you tell them what's going well, they'll do more of it. They'll feel really good about it. If you tell them what's going wrong, if you tell the way you were touching the ball was bad, they'll stop touching the ball, they'll stop playing the game.

So you tell them what's good and they want to do it more. It works with adults too. it turns out because we're all humans. Notice what's going well or help them notice what's going well, help them turn up some of that good. Another good idea for a retrospective is to find one thing, just find one thing to improve. One thing to either turn up the good on or one thing to adjust, make a plan for it and make it -- have some accountability on that plan and we're kind of looking forward as a team. Let's make sure we get it done. We have got two weeks to get this one little improvement done or one big improvement done. Two weeks is a long time. We can do one thing in two weeks. It usually works.

Ben: Get them to focus on one thing if you want improvement.

Yes. Yeah, you got to focus on one thing to improve. Many teams make a list of 20 things that they think are going wrong that they should change, that never works. Just find one thing that you want to do better either correct or turn up the good on, one thing, focus on and you can get it done.

12. Where can be people go if they want to learn more about the core protocols and find ways to use them in their teams?

Yeah. So the core protocols, I clever it with a group of people called the Greatness Guild. You can go to our website, greatnessguild.org, another URL for the core protocols, thecoreprotcols.org, easy to find them. You can also find information about the core protocols in my book. It's called "The Core Protocols" and it's very, very concise. I created the book so that people could carry a print version of the core protocols in their pocket. Also check out the books from Jim and Michele McCarthy. They are like the economical books about it. Their book "Software for Your Head" and their book "Dynamics of Software Development, these are the places to find the origins and the rationale behind core protocols.

Ben: Thank you very much, Richard for the interview.

Thanks, Ben. This is great.