Roy van de Water and Clayton Lengel-Zigich discuss:

• A Culture of Learning
• Fear of Failing
• Having too much fun?

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the Agile weekly podcast. I’m Clayton Lengel‑Zigich.

Roy van de Water:  I’m Roy van de Water.

Clayton:  Today, we’ve got some topics for you that come straight from the trenches. I’d also like to point out that it’s the 100th episode. Although, if you were to add them all up, we probably missed a few, so this is probably, really, 96 or something.

Roy:  That’s true, counting as one of our strong suits, and our special episodes, and then there’s all the other episodes that we recorded but lost.

Clayton:  I would encourage you to go back and listen to all of them, and check, and see if we’re right or not. The first we’re going to talk about is kind of an interesting thing where you’ve got a team, and from what I understand, they make a working agreement that no one can work as a silo. They have to be working with someone, everything.

There’s a problem when there’s the odd number of people. How have you guys been solving that?

Roy:  Our solutions for the last few months has been to do something that we call trying.

Clayton:  I’ve also heard stooging for three people, because it’s the three stooges.

Roy:  I was thinking of the third person as a stooge. I don’t really have a high opinion of it, based off of the experience I’ve had with it, because I’ve actually joined in on some of them. I’ve actually been one of the three on the tri. The common pattern of what I see is, there will be two people working and one person watching, because we do the two keyboard pairing.

When you have two people working, and one person watching, the one person watching is not really usually contributing. In some cases they contribute a little bit, because they happen to be the person who has the knowledge but if the primary knowledge holder is the one that’s driving, forget it. The person that’s in the back is going to stay there, and is going to be nodding off before too long.

Clayton:  I’ve heard a lot of people that try and defend this sort of thing. They make it sound like it’s really easy for everyone to be engaged, and they can learn a lot just by watching, but I don’t think I’ve ever seen that in practice.

Roy:  All I can say is for me, personally, I can’t stay in [inaudible 01:55] . I am not physically capable of it. I tried today. Today I was doing some tri‑pairing, earlier today, and I was peering over the other two shoulders, going like, “Hey guys.”

Clayton:  You felt like you were in the back seat?

Roy:  Right. I felt like a voyeur, watching two other people code.

Clayton:  The thing I always think about when I hear this sort of thing or people suggest this is they haven’t really done pairing. I think if you’ve really done pairing, and you know what it’s like to have that back and forth, you know that it’s impossible to have a third person there.

Roy:  I’ve heard of people taking it to extremes, and doing mob programming. I couldn’t imagine having five people. I can’t even do it with three.

Clayton:  The thing that’s different about mob programming, at least, is that there’s one person driving and everyone else is participating.

Roy:  That’s true, everybody else is just shouting along. That’s true. You’re not the odd man out at that point. You’re the odd man in.

Clayton:  Right. I think it makes a difference, at least from the pictures I’ve seen, from mob programming, there’s usually one person in the front, and the other people are behind.

Roy:  Maybe, we should switch up our mob programming, or, trying strategy, and, instead of two people behind, one person up front, on the keyboard.

Clayton:  I think space is a limitation. Not everyone has the perfect set up for pairing, let alone a set up where you can see over someone. It’s like you have stadium seating.

Roy:  That’s true. When I’m in the back way off to the side, I can’t read a thing, even if you turn the font size up.

Clayton:  One thing I’ve heard, you’ve mentioned, and I’ve heard other people say this, and I’ve kind of hinted at it, it’s a good way to learn. But that’s not necessarily the team trying to have a culture of learning.

Roy:  No. Originally, it was. Originally, the problem was we had silos on particular stories, and we had a problem with cherry picking as well, that nobody would call that on because the team was still in the forming stage. You’d have a story about a particular technology, and somebody would say, “Well, I’m familiar with that. I’m going to go ahead and take that and work by myself.” Then nobody else would have the knowledge to transfer. This was to combat that, and I think it was really effective. Originally, I think, it was probably a necessary step for us at first.

Clayton:  Do you think it has helped people that have a skills gap, and close that skills gap? Or, do you still see the same people that started out with a gap, are they still in that same phase?

Roy:  That’s a good point. It depends. Some people still have a bit of a skills gap. I think pairing is a really great tool for teaching, and for learning. But only if everybody is actually in it for that. You know what I mean? It can also be a really great tool for, “I just want to coast along. I’m just going to pair with a bunch of people who do all the work, and then I never have to do anything.”

Clayton:  Especially, if you’re not driving. If you’re the guy in the back, you can pretty much get by, by just seeming like you’re pairing.

Roy:  Especially when you’re driving, it’s actually probably easier to get away with that. You can just blindly stenographer everything somebody else says. You don’t have to understand everything that goes on.

Clayton:  That’s a good point. That’s one of those things where I think if you’ve got someone who’s driving that maybe does have that skills gap, as the navigator, you have to find some creative ways to guide them towards the right direction, but not necessarily tell them what to type, right?

Roy:  That’s true. It’s difficult and it’s frustrating, because I’ve paired before with people like that where they sit there and look, and like, ” [inaudible 05:13] . Tell me exactly what to type.”

Clayton:  Or, they kind of act frustrated. But I always wonder, do they just have a fear of getting it wrong? They’re just afraid to fail, and so they wouldn’t start?

Roy:  I’ve been part of a team before, where two people are pairing. One person was a junior developer, and the other person was a senior developer from back when they had titles. I saw the junior developer do something, type something out, make an attempt at it. I don’t even remember the specifications of it. It was pretty basic, he took a stab at it, and took a paradigm from one language which works in that language, but doesn’t work in this one or something.

The other person was like, “Oh, you’re so stupid. I can’t believe you just did that.” Made everybody from the team gather around and look at it and be like, “Look what he just did.” It’s like that person never took any risks anymore after that, like, “I’m not typing anything unless I know for sure it’s correct.”

Clayton:  You were talking earlier about the concept of acting stupid so you don’t write dumb. I thought that was interesting. Explain that.

Roy:  Yeah, the idea behind that is instead of trying and looking dumb, and everybody makes fun of me for being dumb. I’m instead going to be dumb on purpose that way nobody can really make fun of me, because I’m the first person to do it. You know what I mean?

Clayton:  They can’t make a joke about it?

Roy:  Right. It’s how you would work with a bully at school. You would be like, “Well, I’m going to make fun of myself first, and then that way the bully can’t make fun of me for it.” That is really effective, and maybe the core problem isn’t the person being bullied, maybe the problem is the bully.

Clayton:  I think on that team, if the team chastises someone for getting it wrong, that doesn’t necessarily sound like they have a learning culture.

Roy:  Right, but we used to have this culture at Integrum. Remember when we would have fun with that. You, Jade and I all the time, if we catch each other doing something stupid, we’d be like, “Hey, look what you did,” and make a big deal about it, because it was funny, but we’d be OK with it.

Clayton:  I guess there was something different about that. Because I think we internalized that. We acknowledged the failure maybe, and so we thought it was OK, and it was kind of a learning experience.

Roy:  Yeah, we still do that.

Clayton:  That’s true, yeah. What’s different about our team than an average agile team?

Roy:  Maybe it’s because we feel like we are on equal footing, and we’re doing it in a sense of camaraderie and to communicate.

Clayton:  I don’t think we have that fear of failing. We aren’t afraid of it.

Roy:  Also, what I see on some of the teams, or teams before is that it is a way of putting somebody in their place, and maintaining the status quo of ranks. If I’m the senior developer, I’ve got to make fun of the junior developer when they screw up, or else they’re going to be senior developer. If we’re all senior developers how can I be better than everybody else?

Clayton:  I think that makes sense. I wonder how pervasive that is. I’m sure there’s a lot of people that self identify with the senior developers, and they would want to hold on to that as much as possible. I could see that.

A lot of the reasons I think I’ve seen that senior people will either take control and drive all the time and they leave the junior people behind is that they want to get stuff done. I know that your team has been experimenting a lot with pushing the boundaries between having fun and getting things done. Is that a hard line to walk or…?

Roy:  It’s really difficult, especially when it seems like when we are having the most fun, and feel like the least productive it often times turns out we were pretty productive. Other times we are not productive at all. A good example is that we had a planning ceremony about a week ago, where normally it takes us about an hour and a half to task out a sprint. In this case we were laughing the entire time, and we were throwing index cards around. I got a picture I think I showed it to you.

The entire place was trashed. There were index cards everywhere. Which we all picked up, don’t worry, right before the end. We felt like it was the least productive thing ever, and an hour later we are done with our sprint planning. We were like we can’t have more planning sessions like this, because it is just chaos and un‑maintainable. But then we thought when we stepped back to look at it, but wait we just planned out a sprint’s worth of work in one hour when it normally takes us an hour AND a half, and it was a blast.

Clayton:  I think sometimes when you are having fun, time flies. You don’t really notice. It doesn’t really drag. Was anyone on the team kind of frustrated with that, maybe were some people not having fun so they thought it was unproductive?

Roy:  I don’t know, I know personally in the back of my mind I was like, “Man, this is fun, but God I’m going to get in trouble later when it turns out we don’t have anything done. We don’t have any sprint work. We are going to get reamed.”

Clayton:  Is that your conscious telling you, “Maybe I’m having too much fun?” Or, ” [inaudible 10:16] got to reel it in a bit?”

Roy:  Yeah.

Clayton:  I think that’s a good point you made about stepping back and reflecting on it. I’m sure in every team there’s varying levels of how much fun they want to have.

Roy:  That’s true.

Clayton:  Most agile teams, to some degree, value fun, but I think a lot of them don’t value it enough.

Roy:  A lot of people are scared of them.

Clayton:  Scared to have fun, you mean?

Roy:  Scared to have fun or scared to be seen having fun, because then their managers think they’re not doing work.

Clayton:  I guess the traditional thing is if you’re having fun at work, then you’re not working.

Roy:  Right, exactly.

Clayton:  Which is pretty sad?

Roy:  I’ve worked with people where we try to have fun. They said, “Hey, we came here to work. We’re here to work. I come here, show up, and do my work and go home. I can have fun at home, but this is not the time and place for it.” How miserable is that? You spend a third of your life here, and you’re not allowed to have fun?

Clayton:  I think a lot of agile teams embrace the idea of having fun. But maybe they don’t spend enough time reflecting on how much fun their having, or maybe where that boundary is? The boundary between having fun and being productive is kind of a moving target.

I think if you have a lot of fun and getting a lot of stuff done, then, usually, people don’t seem to notice, right?

Roy:  Right. Definitely, there have been times when we have a lot of fun and nothing gets done.

Clayton:  That’s true. How does your team compromise? How do they mitigate that?

Roy:  On a side note real quick. It’s funny how that perception happens, because you remember today, you walked over to our team. Because you all of a sudden heard us be silent, and said, “Hey, it sounds like you guys are finally starting to get some work done,” because we’ve been screwing around.

The irony part was, the reason we were all silent was because we all turned back to look at our email and stopped working, for that little bit. Exactly when we were not working, was when you thought we were working the hardest.

Clayton:  That is interesting. I guess the perception from the outside could be pretty misleading if you don’t know how the team is operating. When you guys are having fun, how much does that play into creating that kind of learning culture? Do you guys try to have fun as a means of learning?

Roy:  I don’t know if it’s a means of learning. Learning should definitely be fun. If you make work fun, then you make people passionate outside of work. If your work is dreary, then why would you spend your free time getting better at it?

It’s like, “I hate programming. The last thing I’m going to do at night when I’m sitting at home is program. I’m going to watch TV or read a book,” or whatever it is you do. If your work is fun, then all of a sudden you’re like, “Man, this is great!” Programming is awesome if you have fun at it, and work with good people. It can be a really fun experience.

With Start‑Up Weekend we got together the group just for fun. We programmed for fun. Nobody paid us. We made a product we knew we were going to throw away at the end.

Clayton:  That’s true.

Roy:  It’s a blast to work that way. If that type of thing is true, and you enjoy what you do, then all of a sudden it’s going to become worth it to you to spend your free time learning it, too. Like, “This was fun at work. I’m going to do this as a hobby. I’m going to get better at it,” which in turn makes your work more fun. It all of a sudden starts feeding back on itself.

Clayton:  Fun is definitely underestimated. I think it’s talked a lot about in the agile community, and it’s really gamification and all that kind of stuff. I think as a team value it probably goes under represented. Although I feel like at a human level, everybody wants to have fun. Even the people that say they don’t want to have fun at work, they want to have fun.

Roy:  I think most of the time when fun is brought up during a retrospective or something of that nature, it is almost always in my experience, in the context of we are having too much of it, and we need to cut back.

Clayton:  That’s true.

Roy:  What’s interesting is that the talk isn’t we aren’t productive enough and we need to be more productive or we need to hit our sprint. It’s we are having too much fun. That’s our biggest bottleneck. Clearly, if fun was less, the work would be more.

Clayton:  Maybe that’s a knee jerk reaction to some kind of old way of thinking about things? That everyone’s baked in their mind set about how works supposed to be? That’s why they want to dial back the fun?

Roy:  Yeah, that makes sense.

Clayton:  Interesting. I think we are about out of time.

[music]

Clayton:  Is there something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest.

Looking for an easy way to stay up date with the latest news, techniques and events in the agile community? Sign up today at agileweekly.com. It’s the best agile content delivered weekly, for free.

The Agile Weekly podcast is brought to you by Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes.

Roy:  Need help with your agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free! Call 866‑244‑8656.