Growing People on Agile Teams

Episode 10

April 06, 2011




The Agile Weekly Crew discuss growing people on Agile teams.

Episode Notes

Clayton Lengel-Zigich, Derek Neighbors and Elvis talk about growing people on agile teams.

Deliberate practice

Mentoring team members

Practice new skills



What’s the motivation

Saturated market


Shared goal


Derek Neighbors:  Hello and welcome to another episode of the Scrumcast. I’m Derek Neighbors.

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich.

Elvis:  And I’m Elvis.

Clayton:  Elvis is new to the studio.


Derek:  That’s how powerful Agile is. It can bring back Elvis. So, recently attended the Agile up in the Northwest, in Portland. There were a number of really great topics. One topic that seemed to come up in a couple of different formats was the concept of growing people or mentoring people or deliberate practice to get better. I think that that’s kind of one of the tenants of Agile is continuous improvement and really trying to get better and inspect and adapt.

I wanted to talk a little bit about deliberate practice in areas that aren’t technical. A little bit about what it takes to mentor and grow people. And a little bit about how do you facilitate developers who care?

Clayton:  [chuckles] Easy topics.


Derek:  It would hard to find a five minutes’ worth accounting time.

Clayton:  OK. What was the first one?

Derek:  I think they’re all one and the same. How do you deliberately practice things that aren’t really tangibles? I think you could say, “How do you practice becoming a better coder,” because it’s fairly easy to say, “Here’s what code. Code has an output.”

But if you say, “How do you deliberately become a better communicator, or a better estimator, or better at intuition, or better at leadership,” those things have a lot more difficult outcome to predict. How do you go about deliberately practicing them? The second part of that is, how do you mentor good team members? How do you facilitate developers that really care about the work they’re doing, not just the code?

Clayton:  I think as far as deliberate practice for some of those scenarios that you described, it’s hard to do as part of your work day, because the chances for doing that are pretty limited.

One that I’ve tried to do is really take it beyond my work, and look for opportunities in general life, where I can say, “OK. I’m going to sit down and I’m going to estimate the difficulty of doing this particular task or whatever it is. I’m going to sit there, and I’m going to actually measure it. I’m going to see how accurate was I at predicting how long it took me to do that or how difficult that was,” et cetera, et cetera.

Same with communication is how am I facilitating communication in my personal private life. Am I using that techniques that should make me a good scrum master, a good scrum coach? Am I using those things to talk to my wife or talk to my kids? I think there is plenty of opportunities if you can think outside of the box on ways to practice and exercise those skills.

Derek:  I think I agree that code is an easier one because there’s some output and stuff. I like Jay’s idea of trying to take some of that stuff, what you’re learning, and trying to do that in your normal, everyday life.

One thing that I found that’s kind of interesting is get home from work and wife and I talk about our days and stuff, and a lot of the stuff that I do is of a very technical nature and what’s kind of fun every now and again is just kind of to humor me, she asks me, “Explain that thing.”

So I think it’s interesting to some degree to try and challenge yourself to say, here’s this person who doesn’t know anything about this technical thing I’m talking about, but I’m going to try to explain what the goal is and what the purpose is and all those things.

And I think that when we take that for granted because we come across, it’s like you go home and you are like, “My wife doesn’t know much about this technology, but I’m going to explain it to her,” and you’re a nice guy. But then you go to your client and you’re like, “What a jerk that guy doesn’t know anything that he’s so stupid [laughs] .” So I think that’s a good opportunity just in your daily life.

I’ve got these friends that, they’re curious, how’s work going and things like that. And they don’t understand anything from a technical perspective that I’m doing, but it’s kind of fun time to be able to like, “We’re working on this cool project and here’s the point of it and what we’re trying to do.”

I think seizing those opportunities probably first. It’s hard to realize when those come up, as far as communication, improving your communication. I think just any opportunity you can to speak in front of people or even just answer a question or just anything like that is just kind of finding those opportunities and then doing something with them. I think that’s a really good way to improve on those intangibles.

Clayton:  I think those are good ways of casual practice. I think experiments are really where you going to able to have deliberate practice, so whether that’s taking a different approach to solving a problem within some work problem that you’re dealing with, or lots of people have a side project or things like that, can you apply these things to your side project or test out new theories in those ways and measure the results that you’re seeing against that?

To me, that’s working a little bit more towards a deliberate practice of trying to improve your skills in these areas.

Derek:  Yeah, I agree that everyone has their side projects and I think sometimes we get to a point where we have too many side projects. You go out and say, “I’m going to try all these new things and see what they’re like,” and then you’re not really doing deliberate practice at that point, you’re just kind of goofing off.

I think that is really challenging to say, “Here’s something that I want to deliberately practice and it’s of some value to me and my normal day or whatever, I’m really going to focus on that, I’m not going to start this project and then two weeks from now hear some new other new hotness and then go strike that one in.” You know then by the end of it, you’ve got like five projects that you haven’t actually done anything on.

I think it’s very important that you stay focused if you’re going to try and use a side project or experimentation as a way to practice or learn newer things.

Elvis:  I think there’s a couple of pieces to this that are interesting to me. One is that I think that when I look at really high performers, they’ve learned that, to get more performance, they have to start looking at different things. If I’m a highly functioning developer, I’m really good coder, I do really well with software development, to take it to the next level, I probably don’t have to practice code.

I have to practice other skills, listening skills, problem solving skills, communication skills, different pieces. I think that, kind of to me, step one is if you’re already a high performer is you have to start saying, “What can be a big boon for me that’s not just like a new way of doing the thing that I’m already doing.”

I moved from Java to Ruby. Yeah, you’re going to get a lot of performance potentially out of that, but I would argue that if you’re already really proficient at Java, you’d probably get a lot more performance at learning how to better deal with customers or better understand value of product or do other things that are going to get you a bigger bang for the buck.

I think how do we start to get developers to realize that being the best coder or the best at a particular language or a tool, why not an all‑bad thing isn’t always the best way to succeed. I really actually loved Andre Agassi’s book called “Open.” He really talked about this and one of the big things that one of his mentors really pushed on him is, “You only have to be as good as the guy on the other side of the court.”

I think sometimes when you talk software development, you only have to be as good as necessary to really succeed more than whatever the competitor is and I think sometimes as engineers, we focus on being perfect instead of being well‑rounded enough to beat the other guy.

In his case, the thing that he really lacked was physical stamina. He would pretty much crush everybody through the first two or three sets in a match and he would fall apart in the fifth set. The other thing is mentally he would give up. Mentally, the opponents knew how to get underneath his skin and basically pull him.

For him, to win all the titles that he did, he really had to overcome those two things. It really wasn’t about tennis. He was proficient enough at the game of tennis. It was the other two things.

I think, within a team, part of that is how do we identify the deficiencies in our team and say, “You’re a really good Java programmer. You’re a really great Ruby programmer, but that’s not what’s really holding you back. What’s really holding you back is not understanding the value in product or you’re not understanding how to communicate well with other team members or you’re not testing well or what is that thing that’s really keeping it.”

So that’s part of it, and I think the other part is, in deliberate practice I think that knowing is half the battle, to kind of go GI Joe on it is, I th