Agile Weekly Podcast

Jade Meskill:  Hello. Welcome to another episode of the Agile weekly podcast. I’m Jade Meskill.

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

Derek Neighbors:  And I’m Derek Neighbors.

Jade:  I thought today, we’d talk about something, maybe a little controversial. Do we need frameworks?

Roy:  Like Rails?

Jade:  Maybe like Scrum. What do you guys think?

Derek:  No. Yes. No.

Jade:  OK.

Roy:  It’s one of those things where they’re helpful to get started by get in your way after a while, but you think they get in your way a lot sooner than they actually do.

Derek:  I like to say, if its individuals and their actions over process and tools. Why is it the first thing that we default to add to lists are hey, you need to learn a bunch of process? I think, no, they are not necessary.

However, it’s very hard to do things well if you don’t have any discipline. What process does is it allows you to learn how, as a team, to be disciplined about the work that you do. It helps highlight issues that you have that can help you improve. Basically it builds off of work that people have done before.

We know that all these things tend to really keep teams from performing well. If you’re not cross‑ctional, if you don’t have a concept of time boxing, if you don’t have a number of these things, you tend to struggle.

We’re going to go ahead and put those things before you. Learn how to use them, and as you learn how to use them, you can shed them away and probably still get really good results.

I’d say, yes and no, I don’t think you need process. Do I think that it’s hard to be good without having some guide rails to explore how you work? Yes.

Roy:  I think some of it comes down to pragmatic thinking and learning talks a lot about the Dreyfus model and how early on you need rules because you don’t have enough knowledge to make your own decisions. But that rules ruin experts, and all these people that have lots of experience are now hindered by having to follow these rules when they should be trusting their intuition.

Derek:  People tend to find themselves being experts far before they’re really experts. That’s another problem there is. I call it the so fucking agile. We’re so fucking agile that we don’t need to do XYZ. I can turn on the dime. I can respond to anything. I was just like, Yeah, so you’re in chaos. That’s really great.

I don’t consider that agile. Never getting anything done because all you do is respond to every stimulus that comes your way does not make you good. It makes you undisciplined. I think that that’s difficult thing.

Roy:  I think that’s the careful distinction between thinking that you’ve arrived, that you’re there and that you’ve finished adapting Agile or whatever or finished improving and the idea of, I think I’ve grown these rules but I still need to improve and try new things all of the time because I’m not even close to where I want to be yet.

Derek:  Yeah, so the litmus test I use is if somebody believes that the rules don’t belong to them and they don’t want them. They’ll throw a fit if they have to follow rules, they’re probably not really a master. If somebody says, I think that these rules could be bent but I don’t really have a problem with the rules and if it’s going to cause you all sorts of grief to not adhere to these rules, then fine, I’ll adhere to them.

I generally find that’s the person that’s probably OK without actually having rules because what they’re saying is, I don’t think the rules hinder me so much that I can’t be effective, but I do think I know the rules well enough that when they need to be bent in certain ways, I could get more performance out of them.

Where the amateur tends to say, I just don’t want the rules at all. Any rules at all are going to hurt me.

Roy:  I agree with that.

Jade:  Part of my reason for asking this question is thinking about introducing new teams, new people and dumping this giant framework on their heads, let’s say Scrum. If I’m going from nothing to Scrum, that’s a lot of stuff to learn and take in. Does that hinder or help their ability to become more agile?

Derek:  I don’t know. So you do count them on if you don’t want to do that. I think that to me like what I’ve been…

[crosstalk]

Jade:  That’s even a lot to take on.

Derek:  Not really.

Jade:  To do right.

Derek:  The way that I look at it is, what do you want? If you want some immediate results, a framework like Scrums says, We’re going to be opinionated about a whole bunch of stuff because we know it works for most situations so just believe us and do it.

The benefit to that is you can actually get real benefit immediately by making those changes. The downside is, you have to make fundamental changes on how you work. For a lot of people that pisses them off and makes them turned off to the process so then, they want nothing to do with it. It doesn’t stick long term the minute that somebody says, OK, you don’t have to do, even if we’re getting great results from it, ultimately, we didn’t decide to do all those things.

The framework tools we had to do them so I’m going to throw them away the first chance somebody will let me where I tend to say that people that have a little bit more time, can explore. You do something more like Kanban. Just do what you’ve always been doing, visualize it and start to ask yourself how we can improve, improve over time.

That’s a lot less hostile. People will tend to get to the same place that they get to in scrum a lot of times, but they get there over the course of months or years. They totally own it, because they’re the ones that made all those decisions.

I had a team the other day. One of them was doing the work of what I would call the scrum master. The other person said, We created our own rule for a Kanban, it’s called the … [inaudible 06:06] Nanny.’

It was the person that was helping organize the work with outside parties and working with the product owner and managing a lot of the stuff that developers didn’t want to really be doing, but needed it to happen.

I thought it was kind of ny that after a couple of months of Kanban, they had really implemented the equivalent of a scrum master.

Not because they wanted to emulate the scrum master. It was just that somebody stepped into the role of doing that and people could tell there was a different role than the developer.

I don’t think it’s necessary. I think it can hurt or help.

If you want some immediate gains, if you believe in cross‑functionality and you believe in time‑box and being able to estimate or have some predictable delivery or really important and you want to get that right away. I think scrum can give you those things right away. It might piss people of in the process and turn them off to Agile in general. That’s a possibility.

Jade:  When have you seen the best results?

Derek:  I see the best results when it’s a hybrid.

You don’t necessarily force. You have to do all these things, but you do some kind of principle‑based stuff. I almost think of it like scrum is the best idea of how I would deal with this, but if you have a different way to deal with this, fine let’s deal with this in a different way.

I think that time‑boxing of iterations is a really good way to force feedback in some regular thing. If you’ve got a better way than that form of time‑boxing to do something, cool. Let’s look at it.

More often than not people, given them the choices, just give a better way to do it. Let’s hear it. Very mature, so they don’t know. They’re like, OK, let’s do that, because I don’t have a better way.

Sometimes they come up with a better way like, I think we can do this instead.

Jade:  You’re showing them the facts, but then saying, It’s your choice. If you’ve got a better idea, we’ll support the best idea.

Derek:  Right.

Roy:  That sounds reasonable. It goes really hard to argue with too.

Derek:  It’s about not being dogmatic. At the end of the day, we just want results. As long as we’re all OK with the results.

Roy:  If you can manage to get awesome results with Waterfall, then by all means.

Derek:  To me, with cross‑functionality, people get really hung‑up on it. I like to switch it more toward shared commitment. As long as we’re all shared in the commitment and that any of us are willing to do the work and all of us are part of that, I’m OK with not necessarily calling it cross‑functionality.

It’s impossible to get that result and to have shared commitment without having some level of cross‑functionality, but if somebody’s going to get totally hung up on like, I’m a DBA. There’s no way I could do XYZ.

Great. Let’s not talk about it in those terms. Let’s just talk about it that we’re bringing in two stories. The three of us are all going to commit in doing those stories. Let’s not predetermine who’s doing the work and we’ll go from there.

Roy: It reminds me of something Jim brought up in one of our earlier podcast when he joined us.

The idea, “We just care what is effective. The fact that it happens to be what makes people happiest is just a really nice coincidence and side‑effect but really it’s all about getting results.”

Jade: Maybe that’s where some adoptions go wrong, the desire to state is to be doing scrum, not to be getting results.

Roy: Especially when you start measuring how far along your scrum adoption has gone.

Jade: I’ve seen a lot of corporate roll‑outs in large companies. Really, the goal is to have scrum. It really is not about delivering results.

Roy: We are more agile than you.

Derek: No, I think it’s more, better, faster. What we really care about…

[crosstalk]

Roy: No, but they’re not even tracking more, better, faster. They’re tracking the ability to adhere to the scrum frame.

Derek: No. In most of them it’s, is your velocity increasing over time. If you’re velocity is not increasing over time, we’re going to get mad at you.

One of the ways that we track like are you getting better is ‑‑ are you having stand‑ups? Are you doing retrospectives? Are you doing a planning meeting? What’s your velocity?

Jade: Measuring the rules of scrum.

Derek: It’s measuring the ceremonies and the rules of scrum, not the results of the scrum team. That is one of the things that actually kills scrum.

It shouldn’t be about any of those things meaning if you can’t get better by like…We’ve been trying to say while I’m on my current engagement is you will do Scrum or Kanban for two to three cycles or two to three sprints, whatever you want to call it, in roughly 30 days, give or take, in a fairly pure form to whatever the methodology or the thing is. From then, go ahead and make whatever changes you want.

One of the major means for change for me is, have you started to change it. Because if you haven’t, I don’t think you’re really agile because agility starts to say like, “OK, we’ve done this and we now know what we could do better that works for our DNA or organization or team.”

The second part is measuring are you getting real results, not is you’re velocity better, not are your sprints cycles order, not with a bit like are you getting whatever results the business wants from you. If you’re doing those two things, you’re good to go.

Jade: So, it really comes down to results?

Derek: I think so.

Jade: Great. What advice would you give to people who are out there who are maybe in the midst of this transformation or adopting Scrum or thinking about adopting Scrum? What would you tell them that would help them become more successful?

Derek: For me it’s a journey not about destination. I mean, too many groups, teams, organizations I look at and say, “Hey, we were going to do an agile adoption or an agile transformation and we want to be done in two quarters or we want to done in a year and a half.” So, they put all these effort and like to we’re adopting something whether be Kanban or whether be Scrum.

The end is when everybody in the organization is doing that process. For me, if you want to be successful, don’t think of it as a destination of we’re successful ones everybody is doing for some process, think of it as this is a life long journey for your company.

You have to constantly be adapting to the world around you. Part of it is you should be asking yourself if you’re still doing to same Scrum thing that you were doing or the same Kanban thing that you were doing a year ago, you’re not adapting because I guarantee your world is changed in a year, year‑and‑a‑half time‑frame.

I think part of that too is if you’re not seeing your team change and you’re not seeing your result improve, there’s something wrong with what you’re calling agile.

Jade: And results, not velocity, not your scrumness ‑‑ your actual results.

Roy: The thing I would look at the two is to think about why you’re being asked to change. Because with some of the teams, I think that they are…because they happen to be the best team in the company and for some reason think they are the best team within their immediate surroundings. They think that they don’t need to improve at all. So, that would be my biggest advice as I just assume you suck and get as good as you can.

Derek: If you don’t think you suck, you’re probably already dead. What I mean by that, that analogy I give all the time, is if you look in a gold medalist in almost any sport when they’re standing on the gold medal platform or getting their gold medal, they are more likely not thinking what an awesome performance I had.

They are thinking about every single mistake they made that they could have done better even though they’re already getting the gold medal.

They’re saying, “Man, if I would have stuck that, I could have got a perfect 10 or I could have shaved an extra five seconds if I would have picked up my foot up or man, I had a bad start out of the gate and if I would have fixed that, I could have beat the world record.” No matter what their performance is they’re sitting there going I could have done something different to go better.

That is where exceptional teams, exceptional individuals come from as when they look at even their best performance and say, “Man, I can do even better. I can find another way to make this better.”

The people that tend to be mediocre, the people that are like, “I’m great, I did the best I could there. I could not be possibly get any better.” Because the minute you said that even if you are the best, somebody else will come behind you that wants it more that what you want right now and take it over from you…

Roy: Then they’ll make it look easier for you.

Derek: There was a time when there wasn’t such thing as the four‑minute‑mile, right?

Jade: Yes.

Derek: I mean that seemed impossible but once it was four‑minute‑mile, it just keeps going like there’s always somebody who will find a way to outperform whatever you think the best performance is especially in technology because we’re not limited by physical means.

Somebody will invent a better mouse trap that will surpass whatever you think is the pinnacle. If I were to say we’re going to travel beyond the moon and land and to do something that might seem impossible today but once that happens and it goes the next level and the next level and the next level, somebody will always one‑up that.

That is a huge factor. If you’re not looking to improve like why are you doing agile, like if you think you’re great? I also think there’s a big translation problem between executives and middle management. Executives what I hear most executives say is “I am sick of not being the best in market, I’m sick of not making our customers happy, I’m sick of not being like number one.”

What management tends to hear on the technical level is they want us to be faster with better quality. When middle management tries to adopt agile, it’s really all about how do we get agile? Do we have better velocity, less defects?

The reality is if they produce the same shit with more quickly with the same amount of defects, their manager…their executives would still be asking for something different because what they’re really asking for is how do we outsmart the other guys that are on the platform with us.

Roy: Right. They don’t want a faster horse. They want a car.

Derek: Right. Exactly.

Roy: They want something that may change it.

Derek: Exactly. That’s exactly it. That’s one of the things that’s very difficult for teams to realize too because they’re just like, “OK, we just need to go faster, we need to work harder.”

So, a lot of the agile initiatives are seeing this kind of like, “All right, great. Somebody got a whip out” and they’re just beating us hard with this process. Instead of saying maybe this is a process that actually frees us up to be co‑creators of something great instead of just going faster at the crap that we’ve always done.

Jade: That’s all the time we have here today. Thanks for listening. Catch you next time on Agile weekly podcast.

Jade Meskill:  Hello. Welcome to another episode of the Agile Weekly podcast. I’m Jade Meskill.

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

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

Jade:  Clayton, you’re trying a new approach to coaching a team you are working with. We wanted to talk about that a little bit. Tell us a little bit about what you’re doing.

Clayton:  A little bit of background. The team is this collection, I wouldn’t say misfits, if you’ve seen the movie “Bad News Bears” it’s kind of like that.

Jade:  [laughs]

Roy:  Wow. I have not.

Jade:  [laughs] Imagine that you have.

Roy:  Is it like “Breakfast Club”?

[laughter]

Clayton:  In that there are people in the movie, yes. It’s the same thing.

Jade:  [laughs]

Roy:  Is it like any of the three “Star Wars” movies?

Jade:  [laughs]

Clayton:  OK. There’s this collection of misfits and the approach I have been taking was I wanted to be prescriptive about some things. I go back and forth between organic learning or being really prescriptive. I thought I want to be kind of prescriptive because I want to accelerate things, but I don’t want to be prescriptive about stuff like process. I don’t want to say like, “We have to do stand-ups” or “We have to do Scrum” or “We have to have a product owner.”

But I thought, “What if I’m prescriptive about the principles and the values?” As far as being prescriptive goes, that has actually gone pretty well. Things like being open about what we’re working on, visualizing the work, collaboration, and all those kind of things. Then the other approach I’ve been taking that’s actually probably had the most benefit there’s two things.

One is I’m pretending like they’re already an awesome team. When topics come up, rather than saying like, “I’ll ask a question about something like, “How would a team handle this?” Rather than saying like, “A high‑performing team would do X, Y, Z,” I’d say, “Oh, I think maybe if you guys did this, that would work.” They look around. The next part that comes in is “You can do anything you want.”

I always laugh when Jade does the, “You can do anything you want, but there are consequences.” I’ve been trying to get them to believe in this kind of fantasy land where they live in this reality where they’re already awesome, and they can do anything they want. Some of the things that I’ve done on accident that have helped a lot, we set up pairing stations. One of the things that I was being prescriptive about was collaboration.

Rather than trying to work on a bunch of these different projects all at once with a bunch of different people siloing, I said, “Hey, let’s set up a pairing station.” I actually did that for them and made it really easy to use them. It worked out in my favor that no one’s machine was set up to work on any of the projects, and the only machine that was was the pairing station. I just grab [indecipherable 2:27]

Jade:  This was a team that hadn’t paired before? They were not

Clayton:  Yeah, they’d had a little bit of exposure but not really.

Part of the pairing station problem that we had was the monitors were really bad. I went out one day, and I just bought new monitors. I came back and they were all like, “Wow. How did you get new monitors? You didn’t go through IT.” I’m like, “Yeah, I just went and bought them”. They are like “you can do that”? I wasn’t trying to make a case on this but I was like “Yes, I can, I’m an adult. I went to the store and I purchased them and there was this transaction and now we have new monitors”.

It was totally an accident but that was I think the first time they saw “Oh, wow, you really can do anything, there was this thing that I thought was impossible but then you did it”. All the conversations we have been having around actual code things or technical practices or what ever, I think the barrier of that’s impossible, I have never seen that before is widdled away at this point.

They are willing to pretend now, that they can do any of these things. Anything is possible.

Jade:  What are the results that you have seen so far from this experiment?

Clayton:  They are making good choices. One of the things that I have been trying to emphasize is that concept of if you see a problem it’s your problem now. If you tolerate it, you insist on it. If you see something that you think there is a better way of doing something, then go ahead and do it. Take ownership of it.

It started out where the board was disorganized and people were saying, “I don’t understand what the board means”. “OK, then make it better”. “Oh we can do that”? So they went and made it better.

The next day “I don’t understand how the board flows, I don’t understand what projects they are”. Then someone said “I think we should color code them”. Great, go color code them.

It seems like they are doing what ever they want, but they are really doing the things that are helping them being effective. I have seen a lot of collaboration. They actually are pairing on everything. It’s kind of by necessity.

There is not one person who knows everything, so they’ve gotten so much benefit out of collaborating on the work, I think they are falling in to that as just a habit. I don’t they trying to find a way out of it. They are not just doing that because they need to. I think they are enjoying it and having a lot of fun.

The other thing I have seen is at the end of the day, they look like they are mentally exhausted from pairing all day and they look like they are ready to go home. Where before there was a lot of idle time and board thumb twiddling. That is a status quote for that organization. These guys seem like they are really engaged the entire time.

Roy:  It’s interesting because you brought up the fact that, from your coaching experience it sounds like this is one teams you have been the most prescriptive with, yet they seem to have the impression that they can do what ever they want.

Clayton:  I heard a conversation that they were having with someone on their team where they said “It’s really awesome, we just get to do what ever we want”, which is really not the case. If they got to do what ever they wanted they would probably be doing something different, but because I am able to guide them along with their principals, if there is an idea and we’re using a decider, so everyone is trying to support the best idea.

So when something comes up they are in the habit of saying “OK, I have this idea.” Make a decider or proposal and it passes. If something maybe needs to get tweaked a little bit, we can just make a new decider, and alter it a little bit. Or we can investigate what that behavior is, and get their intention. One example that came up the other day was, they didn’t want to have a rule about [indecipherable 5:48] overproduction code.

I think maybe normal coaching stuff would be like, “This person wants to go off and do their own thing, because they [indecipherable 5:55] “ In reality it was, “I want to have more time to learn by myself. The best way to learn is to actually do the work.” “OK. That makes sense.”

They wanted to go home, and to do the work on their own to learn. Many other people in the team thought, “Hey, that takes away an opportunity for me to learn.” We were able to negotiate some way, to talk about how we can satisfy all those needs on the team.

It’s like the team is doing what they want, but they are still sticking to the principle of overproduction code is paired collaborative code.

Jade:  What do think has been one of the most powerful ideas that you’ve tried out? You talked about pretending. What’s one of the other things that you’ve done, that you think has allowed this team to be able to enter into this new reality, and just accept it?

Clayton:  A couple other things that have been really powerful, we snapped them out of the current environment I guess. The very first day that we were a team, there was a lot of [indecipherable 6:55] about, “Why we had formed this as a new team?”

“What were doing here,” and “Why did I get picked to be on this team, and not these other people?” I said, “I’m going to go on an adventure, and go to Michael’s and buy some supplies to make a physical board. Who wants to come with me?” This was 9:30 or something.

There were two people that looked at me strangely like, “You are going to go where? But it’s work time?” We went, and it’s stuff like that. Like those little moments, where I’m just modeling that behavior of reinforcing that, “You can do whatever you want. You can make the workspace better or the work better, or how you are doing the work, better.”

Those are the kind of things that have the biggest wins.

Jade:  You took on the authority of, “We can just do this. We can go wherever we want. We can do whatever we want, right out of the gate?”

Clayton: Yeah. Because from my perspective, obviously my boundaries as a consultant are much wider than theirs are, at least their perceived boundaries. I tried to maximize that and be super vocal about it.

Normally, I probably would have done the Michael’s anyway. I wouldn’t have said, “I’m going on an adventure. Who wants to come with me?” Just that kind of thing…

[background noise]

[laughter]

Jade: That was the Jenga board that just…

Clayton: Oh, probably. [laughs]

Jade: The life size Jenga that just crushed.

Roy: That was my fault. I may have built the Jenga tower up to the ceiling.

[laughter]

Clayton: Anyway, being just the person who is really being this outlandish “I do whatever I want” type of person, but very, “I’m not doing anything that’s totally crazy.” It’s stuff to them seems crazy. As far as I’m concerned, it’s pretty vanilla stuff.

Jade: The idea that they believe they can do whatever they want, is very interesting. In that, you’ve put them in this sandbox, where there are boundaries, and there are constraints to what they are doing. That are totally outside what their normal behavior is.

You’ve set some very strange expectations on them. They don’t seem to feel like those are even there. It’s completely invisible to them, that those things are even happening.

Clayton: We had one word they were stressing about going to a meeting. They thought that all five people had to go to this meeting. I said, “OK. I don’t want to go to that meeting.”

They looked at me like, “You have to go. You are on the team.” I said, “I don’t want to go to this meeting. I don’t care about it. I think anyone should be free to go, or not go. Whatever decisions get made, you have to go along with those. If you guys go to this meeting, and make some choice, I’m fine with that.”

I think that kind of stuff is like, “Whoa! That’s crazy. You would not go to a meeting, and then be OK with what other people said. You don’t want to have your hand in the cookie jar and micromanage me?” That was a crazy experience.

Roy: One of the freeing things about that, it sounds like it removes all excuses. I’ve dealt with quite a few teams, and we are like, “We are in a meeting the whole day, we can’t leave. They are wasting my time, and I know that I’m not even necessary, but I can’t talk to my manager about it.”

All those excuses are gone. It’s just like you don’t go. I’ve talked to a lot of people about that. They are like, “Whoa! Maybe in your fantasy world, you can just get up and leave from a meeting.” I tell them, “No. Just get up and leave.”

Roy: They don’t believe it, I wonder why not. Why do your people believe that [indecipherable 10:02] ? Is it because you are modeling the behavior?

Clayton: I think the two things that I’m using for that type of thing is, I’m saying that all I care about are results. I don’t care at all about effort. If you put a bunch of infrared in…

Jade: You are done.

Clayton: …you are done.

[laughter]

Clayton: I’m saying all I care about is results, but I’m also saying that I demand excellence, and that we should be continuously improving. Maybe you were getting results last iteration, but now let’s get more results, or better results. Let’s do more.

Those two things are the two edges of the sword. I’m not worried about them becoming lazy and saying, “We’re getting results. We only have to work four hours a day and we just kick back.”

We value excellence. We value continuous improvement. There’s always something you can do better.

Jade: How would you have somebody else who would like to try this approach, what are some of the tools in the toolbox that you think they need to pull this off?

Clayton: The core protocols have been very helpful. I’ve been really trying to get them to use Ask For Help. I have been trying to stress to them that they can do anything if they just ask for help. Ask for enough help and you can do anything you want.

Decider has helped a lot. I’ve personally been using Investigate and Attention Check to try and uncover some of the second or third level reasons why they think they can’t do something or why they have some problem with this.

That’s helped me to uncover some things and then make proposals to solve those problems. The core protocols have been very helpful. The biggest thing for me is modeling that behavior, not only just telling them.

If I were to tell them, “You can do whatever you want, it’s up to you. You’re all powerful” and then I left, that’s what they’re used to. That’s the manager coming in and saying, “You’re self organizing!” and then I leave and I don’t reinforce that.

Telling them that stuff and then being in the physical space with them, and helping them when they asked for help, and then showing them, like with the monitor thing. Even though that was unintentional that worked out totally awesome.

Jade: It’s because you were living out the thing you believe, right?

Clayton: Exactly. I don’t want to wait. It’s frustrating. From my perspective, I went slow on that. I stalled when I probably shouldn’t have. I should have done something else. I waited a little too long.

From my perspective, that was probably bad behavior in terms of slowing things down just to be comfortable.

Roy: But from their perspective it was so fast.

Clayton: “This rebel without a cause, he went and bought monitors!”

[laughter]

Roy: He popped his collar.

Clayton: I was like James Dean there.

Roy: Go into Michael’s to buy crafts, supplies, and monitors.

Jade: Pretty rebellious.

[laughter]

Jade: What’s next for your experiment that you’re trying here?

Clayton: The next thing that I’m going to try is, I’m going to really try to get them to use Ask For Help as a default. They just participated in a Hackathon. I told them I would help them with whatever they wanted, but they had to ask for help.

That was the only way they could interact with me. That was frustrating for a little bit.

Roy: For you?

Clayton: No, not for me, they were mad about that. I had to keep saying, “Are you asking for my help? Did you use the protocol?” They got better and better and better. I really would like to reinforce that enough so that when they get stuck with something, they have no problem asking for help from anybody.

Right now there is something that is in their work queue where they need to go talk to somebody to get access to a repository of files, and they’re stuck. I want the light bulb to off to be able to say, “We should go ask that guy for help.”

“Hey so and so, I’m going to walk over to your cubicle and say hey, will you help me get access to this?” I bet you that would work. That’s not what they’re used to. That’s not the way of doing things.

They’re used to sending an email and wait, and go through all the polite channels. My next experiment is to see if we can use Ask For Help for almost everything.

Jade: One last thing. How have you dealt with the urge to rescue them when you see them doing dumb things?

Clayton: That’s been really hard, especially during the Hackathon. That was really difficult. The one thing that I found was really helpful is I would just try to ask questions about stuff.

One of the questions I asked for the Hackathon was, “That looks really cool, where can I go see it?” or, “Can I send that link to somebody?” Then it was, “No, you can’t. It’s not on the Internet.” That’s too bad.

[laughter]

Jade: That’s rough for a web app.

[laughter]

Clayton: That triggered, “Will you help us set it up?” Sure, I’ll do that. I think that’s back handed rescuing, so I probably need to stop doing that too. Fighting the urge to rescue, I don’t think I’ve figured that out yet.

Jade: What do you think would have happened if you were rescuing them all the time?

Clayton: I would have been this linchpin where they wouldn’t have been able to do anything without me. I certainly don’t want to be in that position. I don’t want the team to be non functioning after I leave.

I think if I were to rescue them the whole time they wouldn’t have learned a whole lot. There’s a whole bunch that they learned. I think they really have grown as a team by being frustrated.

I’ve seen people sitting there by pairing. Someone says, “I really am frustrated. I don’t understand what’s going on.” The other person says, “Let me finish.” Those are the kind of things that if I were jumping in and saying, “Let me explain it to you” they wouldn’t have that shared experience as a team.

Being frustrated and getting mad at somebody that you’re pairing with, those are such big building blocks.

Jade: Having that good conflict?

Clayton: Exactly. One person has to slow down for the other person, and having the discussion of how did we get here, and all that stuff.

Jade: Awesome. Hopefully we’ll hear more about how this progresses with your team. If you guys have any different or exciting ways that you’ve interacted with the team and helped to get them to high performance, we’d love to talk to you about it.

Look for us on Facebook, and we’ll catch you next week.

[music]

Jade: If there is something you would 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 to 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!

[music]

Sharon: I’m Sharon.

Diana: I’m Diana.

Sharon: Leadership is not easy, is it? The dilemmas of leadership.

Diana: The challenges.

Sharon: They’re not alone in their struggle.

Diana: They want to be a better leader.

Sharon: Listen, it’s good.

Diana: Nothing but the truth.

Announcer: Partnerships and Possibilities, podcast on leadership. Find us on iTunes.

Jade: The Agile weekly podcast is brought to you by Integrum Technologies and recorded in 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.

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

Jade Meskill: I’m Jade Meskill.

Derek Neighbors: I’m Derek Neighbors.

Roy VandeWater: I’m Roy van de Water.

Clayton: Today we are talking about my favorite thing, being lazy.

Jade: Oh my gosh, that’s my favorite thing too.

Clayton: Really?

Jade: Yeah.

Roy: Do we really have to talk about it?

Jade: I don’t know.

Clayton: [laughs] I don’t want to think about it. That’s too much.

Jade: [laughs] Good thing we can talk without thinking.

[laughter]

Clayton: So many more jokes to be made.

This topic, Jade and I talked about this at lunch. It sounds like, Jade and Roy, you’ve been talking about this a lot. The concept stems from a lot of the clients that we’re working with.

We see these teams where they do a whole bunch of work, work, work, work, work, work, and they get praised for all their effort. At the end of the sprint they didn’t really deliver anything of any value, they didn’t really ship anything, the customer’s not delighted. But boy oh boy, they worked hard, and everyone in the room is clapping for them.

That feels really disingenuous. I think I heard someone the other day talk about how they stayed up till 5:30 AM tweaking these servers. I thought to myself, “Man, if I had to do that, I would be very upset. I would probably find some way to automate it.”

Roy: I’d shoot myself in the face.

Clayton: Yeah, that was my next way of saying that.

Jade: I remember living in that world, though. I was definitely part of the “Hero” culture. I could always be counted on to work the extra hours, or do whatever it took to get the job done. I’ve wizened up since then.

Clayton: I think it’s interesting because I think we have an “Automate everything” mentality, but there’s so much stuff now that…I used to do that, maybe be the hero, or you want to work the extra hours or whatever. It felt good to do that, like you were contributing a lot, but now it just feels dumb. I’d feel stupid if I do that.

Jade: I do too. Roy and I were talking about it the other day. I said, “If you find yourself working that hard to get something done, you’re probably working wrong.” It is so easy to get away with automating a lot of things, not having to do that much work. The problem is, there’s definitely a stigma against being perceived as not working hard.

Derek: I think my goal in life lately, maybe it’s why I’m a little more interested in robotics lately, is to replace myself with some form of automation. That is the pinnacle. I think what happens is, people do think that, “If I’m not doing something all the time, people are going to think I’m not valuable.”

I keep saying, what is it that makes us think this way? I can’t remember if it was Carlos Segura , or a designer of some kind. He’d said something very profound to me, at one point during a talk.

They basically said, “I make three million dollars for giving somebody a logo, and that logo only takes me about an hour or two worth of effort, to actually make the logo. My value is in knowing what to make for a logo, and that’s why I’m worth three million dollars.” The guy who makes the Nike Swoosh, we can all laugh at, “Man, that’s so simplistic!” Think of how valuable that is, or the Coca Cola logo, or whatever.

We focus on things that are very low value, and we think that we just have to put in a ton of effort to get any kind of result. I like to say that you have to put in a ton of effort to become an expert, and to become good, to know what the right logo is to do. But that’s not the same thing as, then every logo thereafter, you have to put in tons of effort to get there.

I think that’s the misnomer, is people just want to work hard, they don’t want to work at getting good. If you work at getting good, then you don’t have to work as hard anymore.

Clayton: Jade, you’d talked the other day about…Your definition of “Lazy,” I think, was about not wasting your time. It had something to do with wasting your time.

Jade: It’s that I have no tolerance for wasting my time.

Clayton: I think there’s a big difference. I’m not opposed to hard work by any means. I think hard work is a great thing, and maybe being deliberate with what you’re doing is very important, and busting your ass to get to do that stuff, but I don’t want to waste my time.

Jade: I don’t want to work hard at being stupid.

Roy: There’s still the “Human nature” component of not valuing it. Clayton and I were talking about his eye surgery, because he just got LASIK surgery. He spent a ton of money, and I think the operation, you said it took five minutes?

Clayton: Yeah, basically.

Roy: It was all automated, the doctor came in, pushed a button, and you’re done?

Clayton: Right.

Roy: I could totally see myself thinking, “I paid however much money for this? That’s crazy! I should have paid $5 because it took him 5 minutes!” It’s not like I’d rather have surgery for an hour.

Jade: You want the surgeon to work really hard on you, for a couple of hours?

Roy: Take a really long time, right.

[laughter]

Derek: I think it’s the value. If you’re spending $100 or $200 a year on contacts and you go out and you have this surgery, and it makes it so you don’t have to have contacts for 10 years or more, the value of that’s pretty high.

Jade: Maybe you just hate wearing them, it’s not even a cost thing.

Roy: But the weird thing is that I would actually feel less slighted if it took an hour, than if it took five minutes.

Clayton: I don’t know what it is about software teams that it’s so easy to fall in that trap of just praising effort. I think some of it has to do with, nobody in the whole food chain is very clear about outcomes. If the entire maybe organization or department doesn’t have some alignment about what it means to be successful, I think you just default to back‑patting.

Jade: It’s the thing that’s very easily visible. If I can look out in the parking lot and I see everybody’s cars here, and it’s 6:30, I know everybody’s working hard. Man, they must be a great team. [laughs]

Roy: But there’s a waste factor to it, too. I may have one guy who’s able to do in an hour what the other team takes 10 hours to do. He comes in and works for an hour and leaves. That gets me thinking, “What if I got him working all 10 hours? I’d have 10 times the capacity,” although maybe the magic to why he’s able to do 10 times what everybody else does is because he only works an hour. There’s a lot of that to it.

Derek: I think some of it, too, is it’s like preventative care in healthcare, or in medicine, or dentistry. I think a lot of times people don’t see the value in automation upfront, because there is performance degradation upfront that pays off in the long term.

If I go in and spend 10 minutes, I don’t know, once a quarter or twice a year getting my teeth cleaned, and I spend two minutes every night brushing my teeth, I can prevent really costly damage, and all sorts of repeated visits to the dentist down the road. But if it’s like, “Man, I just don’t have two minutes to brush my teeth every night to maintain that,” that’s ridiculous.

Jade: We have this happening at our client right now, where they have a build process that takes one to two weeks to run an automated test suite that they have. They have the capability to increase it by at least 100 times performance.

Roy: They know it’ll take less than a few weeks.

jade: Nobody will give them the time to invest to speed up their process that much. They think they can even take it to 1,000 or 10,000 times speed, but nobody will give them the time to invest. Now they just waste everybody’s time for weeks and weeks on end, because they refuse to invest that little bit.

Derek: I think that that’s a great point. I think that really solid engineers don’t ask because what they do is they say, “Look. We ship stuff late all the time. That’s standard for the industry, nobody’s going to beat us too hard.

“If we have to take in the shorts for a sprint or two or for a week, or a month, or whatever to get that 1,000, as long as we get that 1,000 times gain, people are going to be amazed with us 4 weeks from now. Fine, let them be pissed off for two weeks, while we fix this.”

I’m not advocating people go lie to their product owners or do hairy things, but I think there’s ways. If you truly believe in automation, you just bake it into what you’re doing. You don’t even say, “Oh, we need all this extra time to go do it,” you just bake it into part of the process.

Jade: What other ways do we try to maximize our laziness besides automation?

Derek: I think I put a lot of effort into being good about pattern matching, so I don’t spend a bunch of time rethinking about a problem to figure out a solution for it. I think I immediately try and just go to my library of patterns. “This looks like something I’ve already done, I’m just going to go to that right away.” I think I spend a lot of time doing that. I just focus in on, “What have I done before?” and, “How does this look like what I’ve done before?”

Roy: I’m pretty brutal about trying to remove anything that isn’t totally necessary. When I’m talking to a product owner, I’ll try to get everything out that I don’t need to be able to demo that feature. That usually means you can end up delivering most of what they want with 10 percent of the effort.

Jade: I’ve seen Roy put a lot of effort into beating down a product owner to get to the simplest solution.

Roy: It was interesting though, because I’ve gotten interesting reactions from product owners. When you do that it allows you to get way more done, because you’d spend 10 percent of the effort on 10 stories and…

Clayton: Do the right thing on…

[crosstalk]

Roy: A few times, and in one case, the product owner actually made it explicit that he felt that I was just trying to get out of doing work. Which I guess is true to some extent, but I wasn’t trying to get out of work to not do work.

Jade: Your intent was to deliver maximum value for minimum effort.

Derek: One area I see there being a lot of, I don’t want to say “Effort spent,” but some upfront effort spent, that gets long‑term gain for laziness, is space layout.

When I look at physical space layout, it’s one of the things I will fight really, really hard for teams to make the barrier to communication so low that everybody is within ear shot in the same room, so that I never have to IM somebody. I never have to get up and go to somebody’s cube.

The people that I work with the most are close to me, and are available right away. If I have to deal with somebody who’s digitally, I create pathways. Whether it be GroupMe, or Flowdock, or whatever, to basically maximize presence with them so that I don’t have to overcome some barrier. I don’t have to send an email and wait, and do all sorts of blocking techniques.

I think it’s interesting, because so many people just write that off like, “Why are you even finding facilities to just get all of us together? That’s just a waste of time.” I was like, “Not really, because every time we want to communicate, it’s going to save us, potentially, tens of minutes, hundreds of times a day.”

Roy: If I can turn my head and talk to you instead of get up, walk for 30 seconds, and talk to you, that’s huge.

Jade: The reality is you probably won’t even do it. If you have to spend even 30 seconds of effort to do it…

Roy: I’ll put it off.

Jade: You’re going to put it off until…

Roy: I’ll start trying to batch it, and then I eventually end up not doing it at all.

Derek: It falls in line with one of my other principles. I want to be the dumbest person in the room, or the dumbest person on a team, and if I am, I’m going to ask for help a lot. If there’s any barrier to me asking for help, it’s going to slow me down, so if I really want to be lazy, I want everybody near me and within earshot of me, or digitally near me, so that I can ask for help a lot, because I’m really lazy.

If Clayton solved the problem before, and he’s got a pattern the use, I don’t want to have to recreate it. I would rather ask Clayton and have him to say, “You’re such an idiot! Why don’t you just use this?” “That’s a fantastic idea. I would love to use that.”

Clayton: It’s interesting. These things we’re talking about are things I think get beat out of you in school.

Derek: I cheat a lot.

[laughter]

Clayton: On the way to work I was thinking, “Man, I was a really lazy kid, and I always got in trouble for being lazy. Did the universe just align me with this perfect career where I get rewarded for being lazy?”

Jade: [laughs]

Clayton: “Or am I doing something different?” I thought, “I used to get in trouble for being lazy,” and the same thing about asking for help. “You don’t do that in school, it’s not right to do that. You have to do your own work.”

Roy: If you ask one of your classmates for help, that’s called “Cheating.” You get sent to the principal’s office for that.

Clayton: Derek already knows how to do this, why would I bother figuring it out on my own? I can just ask him.

Roy: Derek already filled his worksheet out. Why don’t I just copy his?

[laughter]

Derek: Can I just copy your…

[crosstalk]

Clayton: No, I’m going to learn something when I do it, and then maybe I’ll have Derek pair with me. We can both pair on that [indecipherable 12:07] how to do it. Now I know how to do it, and I already solved my problem, I don’t have to do those things twice. That’s one thing I’ve seen a lot in a lot of these teams.

Especially from the flip side, all the people in the room I mentioned that were clapping. There’s something about getting to the end of this demo where the people have just shown you some work that they’ve done. They’ve spent their time doing something, and I think everybody in the room feels obligated to just clap.

“Well, I have to show some praise. I have to pat you on the head and say that you did a good job.” But I think if you were to go around the room and ask everybody, “Why are you clapping?” they wouldn’t know what to say.

Jade: “Because I have to,” it’s expected.

Roy: “Everybody else is clapping. If they see me not clapping, then…”

Clayton: It’s just what you do.

Derek: Can we have effort ceremonies, where we go out and do a demo, and…

[crosstalk]

Jade: That’s what it is!

Derek: No, but what we really do is we go dig a 10‑foot hole that’s 1 foot in diameter…

Jade: With a teaspoon.

Derek: …and we say, “My feature is so great we need to go outside and look at it. It’s so customer‑facing we have to go out into the public,” and everybody gets all excited. You come in and you say, ” Look at this hole!” and everybody’s like, “What the hell is that?” It’s like, “It’s my hole! Do you know, I spent all day digging this hole?” when they look at you and you’re like, “You are dumb,” “Well, it’s just as valuable as every other feature shown in the demo.”

Clayton: I think that’s one thing that really is interesting about this. I think the bounds of this problem…Basically, the amount of bullshit that people can ignore is this really narrow thing. If I were to say, “I did the same feature, but instead, what I did was I went over to this typewriter, and I typed the code out. Then I scanned it in an OCR, and then I saved the file. That took me three times as long. Isn’t that great?” Of course not, that’s so stupid.

There are some a little bit less than that, and I then get away with it, and I get praised for it.

Derek: It’s because the people praising generally don’t understand. They only are looking at the output, and the output looked like you had a lot of effort. They don’t know that all that effort was stupid effort, and there was this much, much simpler way to do it.

They think, “Wow, you did exactly what was necessary to get this done,” not, “You completely were moronic, and could have done this in a much more simple fashion.”

Jade: I’ve seen it doubly so, even when the output is poor. Because you put even more effort into it, it’s like, “Wow, this really looks terrible, but you worked so hard at getting this done.”

Roy: I was thinking the same thing. There’s so much with failure, like, “You didn’t succeed, but man, you tried really hard. As long as you tried really hard, that’s all that matters.” In school, that was the case. “As long as you showed your work, even if you got the wrong answer, we’ll still give you a 9 out of 10 points.”

Derek: Maybe we can call this the “Taxicab principle.” Taxicab drivers only get paid for the distance and the time you’re in the cab. If you jump into a new city, and you don’t know anything about it, and you don’t know any better, they’ll take you all around, so that they can have a much quicker fare. When, in reality, shouldn’t we pay them for, “If you could get me to the place quicker, I would actually pay you more money, instead of if you went the long way?”

Jade: I’ve done that.

Derek: I think product owners are like tourists. They have no idea how far or how long something is. If the cab driver drives through all this traffic, and they’re swearing the whole time about how horrible this this and how far it is, they’re so pleased as punch when they get there, they’re just like, “I’m going to give you an extra tip, because you really were a trooper and treated me well during this really long taxi ride.”

Jade: Roy and I decided that we’re going to start shaming people who try really hard, and work hard. We’re going to get a trophy that we hand out…

Roy: Right, a little Yoda.

Jade: [laughs] That says, “At least, you tried.” [laughs]

Clayton: OK. To wrap up, if I’m a product owner, the manager, or whatever, what can I do to stop praising effort?

Jade: Stop praising effort.

Roy: Stop praising effort.

Derek: Stop praising effort.

[laughter]

Clayton: OK, but how do I do that?

Roy: First off, stop clapping in the demo when everybody worked really hard to produce nothing.

Derek: I think a big part of it is, promote sustainable pace. Force everybody to go home at 5:00 PM. Don’t let people come in at six in the morning. Don’t let them work on the weekends.

Make them say, “You’ve got to have some time off,” and, if they don’t have those things, you should say, “Well, something is wrong with you. You are too serious.” When they’re like, “How else am I going to get all this stuff done?” it’s like, “You need to learn to work better.”

Clayton: Find a better way.

Roy: Find a better way.

Jade: I think, being proud of doing the simplest thing, of not working late, all those things are how you start to combat that attitude.

Clayton: All right, thanks.

Jade Meskill: Hello. Welcome to another episode of the Agile Weekly Podcast. I’m Jade Meskill.

Roy vandeWater: I’m Roy vandeWater.

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

Derek Neighbors: And I’m Derek Neighbors.

[laughter]

Jade: Very nice. Derek, you had something you wanted to talk about. What was it?

Derek: Yeah. I’ve been doing the work with a number of teams, and one thing that I’m starting to see emerge as a pattern is the team’s struggle to go fast. They struggle to work particularly within the Scrum framework a lot of times. Not only are they siloed where they got developers and QA that are separate, but where they don’t have a lot of automation. This could be automation around deployment.

This could be automation around testing, so maybe they don’t have an automated testing suite. Or if they’ve got some automated testing suite, there’s still some manual regression happening. Even if they have a fully automated testing suite, they’re not running it automatically.

They’re not having continuous integration, or it takes an enormous amount of long time to build. What I’m finding is it’s very, very hard for them to see what performance looks like, because they can’t get over the concept of their current reality. The current reality is, “Hey, it takes five days to run the test suite. There’s no way we can have a one‑week iteration. That’s just impossible. It takes us one week just to test, once the developer’s done with a feature.”

Have you guys seen instances, where maybe the current reality or the lack of automation makes it so teams just find…I had somebody specifically today, tell me, “That’s really nice that you stand up there and talk about a 10 minute build. Frankly, there’s no way you’ve ever done that before, because I’ve worked for five different companies, and none of them have ever been able to do that. I find what you’re saying impossible to believe.”

Jade: [inaudible 02:06] we have a 10 second build?

Roy: Yeah. I agree. I’ve struggled so hard to get a build to take 10 minutes. I don’t believe it’s possible.

Derek: In their current reality, I understand that. If you’re a manual regression tester, and you’ve got a fairly complicated suite, it’s taking two or three days to run a single test plan. I can understand how it feels impossible that you could, with any level of comfort, run a test suite under 10 minutes that made you feel like you weren’t shipping crap.

Roy: We’re working with the team right now, but we’re not working with working microphones.

[laughter]

Jade: That’s right. We are working with the team right now that a single test takes two weeks of constant computation, a single test.

Clayton: I’ve seen that in a lot of instances where, the technology gets in the way. If you’ve got a java applet that loads a Swf, how do you automate testing of that content? That seems like this impossible thing. I think a lot of people say, “It is what it is, throw my hands up in the air. What else are we going to do but, let those hourly regression people slave away at typing in commands and looking at the screen”?

Roy: Along the idea of trying to test a flash out, I think that’s one of the first mistakes that immediately causes your test suite to get larger, and take longer, regardless of whether it’s manual regression or automated testing. That’s when you write the test case last, after everything is done.

Jade: Yeah.

Derek: When you write the test case first, you end up using solutions that are easier to test. You don’t run into those things.

Clayton: That’s one of my favorite things about doing, not even just TDD, but just test first. Where you have to take into account what easy to test and what isn’t. I’m working with a team that has a fairly large fitness test suite. You can, totally, tell the way they went about using fitness to write this acceptance for higher‑level tests, because it was so difficult to test at the unit level, the only thing they could do was test the big black box of spaghetti code. They were all written after the fact.

They were trying to do more of a TDD approach or write unit test. It would’ve been so impossible to write any test whatsoever, if they were actually dedicated to that, they wouldn’t have had to solve that problem in the first place. The reason automation doesn’t get more not popular, it’s because a lot of times team get rewarded for effort. Jade and I were talking about this the other day. If you’re using a lot of effort that probably means you’re dumb. You can be so smart and lazy that you can do a lot of things automatically.

If you work in a system or an environment where you rewarded for staying up till five in the morning working on some stupid thing that should be automated, what incentive do you have to automate things? You’re going to get clapped for, and pat on the back if you put a lot of effort into stupid things. Human nature wise, that seems to make sense. That’s like irrational decision at that point.

Jade: Yup. If you’re putting a lot of effort, it must be important.

Clayton: Yeah. Exactly.

Roy: The part that’s really difficult especially when you go to test after the fact is to justify the expense of writing a test. Because you have this working piece of software that your user could be using right now, why not just release it, and then not worry about the test?

Clayton: I’ve heard regression teams be referred to as backstops and people make a baseball analogy metaphor that’s, “The catcher is supposed to be there to catch the ball and that should be fine, right?”

That’s what I think what the developers think of themselves as, “We’re going to do this thing where we’re going to write something, and I’m going to look at it, and I’m pretty sure it works. That’s kind of the catcher, but in case there’s some wild crazy pitch edge case that gets past me, at least there’s a backstop.”

Pretty soon, they stop trying to catch the ball and everything is just the backstop. I think that’s what happens. Why would you spend the extra time to make sure no bugs or no defects or problems or no nothing ever got to the regression team, because they’re always there?

You know they’re going to be there. If something goes wrong, wouldn’t you rather someone blame them than blame you? That’s always…

Roy: Then you get into that whole QA developer rivalry, too, where you hate them because they’re making you do more work. You don’t get to work on new stuff, because they keep uncovering the crap that you wrote earlier.

Clayton: I really like the way that some people in the QA or testing or whatever community talk about testing versus checking. Those are the things that a computer can do. Making sure that this algorithm works properly in these different cases or whatever.

I really like that idea where testing is more about heuristics and looking at, “How does the system function, and what do I expect to happen? What people perceive and is it consistent with the rest of the thing?”

All the stuff that you, actually, need the human brain for. Those are valuable things that people could be working on, actual people. Everything else really should just be automated. [inaudible 06:56] should be automated testing.

Jade: You posted a really awesome article, I think at the beginning of this week, about a case where a company neglected to use automated deployment. In this case, instead of automated testing, but another case where something is done repetitively and there was an opportunity for automation that wasn’t taken. In this case, I think it ended up costing that company $365 million.

Clayton: Some trading company, right?

Jade: Right. We’ll attach the article to the description, but it was pretty crazy. They break down exactly what happened, and it ends up being, “We just didn’t automate something that should have been automated.” Now it’s human error that comes into play.

Derek: I see some funniness in that one of the things that had come up in some the discussions today, too, was, “Well, one of the things that QA is really incredible for is our business rules are so complex that nobody understands them. Literally, nobody actually understands the business rule.”

The great thing is what we do is we have QA, what would happen is you would basically code the story as a developer, and as you code the story as a developer, my fantastic test plan is going to cover every edge case, so that I can actually tell you how you didn’t understand the business rule.

When I think about that, it sets the fallacy that this stuff is so difficult that we’re going to have humans try to remember how it works. Like, “I’m a human, I know that doesn’t work.”

Clayton: That sounds like the exact opposite of how it should be.

Roy: Right, where if it’s super complicated, and you’ve got this thing, shouldn’t you have the computer be checking that it’s the right thing? Then make it happen faster so that I can get immediate feedback.

Derek That’s what I was kind of saying is, “The problem is that if I go and I code this thing up and it takes me five minutes, and I hand it to you to run your test plan, and it takes you two days to give me feedback, that’s really irritating. What if I could run a 10 minute build and get that feedback immediately, and make an adjustment?

That’s when it just blew up into, “It’s impossible that you could ever have a 10 minute build.” I think the second part I think that the thing was, “Great, if we really automate that stuff, what happens to us as a manual test team? We’re still going to have to do a bunch of stuff.”

I think, if we look at some of the best companies in the world that are really doing continuous deployment well, they’re not having manual testers test. They’re having real users test. When they deploy something, they deploy it to a small set of people or to a small set of systems, run tests on them and continue to get feedback, and continue to let things deploy as they get more and more feedback.

I think in order to be competitive, especially in the kind of high tech space, you’ve got to get to the point where your crap’s automated, man. I just can’t see hanging with the big dogs if you’re sitting out having manual tests. I just don’t think it’s reasonable anymore.

Jade: There’s actually a ton of freedom and liberation in having those things automated, right?

Roy: Sure.

Jade: There’s no need to have human slaves that are doing that. I’ve been reading a lot of Buckminster Fuller, and he talks a lot about freeing the human race from being muscle reflex machines. That’s what computers should do for us. They should free us from having to worry about those types of details, and those repetitive motions that can be fully 100 percent automated.

Roy: Many of those QA people are valuable people that could be contributing so much more than just a menial task…

Jade: Right, than following a script and clicking buttons.

Derek: One of the things I kind of brought up is that in many instances the QA people have the largest amount of domain knowledge in the company. They could be the front and centre of helping to find the product and helping work with customers, because they’re the ones that understand the product most intimately.

Instead of putting them out there helping them make the product better, because of their understanding of the product. Instead we have them doing the menial labor of kind of like sweeping the shop floor every night, which is just ridiculous.

Clayton: I think one thing maybe we’re glassing over a bit is if you already have some big kind of legacy kluge system that it’s not very well tested, maybe has a big manual test sweep. What is the first step in fixing that problem? How do you even start automating things?

Derek: One of things that I’ve been recommending because it’s something that comes up is at the beginning of the sprint the testers don’t have a whole lot to do. QA doesn’t have a lot to do, because there is no code ready for them to test.

Normally what they’ll do is they’ll start to write their test plans. Do the shell of their manual test plans. Then, what happens is at the end of the sprint, the developers don’t have anything to do and this is one of the big complaints about Scrum on teams that work like this is, “Hey, it really sucks, I waste my time because there’s three days left in a two week sprint where I’m not allowed to do anything, because I can’t bring new work in because there will be no time to test it. What do I do with my time?

A lot of times I’ll see Scrum masters say, well what you should do is you should go help the testers by running manual tests. What I’ve been recommending is you should help the testers by helping them automate the tests that they need to be writing, or should be go finding code that is the most complicated code that causes you the most grief. You should be writing tests that surround that code.

In that time that you really can’t go grab new code, because you won’t have time to test it you should be helping the team move towards automation. Starting to create that path and create those good habits, the other thing I intend to say is in a bare minimum start unit testing in all new code you write.

Clayton: Even that’s pretty hard. The one thing I always tell people if they want to go towards automation is it’s probably going to be 10 times harder than you think.

I think for a lot of people it’s kind of like, “OK, we have the manual tests, I can just automate those.” But then you start doing that, if you want to make good choices you end up getting to a point where you really do have to go back and re look at a lot of the stuff.

It takes some skill to be able to go in and look at it, some legacy code base. Legacy [inaudible 13:14] two weeks ago, kind of thing. Be able to go in there and say, “Where can I add some tests?” or “How can I pin this code down, so that I can actually test it and get it under tested, so that I am confident in that test sweep.”

Jade: Yeah, but if you do it for humans, doing testing by clicking around those are some really easy places to start automating. There is lots of great tools out there to automate the clicking around and report exceptions for you.

The last place I was coaching at we ran into this problem where huge legacy system, and I started showing the regression testers how to use Selenium and some tools. There is definitely a lot of challenges in just getting the environment working.

They were able to automate the 80 percent of the everyday stuff, and that freed them up to make much better contributions.

Roy: Yeah, for all the people that have the excuse of our environment is so specific that we can’t really test in an automated fashion. I am willing pretty much to guarantee that there is probably somebody else that ran into the same problem was sick of it, and came up with some way to deal with it.

It may not be pretty. We saw crazy hack together solutions using all sorts of different technologies just trying to get something to work, but it’s still beats having human beings click through that stuff.

Derek: Then I think the second thing is where I see complete lack of automation that causes a lot of team’s pain as round deployment. Whereas, the deployment process is so painful and every time someone deploys they screw something up, and because every time they do something, and they screw it up, a bunch of process comes out about it.

Now you’re not allowed to deploy, you have to fill out a form, and you have to go before a deployment board. Only certain people have access to the production environment. It just cascades into ‑‑ it takes two days to deploy a five minute change. Are you guys seeing stuff like that anywhere?

Clayton: Yeah. I think there’s a lot of rules. I’m getting put around deployment. It’s the same stuff, where you can’t automate it because of some usually like some silly technological problem. People don’t know just how certain things could work or there’s some fear around it where we can’t deploy automatically, because if do that then we won’t get the release notes and user update information out in time.

Like coordinating a bunch of different departments that are all doing things in kind of a dumb way. That you could solve those problems, but people usually just avoid that, like we only deploy every so often so I’d rather just do it manually.

We’d rather pick one poor person that has to stay until nine o’clock to press the button than fix the problem. It’s easier doing that.

Derek: I think maybe some of that in the manual testing as well, is people don’t even know the tools exist. I think that’s part of it. It seems so scary, because I’ve never seen it done before, so I don’t even know that tools exist to help make this stuff easier.

Jade: Yeah. It does look like magic, if you’ve never seen it before.

Clayton: If you’re a windows developer.

[laughter]

Jade: On that note that’s all the time we’ve got for today. Thanks for listening to our weekly podcast.

Jade Meskill: Welcome to the Agile Weekly Podcast. My name is Jade Meskill.

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Clayton Lengel-Zigich: I am Clayton Lengel-Zigich.

Jade: Derek you had a topic that you wanted to talk about today. What is it?

Derek: Yeah, something I’ve seen a lot lately is when teams start to really get agility they really start to get high performing. One of the things they tend to do is go around roadblocks. They tend to start to basically, maybe choose some things that the higher powers in a large organization aren’t comfortable with them choosing. There becomes this divide that starts to say, how come you’re not following standards?

Whether those standards are set or whether they’re not set. Whether it’s an architecture thing. Whether it’s a language choice thing. Whether it’s a process thing. You name it. At what point does being agile in supporting the best ideas, and moving forward, and having the people closest to the work make the decisions about the work start to compete with centralization and efficiency?

The problem is if everybody uses .NET, then we get the benefit of people can jump from team to team, or we get all the benefit of being experts in .NET. But if you’re doing Ruby and I’m doing Java and you’re doing .NET and you’re doing C# and you’re doing whatever, now we lose all of this efficiency.

There’s this tension between “We’re trying to be innovative and just go as fast as possible” versus “Don’t you want to be efficient, and have standards that we get benefit, or this economies of scale?”

What have you guys seen in that area? Where do you sit on that sort of thing?

Jade: When you started talking about this I remember a time when our team had started to deal with some of this, our Integrum team, and tried to standardize on certain libraries, and certain techniques, and things like that.

We kind of went through this phase, exactly what you were talking about. From what I recall it was a total disaster. We were even using the same language at that point in time.

Derek: If you guys would all just use Emacs I wouldn’t have been such a [inaudible 02:19] about it.

Jade: [laughs] It really hampered the ability for teams to make the right decisions that were right for the project that they were working on. It became this whole committee situation, and in the end we completely abandoned it, because it was not functional for what we needed.

Derek: I see a couple of benefits and problems with it. I think that it’s nice to have things standardized. The thing I can remember at the time was, everybody was setting up servers a different way. When I had to deal with a problem with some client, and I went to go log into the server, shit was all over in different directories. People were using different stuff. When you really talked to them, there was no like, “Oh, we did it this way, because of this.” It was just, “Oh, I don’t know. I liked Apache, so I used Apache even though everybody else was using Ngnix.

Great. Add in an extra four hours to me, figuring out what the problem was, because everything was non-standardized. I think one of the things that we started to do that worked really well, was to treat things more like an open source project. If somebody had a good idea, people would support that. If people wanted to fork it or do something else, there wasn’t a whole lot of, “No, you can’t do that.”

But if it bit somebody else in the ass, people were not nice to you about it. It’s like, “Hey. If you weren’t going with the best idea that everybody had, fine, that’s great. Do your own thing. But don’t expect a whole lot of support when you’re out on the island all by yourself, and you’ve gotten yourself into trouble.” I remember one distinct incidence where we were talking about moving, I think, to Home Brew or something. Nobody really wanted to move to that. We were a little concerned.

Somebody said, “No, I tell this is the best thing ever,” and somebody said, “OK. Well, if something goes wrong, I can punch you in the nuts if it’s problem.” The person said, “Yes, it’s fine with me. I believe in it that strongly.” I think sometimes to me it’s not about having standards in the sense of written rules and policy. I think that’s when you get in trouble.

But I think when you have — I won’t say, best practices — but when you have some consensus and some alignment about trying to be good, as long as you have the door open to explore, and try new things, you’re OK. It’s the minute that it’s like, “Well this is the way we do it, and you can’t do it any other way, no matter what.” That’s when it gets really dangerous.

Roy: I think the idea of standards — I don’t really like the idea of standards. I think that if you have a particular way that you want something done, and you want to have everybody do it that way, you need to make that the easiest path for everybody. In your example, if I want somebody to use Apache, I’m going to make it really freaking easy to set up an Apache installed the way I want it set up.

It’s going to be so easy, that you choose Nginx, but it’s going to mean a lot more work for you. That way I’m not forcing my standard down on you, but I’m giving you a lot of incentives to use my standard.

Derek: I think that tends to be the open source model. Which is, if I fork it and make it easier, people will use my stuff instead of your stuff.

Jade: It’s technical Darwinism.

Derek: Right. But it’s a lot different than saying, “Hey. Use mine, or if you don’t use mine, I’m not going to help you.”

Jade: Right. Mine was approved by the architectural control group.

Roy: One of the things I’ll say that I see on a lot of new teams too is the opposite of that. What happens when somebody says, “I think that we should have 80 percent coverage, or 100 percent unit tests.” Or, “We should do this instead,” and now you don’t allow anything to come into this source tree that doesn’t have those. Isn’t that a standard?

Clayton: Yeah, but that’s a lot different all of a sudden.

Derek: Oh, so your standards are OK, but my standards aren’t.

[laughter]

Derek: Oh, I see you’d think, so I am maintaining a project, and you’re trying to contribute to it, I want to say that I have a standard that says, at least 80 percent source coverage, before I will take your request? That I totally agree with. I think that’s fine. I just disagree with the idea of me enforcing my standards on you, on your project.

Jade: I think Darwinism also comes into play there. If your standards are unreasonable, and nobody can give back to you, well people are going to stop working with you, and you’re going to die and wither on the vine.

Derek: Right.

Clayton: I think it’s one thing for a team to be principled, and have certain values to say, “We want to be technically excellent,” or something, and that means that we’re going to really value test driven development. Or, “We really care about testing,” or something like that. I think that’s fine to have standards like that, because I don’t think those are so much like rule standards as they the values of the team.

Do you want people in the team to live the values? I think those are a little easier pill to swallow. I am personally a fan of having things more standardized on it at the team level. I think there’s so much time wasted and dumb on purpose stuff that goes on, around people trying to use different things in their little pet project and [inaudible 07:13] work.

Derek: Why is it OK at the team level but not at the org. level, or at the company level?

Jade: I think that at the org. or company level, the values or the influence those have, I think those just get more and more abstract.

Clayton: Yeah, they’re too far removed from the problem that’s being solved.

Jade: Yeah, I think if you were to say, “We have to use Java for everything,” that might not be the right thing for everything. If your biggest problem is that you have people that work for you, that can’t work on your Java project, and then go work on the Ruby project, you don’t want those people working for you, right? You’re not losing efficiency because there are two languages.

Derek: Why would I not want the expert? Why would I not want the guy that wrote Java to work for me, and he doesn’t want to work on Ruby. He’s got 20 years invested in that. He is the absolute best person ever at that.

Jade: Right, but you’re going to get the person that’s the best person at Java, but that’s not really where you’re going to get value out of using some particular technology. It’s not like if you took that person that’s a 20 year Java expert, that’s all they’ve ever done, and you put them on some project, they’re going to instantly make it better.

Derek: But what if I believe that the person that knows 20 years’ worth of Java is better than the person who knows six months’ worth of Ruby? To me, even though Java might not be the right tool for the job, this guy knows so much about Java. This girl knows so much about Java, that they’re going to do it better anyways, a better tool to do it, just because they’re more experienced.

Roy: I would challenge your beliefs and say that maybe your beliefs are wrong.

Clayton: I don’t doubt that that’s possible. I think if you took someone who’s an expert chef and you give them a bunch of crappy ingredients, and a crappy situation, they could pull it off, because they have that expertise, and they have all that stuff. I think that’s fine, but I would question how frequently that scenario comes up, where the biggest gain you get would be out of having the [inaudible 09:01] expert.

Derek: I only hired experts clay.

Clayton: Yeah, and I think a lot of people have that mindset, where they think they only hired the best people. Most of the people that I’ve talked to that think that they hired the best people, they really can never tell who the 10 times programmers are, anyway. I think that they’re chasing unicorns at that point.

Derek: The unicorns that they do find tend not to actually be the best people, in my experience.

Derek: Let’s say it’s not language. Let’s say it’s desktop operating system, or let’s say it’s server operating system. You name it.

Jade: I think it comes down to conventions are very handy things to have. It’s when they become policies that it can become inflexible, and ruin some of your creativity, and your ability to adapt to the situation at hand.

Derek: I think for me, where I get uncomfortable is the minute that somebody says, “We can’t do that because…and the answer is…”

Jade: The policy blah, blah, blah.

Derek: Or some standardization. “We can’t do that because Windows Server doesn’t do that.” Or, “We can’t do that because Ubuntu doesn’t do that,” or, “We can’t do that, because Apache won’t do that.” “We can’t do that…” The minute that I hear that it’s, “OK, so you’re not willing to innovate.” You were willing to sacrifice being able to do something you can’t do right now that somebody wants you to do, to hold on to some standard.

Roy: I think a team can have standards for itself. Why a team and why not an organization? I think a team can have standards for itself, because it is being held responsible for the problem that it’s trying to solve, and everybody is present. If they want to change the standard, they can do so expeditiously. An organization cannot, because they’re solving a whole bunch of different problems, and they can’t dictate a universal solution for all of them, and they’re not being held responsible for any of them.

Derek: But are they being held responsible? Meaning what if the team goes away and the organization still has to support that? You’ve got a team of four people, they did go off on this path and they do something completely non-standard, and it’s really awesome, and it solves the customer’s problem, and it’s really great. Then all four of them get pissed off about something or they get some great new job or they get hit by a bus.

Jade: They win the lottery.

Derek: Yeah, they win the lottery pool.

Jade: That’s the HR term.

Derek: Now you’ve got to have somebody else go support that.

Clayton: I think that’s the risk, that’s the trade-off. You can have the policies where you say, “Oh, we can’t do that because you can have that scenario,” or I think you can have that other extreme, which is, everyone can do whatever the hell they want, and there are trade-offs to both of those.

Jade: Does this come back to the inherent tension between creativity and efficiency?

Derek: Yeah. For me, I always like to explain it. I think there’s a slider button. One polar opposite is innovation or creativity, and I think that’s rooted largely in chaos. Then, if you slide the button all the way the other way, you’re basically in efficiency, which is usually rooted in standardization, policy control. I think you can slide that bar any level you want to find the balance, but what I tend to find is organizations have trouble setting that bar.

They either want to slide it all the way to the right, or they want to slide it all the way to the left.

Clayton: Usually always left.

Derek: The teams underneath, want to adjust it somewhere else. Where I think if organizations said, “We’ve got a scale of one to ten, and we’re going to say between one and three is acceptable,” or, “four and six is acceptable,” or “seven and nine is acceptable,” and then let the teams underneath them, or the organizations underneath them fine tune it for them. I think they’d get a lot better results, but instead I think it’s just this constant tension of team versus org, versus big company.

Jade: I think mature teams will have the slider closer towards the standards for most things, but when they know they could get some benefit out of being more creative or chaotic, they move the slider that way. I think teams get into a lot of trouble, immature teams especially, where they move the slider to the creative side, for the sake of being creative. It’s like “We’re going to do this thing that we could do already using the things we know, but we’re going to do it in this whole new thing that nobody knows we have to support, blah, blah, blah…” That might not be around in six months, just because it’s a cool new thing. I think that’s pretty stupid. That’s dangerous.

Derek: Right, well there’s safety in chaos, because nobody can hold us to the fire.

Jade: That’s true.

Derek: If there is no standard, nobody can say you’re doing it wrong. I think there’s a lot of immature teams that want to jump into that. It’s the classic early-adopter of technology. You probably don’t want to be bleeding edge, to the point where you’re spending all your time trying to get your technology to work. But at the same time, you don’t want to be a laggard, or a late-adopter to the point where you never get any benefit.

You want to be riding that wave right at the top of the crest where you’re probably one of the first people adopting it, but you’re adopting it just at the point where it’s mature enough that you’re having to tweak it a little bit, but you’re not spending all your time tweaking it. That’s such a hard sweet spot to find.

Jade: It’s the hardest place to stay.

Roy: But I think a mature team is really focused on delivering value, so they will try to find that sweet spot on their own.

Jade: The best people I’ve worked with are very situationally aware. They know when is the right time to move that dial. It’s not even on a whole project. It might be in this particular situation. When’s the right time to be a little bit riskier, when’s the right time to be a little more stable.

Clayton: Stick with what you know.

Derek: The blog post that’s coming in my mind right here is the big wave riders. These are the guys that go out there and they’ll sit, and they’ll paddle, and they’ll wait. People are like, “Man, that person’s dumb, they’re not taking any waves.” But then magically, they go right when the best wave of the day comes in, and they ride it in, and everyone’s like, “Oh, man! That’s so incredible! Did you see how incredible that is?”

It’s totally crazy for them. I think that really good people know every so often, you have to be patient, but when the right wave comes, you better paddle like hell to get on it, because it’s the thing that’s going to throw you above everybody else.

If you just sit there forever and don’t ride a wave, you’re screwed. But if you ride every wave, you’re going to be tired before the wave that comes that really matters hits. I think that’s just hard. In big companies especially, that’s hard because that takes serendipity to be able to jump.

Jade: Little companies as well. You might die before the big wave comes.

Derek: Or if you get on the wrong one. But individually it takes practice. You’ve got to fail a lot before you can learn.

Jade: You’ve got to know how to sense the wave.

Derek: When the big wave comes, you’ve got to know how to deal with it.

Jade: You’ve got to have the skills to ride it. On that interesting metaphor. Let’s wrap this up. Thanks for listening. Catch you next week.

Derek: Thanks.

Jade Meskill: Hello, welcome to the “Agile Weekly Podcast”. I’m Jade Meskill.

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Jade: Today, we wanted to talk about the dangers of multitasking in agile and maybe a little bit about multiple commitments. Roy, we’ve been having some trouble with this lately.

Roy: Self-imposed trouble.

Jade: Yeah. We should know better but we still fall for the trap. Why do we keep trying to multitask?

Roy: I don’t know. I think it’s our arrogance and thinking we’re different, and that somehow it’s going to work for us when we know it doesn’t work for anyone else.

Jade: So, because we’re really good at this, we can multitask in agile when all other humans can’t.

Roy: Right, even though it’s miserable and no fun at all.

Jade: What do you think Derek? Have you struggled with multitasking in agile?

Derek: I’m too dumb to do one thing, much less two things at the same time. I see a lot of teams struggle with it or actually organizations. Well, I see teams and organizations. I see organizations do it with the multiple resource trap.

I think of somebody is this logical thing that has 100 percent. Because I think of them as this logical binary bit of 100 percent, I can take 10 percent of them and give them over here, 30 percent and give them over here an 60 percent and give them over there.

On paper that sounds really fantastic, but for whatever reason it just doesn’t ever seem to pencil out quite right. I see that trap a lot.

Jade: Interrupt you real quick. That reminds of a cool exercise I did once with a group of managers, who were really struggling with understanding why nothing was getting done. I had them write out an individual’s name on an index card. I had them do that for their entire team and then I had them go and layout all the projects that everybody was working on. We put the projects up on a board and then I had them say like, here’s John.

How much of John is working on Project X? They said, oh about 20 percent. So, I tore about 20 percent of that index card off and you should’ve seen the look of horror on people’s face that I’m like tearing this person into pieces.

I stuck that up by the project and said all right how much is on this and that? We went through and by the time we were done there were these tiny little scraps of people everywhere all over this board.

Because they had way more projects than they had people and that visualization of that problem really sunk in, that holy crap we are really doing something very very wrong.

Derek: I think that’s becoming a common trend very similar to the no estimates hoopla, I think you’re starting to see a no projects thing emerge, which is…

Jade: Is that from you? [laughs]

Derek: No, I said it a few years ago and kind of dropped it, but I think people are picking it back up. I think what people are realizing is that when you do things by project. Projects ramp up, and ramp down, and have overlap. You have to start tearing people. Pretty soon when you do that, you get 10 percent of people and the problem is that it’s never that clean.

When I say “Jade, 50 percent of your time will be on this, and 50 percent on this other thing, and Roy, 50 percent.” What happens is the two projects both need 100 percent of you at the exact same time. It’s not one week I need 50 and one week I need 50 and it works out great. I need all of you right now, and the next week I don’t need you at all. It never is during the same time, so you just get into this total chaos that starts to ensue.

It’s crazy to see how much it helps people to not have that burden, to not be a slave to multiple masters. When they can just say, “I’m doing my best work on this and I don’t have to be constantly thinking about this other thing at the same time I’m trying to be focused on this.” It’s amazing how much freedom that gives people.

Roy: There’s another interesting effect that happens there too. Which is when you’re working on one project and the second project normally doesn’t have a whole lot of pressure behind it, but now all of a sudden it does. Even though the project you’re currently working on has a high amount of pressure, I’ve noticed that now relatively speaking the other project feels like it’s way more important because it’s more important than it normally is.

It makes you way more willing to interrupt what you’re currently doing to work on the other project, which is weird. Even though both are more important right now, because it’s relative importance relative to its past is higher, you interrupt yourself and you get into this weird thing where you’re interrupting between the two projects, and you interrupt your interruptions, and it just keeps going deeper.

Derek: I see patterns too…of one style of pattern is that everybody on the team is a percent, so the whole team that is working on this thing, this product or this project, or whatever it is. All of us are some percent of our time working on it. The product never gets momentum because I have to coordinate my 10 percent with your 20 percent, with your 30 percent, and we can never find the time to meet because we’ve got meetings on other stuff.

We just can’t even coordinate, it’s a total nightmare. Or the other thing that I see is that almost everybody on the project, or the product, is specifically dedicated to that thing and it’s one or two people are a percentile and then they’re like the outcasts because it’s like, “You’re the bastard we can never, ever depend on because you’re on this “other project,” or this other team. We’re having to compete with you, or for your time, and that’s a burden…”

Jade: Which is usually not that person’s fault.

Derek: No, it’s not…

Jade: But they bear all the guilt, and the brunt of all of that…

Roy: Right…

Roy: If you insist on it…If you tolerate it, you insist on it, so they bear at least some of the guilt.

Derek: Well, I think what happens is they become a scapegoat that they can’t avoid. If I get Jade 20 percent of the time on a product, and Jade is a potential bottleneck for me, I can very easily say “It’s not that my work didn’t get done. It didn’t matter that my work didn’t get done because we didn’t have enough of Jade’s time…We wouldn’t be able to deploy anyways because he’s the Deploy Master, and he wasn’t available anyways, so…”

It allows all this weird behavior to start to happen, total victim mentality of “Well, you know, XYZ are roadblocked, so that’s why we didn’t get it done.”

Roy: If you’re that guy, though, or the team that doesn’t allow that type of bullshit to get in your way, and don’t make excuses, it’s really easy to stand out above the rest.

Jade: How many teams have you worked with that are in that condition?

Roy: Only a few, but I remember every one of them, and they all stand out, because…

Jade: Right…It’s not very common.

Derek: The great thing about standing out is it makes it really easy to cut your head off.

[laughter]

Derek: Which is the other thing. When you start as a “Don’t even bother giving me that 20-percent-guy, the 20-percent-release-engineer, because we’ll just do our own releasing.” Now you’ve pissed all over the release teams.

When you’ve got a department of 10 people that are the database team, and they’re used to controlling everything about the database, so they give you graciously 6.5 percent of a database engineer to deal with your database stuff.

If you’re the team that just says “We’re willing to stand above the rest. F- it, we don’t need the database engineer, we’ll handle our own database,” now you’ve just created a shit-storm because you’ve threatened their entirely livelihood. “If you won’t take 6.5 percent of us, what happens when the next team won’t, and the next team won’t, and the next team won’t…”

Roy: Their livelihood should be threatened.

Derek: “Then, we don’t have a team.” That causes all sorts of other angst. I think that’s one of the reasons you see this multitasking in agile, or this dividing up of resources. It’s basically empire building. If I can build an empire of this thing, then divvy it out as a scarce resource, I have a lot more power than if I just focus on a small team.

Roy: It’s like organizational [indecipherable 8:04] union.

Derek: It really is. If I can have a strangle-hold on you, whether I’m an architect, a [indecipherable 8:12] , or whatever, like these siloed groups that “You only get a percentage of my time. You have to plan everything around me, because if you want whatever new thing approved, and I’m the only group that can approve it, and I can’t get you on my schedule, tough to be you,” that’s the way it works.

Roy: “F- that. I don’t have time for that. I understand that you’ll be stepping on some toes, and people are going to get pissed off, but tough.” Nobody has time to sit and wait to be the six percent.

Derek: I tend to agree with that, but I think that’s how those empires built, as people get fearful of “We don’t have somebody who’s a certified…”

Roy: “Or we don’t want to piss off that part of the organization.”

Derek: “Or we don’t want to piss off that part of the organization…”

Jade: “They may have a lot of power.”

Roy: “They may play golf with the boss, or something.”

Derek: I think it’s difficult. Then I think I also see a lot of multi-tasking in agile happening, especially on scrum teams or [indecipherable 9:01] teams, where people have a ownership problem. Maybe we’ve got backlog of tasks, or sprint items, sprint backlog items, or however you want to call them…

Units of work for the iteration, or the sprint, or the cycle we’re in, and there’s five of them around dealing with the database, and I really want to be in charge of how the database scheme and all that stuff is done. What’ll do is I’ll walk up, and i’ll take all five tasks off the board, or I’ll assign all five of them into me, which totally blocks everybody else. There’s no way I can do those all on the same time.

The justifications I see around this are “You know, these are so dependent that the person that defines a scheme couldn’t possibly be the person that creates the model. They have to be the person…”

Jade: “Now I have to show you so much in order to you to even get up the speed, so I’m going to do this great favor and I’m going to bear the burden of doing all this stuff.”

Derek: I see a lot of that.

Roy: This is a warning sign.

Jade: [laughs] .

Roy: When this happens, something very bad is happening and you should stop it.

Derek: If you have somebody on your team that’s the only person on your team that can do something then you’ve already done something wrong.

Roy: So solve that problem, and then worry about multitasking in agile.

Jade: Recently we’ve been talking about [indecipherable 10:23] and competing desires. I think this has a lot to do with that same problem especially at an organizational level where we have competing desires to finish this project. But also this project, even though we can’t actually spend the money or have the people or whatever it is to do them both.

Derek: Are you criticizing that we have got six number one projects?

Jade: Yes [laughs] They are all number ones of course.

Derek: I definitely see this is a prioritization problem is part of the reason why you get these resources allocated this way and when I say resources I am lovingly talking about human beings.

Jade: [giggles]

Derek: We can’t slice human beings as Jade says even when you spread them on a card, it gets a lot of angst.

Roy: [giggles] Right.

Derek: But if you call them resources you can divvy them up…

Roy: Yeah.

Derek: …however you see fit.

Roy: Especially on a spread sheet. Like five Jades. [laughs]

Derek: …but yeah, I think that’s how usually [indecipherable 11:13] , when somebody’s got a resource allocation spread sheet like, I know they are fucked right out of those [indecipherable 11:17]. Like “This is not working for you right?” and he’s like “Oh no, it’s working great, we are awesome.” So you are paying that consultant for what particular reason?

Roy: [laughs]

Derek: But, I think that what happens is it’s because there are so many priorities that what we start to do is like the only way that we can get the ten number one priorities done. Like we can’t laugh that we just said ten number priorities like the mathematical probability or impossibility of that it’s like totally honest. So what we we are going to do is that we are going to get a spread sheet out and see how we can divvy up these toys, so that we can get all of the number one’s done.

Jade: Great.

Roy: Well….

[crosstalk]

Roy: …sometimes it’s not even that organized, it’s pretty frequent that this single point of convergence of all of these priorities is to develop products doing the work. So they have like three different managers that they report to that are all requiring demands of them, and they are the only person that can stand up for themselves and say like, “No I am working on just this and I have to get this finished.” Instead often what happens is that they would go ahead and promise everything to everyone.

Derek: Well. I mean the way the managers get around that is that when they come back and they say, “Woah I owe this to Jade and this to Roy.” What happens, those two managers get together and say well the easy answer to this is we are going to split the baby in half. Well you can have fifty percent of Derek’s time and you can have fifty percent of Derek’s time but take it…

Jade: [indecipherbale 12:28] slice Derek.

Roy: …but that’s already an improvement if that communication happened, because…

Derek: Yeah…

Roy: …because I am not even seeing that most of the time.

Derek: …yeah. I think that’s how people get to the matrix organization. Is they get to the point where they all have number one priorities and so when they get around to talk about it, when they are looking at a spread sheet, it becomes really easy to say lets slice Roy six ways…

Roy: And then everybody…

Jade: Everybody’s happy.

[crosstalk]

Derek: …everybody’s happy except for Roy. Then ultimately none of them are happy because it takes ten times as long to get anything than if they would have serialized them and say lets do the number one project when it’s done we’ll do the number two project when its done…

Roy: And then [indecipherable 13:04] involve start playing that urgency game where they wait until the last moment to uncover their projects that all of a sudden…

Jade: It has to be done tomorrow…

Derek: Oh yeah, you’ll have to wait for the fire I mean if you can say like this is really clearly the number one thing but somebody’s house is on fire, the house on fire is always going to take precedence even if it’s the right thing to say well, let it burn we are building something much better here. You definitely get a fire fighting culture. A fire fighting culture is part of what emerges when you start to have multitasking in agile, multi-commitments…

[crosstalk]

Derek: …when you have competing desires…

Derek: …competing desires, like these are all like signs that your fire fighting culture is coming and then once that starts you are screwed because nobody can think clearly any more. It really is just like we have got a fire truck with a bunch of fire hoses and whichever flame is shooting the highest right now we aim the hose at it until it’s smaller than the next one and then we move back and…

Roy: Which means the fires never go out.

Derek: …we can not figure out why this fire will not go out, it totally mystifies us.

Jade: So how do you solve it?

Derek: For me I think the number one thing is create good solid teams. Let teams form let teams merge, and stop cutting people up and then start to prioritize your work. Start to say that this is the most important thing for our company or our [indecipherable 14:24] our team or whatever it is. Be totally focused on that until you either decide it’s not the right thing or until it’s complete. One of the two it’s you either kill it or finish it. Until you move on to the next thing. The problem is it’s really hard.

Jade: Yeah. My advice is usually stop. Stop the fire fighting, stop the insanity and it’s going to be really, really painful but it will allow you to have a much better perspective on how to move forward. You are right it’s really difficult to stop. I think, Roy and I find ourselves victims of this right now today…

Roy: Yap.

Jade: …we know it, we are self aware and it’s still hard to stop.

Roy: I mean when the interruption happens we are like, “We shouldn’t do this.” But we are going to anyway.

Jade: [laughs]

Roy: …no we are so stupid on purpose.

Derek: No you are not stupid, you’ve got a lizard brain and people like to be heroes. Why we call it fire fighting culture like we celebrate fire fighters. Fire fighters are these really great people that make a lot of pain go away, and are really looked up as heroic.

Jade: Yeah. It’s true.

Derek: I think that’s part of it. People pat you on the back and say awesome job, when you drop everything and solve their problem for them. The problem is you probably half-assed solved their problem for them and you create another fire. So it’s like on one hand you get rewarded for the effort and you get rewarded that you have got some immediate “hey you made the flame get smaller.” But…

Roy: But the best fire fighter would have prevented the fire from getting started…

[crosstalk]

Jade: And If you say no you are a villain.

Derek: Correct.

[crosstalk]

Derek: “How would you let my house burn down?” Well because I don’t another 6,000 acres to burn so, sorry.

Jade: Yeah, but that’s a a hard pill to swallow.

Derek: Yeah. It’s not as nearly as fun as being a hero that’s for sure.

Jade: That’s true.

Derek: I am bringing matches to work…

[laughter]

Jade: That could be dangerous.

[dropping sound]

Jade: Well, that’s all the time we have, thanks for listening to “Agile Weekly Podcast” catch you next week.

Jade Meskill: Hello, welcome to another episode of the Agile weekly podcast, I’m Jade Meskill.

Derek Neighbors: I’m Derek Neighbors.

Roy VandeWater: I’m Roy VandeWater.

Jade: Roy, will you tell me what we’re talking about today?

Roy: Today we will be talking about asking for help.

Jade: Oh! Will you help me figure out the next question?

Roy: No.

[laughter]

Jade: Derek, will you help me with the next question?

Derek: Yes.

Jade: What’s the next question?

Derek: The next question is, “When should you ask for help?”

Jade: When should you ask for help?

Roy: All the time.

Jade: All the time? You just don’t know anything?

Roy: When shouldn’t you ask for help?

Jade: That leads to a good question. Why don’t people ask for help? If you should do it all the time, why don’t people do it?

Roy: I think a lot of people are probably afraid to be perceived as not knowing something, as OK as that is. Obviously, there’s nobody in the world that knows everything.

Jade: Do smart people ask for help?

Derek: Sometimes.

Roy: Wise people ask for help. I don’t know about smart people.

Derek: I think there’s some cultural baggage around that. In some cultures it’s perceived as if you ask questions it means you’re dumb.

Roy: Yeah.

Jade: It’s a sign of weakness.

Roy: Yeah. I’ve talked to people where they feel they ask questions during a job interview, and they feel like the candidate Googled an answer, for example, then that is looked down upon. That is a point against the candidate, and they’ll probably not get hired.

Jade: What do you think it is?

Roy: What, Googling?

Jade: If somebody did that in front of you while you were trying to interview them?

Roy: If they don’t know the answer, and they’ve asked me and I don’t know the answer, and they don’t Google it, I would be like, “Have you not heard of this? Have you been living under a rock?”

Jade: [laughs]

Roy: If I’m hiring people, I don’t care if they know the answer themselves, I just want them to produce the product. If they rip it all off of Google, as long as it’s legal I don’t care how they get around it.

Derek: I think there’s some stubbornness involved, also. There’s some people who feel like “If I give you something you have to give me something in return. Therefore, if I ask you for help, then somehow I’m enslaved to you, and you could pull that card out at any time.”

Jade: So I’m in “Help debt.”

Derek: Maybe I don’t want to get into debt.

Roy: Maybe the opposite. Because there’s also a lot of cultural baggage around being asked for help. Especially when you look at how people ask for help normally. They say, like, “Derek, please close the door.” It’s not really asking, so you don’t get to really say “No.” By me asking for help, I’m kind of socially obligating you to help me.

Derek: If I said, for example, I need one of you to volunteer to [indecipherable 03:13] this podcast, that would not be asking for help?

Jade: No, you’re kind of commanding help.

Roy: I’ve heard that called being “Volun‑told.”

Jade: Volun‑told, yeah.

Derek: My immediate reaction to that is, “Screw you, buddy! I’m not going to help you. Don’t tell me what to do.”

I know that I don’t like to ask for help. I have a hard time with it. I like to know things, and I like to learn things and figure them out. I’ll definitely Google things, I don’t have a problem with that. But maybe the more subtle or insidious things, that I’m surrounded by smart people who probably have the answer, but instead I’m going to be dumb and learn it the hard way.

Roy: I wonder, too, if there is a bit of trust that’s missing. If I ask somebody for help and they provide it, now all of the sudden I have to take their help, almost, because I asked for it.

I’m not saying you actually have to, but socially it’d be really awkward if I asked Derek for help, and he gave me help and I said, “Nah, that’s not the help I’m looking for. I don’t want your help anymore.”

Jade: Yeah, I think that we think it’s this really high cost thing, too. In reality the amount of time it takes me to ask for help is the entirety of the investment, and if I get the help I gained a whole lot for the amount of time that I asked for it. But if I get a “No,” or I get help that doesn’t really apply, I’m no worse off than I was before I asked for help, except for the small amount of time I spent asking for help.

I think that we forget that. We forget that it’s a really low cost thing to do, because it takes a lot of courage to do it. It feels expensive even though it’s really cheap. I think for me, a lot of times I’ll be OK at asking for help if it’s present and in my face.

If I’m sitting here struggling with a technical problem and the two of you are sitting in the room, I’m probably pretty likely, the minute that I get blocked, to ask one of you two, because I know you’re both really bright and know technology.

But if the two of you aren’t in the room, but you’re on the end of a chat channel across the way, and I don’t have that chat channel open and I run into the exact same problem, I might fight with it for 30 minutes before I go, “Oh, wait! I could get ahold of them on IM!”

Sometimes I think presence makes it difficult too. If the people that we think are available to be helpful aren’t immediately present, we don’t think about…the barrier of typing an email and waiting 10 minutes for a response is probably still better than beating my head into the wall for 30 minutes.

Or we think that people maybe don’t know the answer. Gangplank is a really interesting place, which is a collaborative workspace that we’re in a lot, where we record this podcast. It’s not uncommon, if there’s 50, 60 people in the room, that you might pop up and say, “Hey, will somebody help me by telling me where a pair of scissors are?”

That’s really low‑cost, and the reality is somebody probably knows where those scissors are. But if I sit there and look at all 50 people, and I say, “I have no idea which one of these 50 people would know where the scissors are,” I might not ask any of them.

I think it’s getting over the barrier of, even when you don’t know who can help you, sometimes just saying, “I need help” is helpful. The person drowning that says, “I’m drowning,” generally gets a life raft. The person that doesn’t say that doesn’t get the life raft.

Roy: It’s interesting, because people in general like to help. People like to receive the attention and to take advantage of knowing something that other people don’t.

I think there’s even probably a little bit of, I don’t want to say it’s malicious, but a little bit of one‑upmans. Like, “Hey, I’m helping you, because I’m able to do something that you can’t, so that gives me a little bit of self‑confidence boost,” or whatever.

In fact, I’ve even seen people help when it’s not even asked for and when it’s not wanted, just to have that either one‑upmans, or just to help out.

Derek: One of the things I find very interesting is that people do not like to ask for help, but damn, do they like to give it out, even when it’s not solicited.

Jade: [laughs]

Derek: We really like to rescue people, but we don’t like so much to ask people to help us, which is really odd to me. You think that it would be…

Roy: The other way around.

Derek: An even metering out.

Roy: Because helping people out has a way higher cost associated with it. It actually takes time.

Derek: Something in our wiring makes us want to help people. If we know that we like to help people, even when they don’t ask for it, wouldn’t we think that, when we want help, that…

Jade: People who want to help?

Derek: People would really want to help, but it’s like we’re wired the opposite way.

Jade: If asking for help is cheap, and waiting too long to ask for help is very expensive, how do you create a culture of asking for help?

Derek: I think the same way you create a culture for anything you want, is you just have to model the hell out of it. I think you have to insist on it. You have to constantly be in a mode for modeling that behavior, potentially even asking for help when you don’t necessarily need it.

I think you also have to model that it’s OK to say “No,” so that you don’t create a culture where people feel obligated to help when they’ve got other priorities or other things, and that people don’t get offended when they’re told “No,” that they get a healthy dosage of what it’s like to ask for help and get it, but also ask for help and maybe not get it, or have it delayed, and that that’s OK, too.

It doesn’t mean that if I ask you for help and you say “No,” that it doesn’t mean you’ll never help me again.

Jade: Or you hate me. [laughs]

Derek: Or that you hate me, or there’s something personal, but that it just might be you’re really busy trying to do something else.

Roy: Or have no knowledge to help you.

Derek: Or I don’t have the ability to help. I think it’s just modeling that a lot. I think you have to model it a lot. I think it happens pretty quickly when you get results.

I think when you ask for help and you get help, it feels like you’re cheating. It’s almost like, “Damn, I’ve got the stables easy, but [indecipherable 09:19] smacking this sucker over and over again, and it’s getting easier and easier the more I do it.” I think that it becomes a pretty Pavlov response of, “I really like this thing, so I’m going to do it a little more often.”

Jade: You’re saying, if you are feeling like nobody around you is asking for help, that’s probably a good indication that you need to ask for help.

Derek: Yeah. I would say, if nobody is asking you for help, that probably means that you don’t ask anybody for help.

Roy: I’m pretty sure, though, that the quantity that I think we have a mutual understanding of, is not what most people are thinking of what we’re talking about. I’m thinking about asking for help multiple times an hour, maybe a dozen, two dozen times an hour. That’s once every few minutes. That’s not once a day or twice a day. It’s a lot.

Derek: How could you possibly need help that often?

Roy: I do a lot of complicated stuff.

[laughter]

Roy: I’m a very dumb person, so I do a lot of…

[laughter]

Derek: Can you give me some examples of how you’re asking…

Jade: Actually, you’re a very smart person, if you’re asking for help a lot.

Derek: Can you give me some examples of how you asked for help today?

Roy: [indecipherable 10:20] multiple times, where Jade and I were pairing, and I didn’t understand something, so I asked him to explain things that were going on, I asked you guys all for help in reminding me of something that I knew I had forgotten, and I was hoping you guys would know.

Likewise, I asked for help in remembering whether or not we were going to an event tomorrow, or next week Thursday, and I think there were several other times as well. I can’t remember all of them. Those are a just the ones that come to mind.

Jade: I had to leave and you still ask me for help over IM.

Roy: I think you asked for help quite a few times too, when you were off doing some completely unrelated.

Jade: Yeah, I left all my stuff somewhere, I asked you to help me bring it back.

Derek: What does an organization that asks for help a lot look like? How does it look different than an organization that doesn’t ask for help?

Roy: Noisy.

Jade: Yeah, noisy. I think it’s a place that feels good, feels high energy. I think “Ease” would be a good word. It’s really easy to be part of an organization that asks for help a lot.

Roy: You probably have a lot of trust and appreciation for the people around you, because you’re constantly getting help from them.

It’s like, “I know I don’t have to worry about this, because I know you three got my back, because I’m asking for help all the time, and you’re responding positively. I don’t have to sit there and worry that someday in the future I ask for help for the first time and you guys will say, ‘No.’”

Derek: Do you think maybe one of the reasons why a lot of organizations struggle with asking for help, or don’t have a culture of it, is that maybe people are isolated?

Jade: Yeah. I think just like you said, when it’s not right in your face, there is some weird psychological barrier. Even if it is pretty low and pretty cheap, if I can ask you a question right now that we’re sitting face‑to‑face, versus having to send you some sort of text message or something like that, that’s going to significantly lower my desire to ask for help for some reason, even though it’s still really easy.

I think if you’re not together, not even just physically, but if your presence is low, even virtually, it creates an enormous barrier to asking for help. I know I would feel like I’m inconveniencing someone. If I don’t know that they are present in here with me, I’m pretty sure I’m interrupting them or causing them some sort of problem.

Roy: Which is interesting, because they can then say “No.” If you’re interrupting somebody, there’s no reason they couldn’t say, “Hey, no.”

Jade: Yeah, they could certainly say “No.”

Roy: Or, “No, but try again in 10 minutes.”

Derek: I see this a lot. If I’m in a cube farm, or if I’m in an area with offices, the barrier for me to get up and go to somebody, while that’s not really high, it’s a lot higher than just turning around and asking them or looking across the desk. But I think the real barrier is it really feels like I’m interrupting them.

At our house with kids, and dogs, and animals, the bathroom is the sacred place. It’s the only place nobody bothers you. I think in a lot of companies, cubicles or offices become the sacred place. I see people walk up to cube walls and knock on the cube wall like it’s a door. Like “Knock, knock, can I come in?”

Think about the barrier to that. If I want help, I literally have to knock. I have no idea what you’re doing, I have no idea if I’m really interrupting you.

If I can physically see you and I can see, “Hey, you just hung up the phone, I know you’re done with that phone call,” it’s a logical time to say, “Hey.” If you’re really busy, you’ll say, “No,” but I know you’re on the phone. Whereas I get up, I walk over, you’re on the phone, do I stand there and wait? What happens?

Jade: Yeah, that’s a really great point. That reminds me of when I was much younger, and managing my first team. I was much less wise then, and I had a private office, and nobody would ever come and talk to me.

They were making terrible decisions, and I was always mad and very unhappy with, “Why aren’t they asking me for help? I have these answers, I know how to help them, and they’re just not asking me for help.”

I remember we decided to move. I moved out of that office, I moved in with the team, and that really made such a huge difference of just being physically available to them.

That’s all the time we have for the Agile Weekly Podcast. Thanks for listening. Talk to you next week.

Roy: Will you help us by having a discussion with us on our Facebook page at facebook.com/agileweekly Thanks.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich…

Roy VandeWater: I’m Roy vandeWater…

Jade: I’m Jade Meskill…

Derek Neighbors: I’m Derek Neighbors…

Jim McCarthy: I am Jim McCarthy. You got me in here.

[laughter]

Jade: We found this guy…

Jim: A major breakdown in their standards has occurred.

[laughter]

Jade: …stumbling down the street, away from shelter.

Clayton: It’s like the Hotel California. You may enter, but you may never leave.

Jim: This is my second time to Chandler. There’s been no trips up to Crystal Lake. I can see that the mass of things…It’s pretty cool down here. Actually, it’s pretty hot. But it’s a pretty cool place to be. I’ve got to admit. So, I’m glad I’m here.

Roy: That’s good.

Clayton: We’re glad to have you.

Jim: I’m going to get you up to Crystal Lake. We’re going to do the pod cast up there, too.

Clayton: Today we wanted to talk about presence over planning. Presence is more important than planning?

Jim: I’m willing to talk about that. I was just suggesting that as the basis of our starting this podcast.

Clayton: That seemed like a really good idea. I figure we should talk about it.

Jade: We are present, and there’s been no planning. What a better opportunity?

[laughter]

Jim: [inaudible 01:21] could pretend there was planning. We’re doing a boot camp right now. We’re in the first part of the boot camp and it’s just starting to get rich. I get off when they start to get off. I’m excited, enthused, and happy and I’m in.

Jade: Welcome.

Clayton Welcome

Roy: Welcome

Jim: It’s beautiful to watch.

Jade: That’s awesome. Much better than yesterday. That’s for sure.

Jim: It’s amazing how a little bit of time and persistent focus from their boss makes a big difference.

Clayton: What’s the trouble with planning?

Jim: It’s just fictional. It’s like science fiction. You could write a good science fiction book. That’s something to do about [inaudible 02:12] that’s basically a plan. I have always found, especially when it comes to talking, that your presence will trump your planning every day of the week.

I’m in this room. We got four high end or nice microphones. We’ve got a mixer. We got four men, plus me. Whatever that means.

[laughter]

Jim: I’m looking from my perspective, there’s four men here. Anyway and we are going to talk because we are getting to be friends and its probably going to be interesting cause we are in the middle of this interesting experience. So, that’s what I meant by our presence would probably trump…

Jade: Uh, I’ve definitely been in planning meetings where there is no presence…

[Others agree]

Jade: … those are really terrible…

Clayton: It’s going through the motions, but, uh, half the people are thinking about …

Jade: …they are just doing work, or…

Clayton: …yeah, they’re just trying to get through it.

Jade: And the results are usually very poor.

Clayton: Yeah, I found that you can energize a team if you get everybody involved in what they are doing, which I think is getting towards having presence over planning, so that they actually feel like their physically there, they feel like their mentally there and they feel like they are actually in, you know, they are in to what’s going on.

That makes a bigger difference then any other game or gimmick or technique or whatever anything I would ever really use.

Roy: So it’s the specific value that we are trying to get out of both presence and planning. Like, we are saying presence over planning, but in terms of what?

Derek: So to me, like, I almost think that planning is evil. It’s almost like discussion in the sense of, planning is not doing, right, if we are planning were not doing, we are planning.

People get bogged down in the, just like they get down in the perfection of doing, so they never ship. If you just do and never ship that’s a problem too. Well if you just plan and never do, that’s a problem. And I think that if, to me, if everybody is present, like really emotionally present and really wants to do great things, great things will happen by people that are present doing things.

Roy: So then…

Derek: …I think planning kills energy, like, I mean that…

Clayton: …as far as a formalized process of planning?

Derek: Yeah, like, lets not do anything, lets just sit and complain…

Jim: …like ‘what are we going to do next?’ That’s what it’s all about. Instead of ‘what are we doing now?’

Derek: Right.

Clayton: If you look at the boot camp, the beginning of it, before people have any alignment whatsoever, and people aren’t really present, it’s all about planning like, ‘when are we going to do the next thing?’ and ‘when’s this going to happen?’ and all that stuff.

And then when the people become present, like Derek said they are kind of like emotionally in and invested in it, that I think that’s when the planning doesn’t feel important anymore. It just comes together…

Jade: …the facade falls away…

Clayton: ..yeah, like you don’t know how it happens, but it happens.

Roy: But you still need some kind of urgency, like, you need an urgency to achieve some goal. So, I feel like that’s a really light form of plan. Like, you have to be doing something. You can’t just put a group of people in a room together and say, ‘be great, whenever you get around to it’. [laughs]

Jim: …and whatever medium you choose, and, well sort of we are saying that in this thing, but…

Derek: …but we are giving them a timeline…

Jade: …right, they have been given a goal…

Jim: …given a goal by a boss and the boss hasn’t been relenting.

Derek: To me, that’s absence of an assignment. A team needs an assignment. I don’t necessarily know if they need a plan.

Clayton: I’ve seen plenty of plans without an assignment.

Roy: That’s true.

Jim: I’ve seen a lot more plans than achievements. There are tons more plans than achievements, right?

Clayton: Yep.

Jim: Michelle’s got this thing that usually annoys me, but she’s always right about it. If she wants to discuss that something that isn’t creative, it’s like, “Oh, I’m not going to talk about that user interface. Go do a user interface and then, we’ll look at it.”

But to talk about it as if it had merits of various sides of various arguments and treat it as if it were already done, she just refused to do it. It’s always good advice, so we have a fight.

Jade: Well, that’s real and you can fight over the…

Jim: It’s not what’s real, we can see the work. Opinions are like butt‑holes, everybody’s got one.

Jade: That is the ultimate expression though of having a highly iterative process, not an incremental process, but an iterative process where, “Let’s just create something. Get it out there. See if it actually does what we want it to do. Then, let’s talk about what it doesn’t do and let’s go make that happen.”

That’s where a lot of Agile teams get hung up is they focus on going through the motions of following that process instead of looking at the product that they’re creating. Ultimately, looking at themselves as the team being the ultimate product that’s been created.

Derek: I don’t know how many times we hear, “How can I measure that we’re doing Agile right?” It’s like, “Who cares if you’re doing Agile off, you’re not doing anything meaningful with it.”

Jade: Are you shipping? Are you delivering great products? Then, you’re doing it well.

[laughter]

Jim: Exactly.

Clayton: Someone asked me yesterday, they just got out of the experience of having this painful process of deciding something in this big group which planning is usually a bunch of people have to decide something and nobody ever wants to, competing interests and everything. They were asking me, “Why is it so hard?”

I asked them what it would be like if it were easy. The laughed and they’re like, “The easy answer is everybody trusts each other. People could just go do stuff and it would be OK with the group.”

I was like, “Yeah, that’s pretty good.”

[laughter]

Clayton: That’s how it goes. That is the easy answer, right? You can imagine if you had a planning meeting where the user interface thing comes up, rather than everybody arguing about what it should be, it’s, “Yeah, OK. We got that.”

Then, you go do it….

[crosstalk]

Jade: I like the idea of not discussing it until it’s been created.

Derek: Some of that is process starts to become more a crutch for bad behavior. I find myself more and more getting frustrated as people say, these clients tend to ask, “How do we know whether we’re doing Scrum well or doing Kanban well, or doing whatever it is? How do we know our process is working?”

I say, “I hate Agile,” because I hate process. In reality, Agile hates process, too. It actually says, “Individuals and interactions over processes and tools.”

How do we get to the point where everybody who’s “doing Agile” is arguing about process when we should be valuing individuals and the interactions of individuals over those processes and tools? One of the things I love about boot camp is that it melts all of that away and it just gets down to people.

Invariable, whoever the high‑performer in the room is, the first thing I want to do is throw all sorts of process on how to get these people productive. When, in reality, if they would just get down to getting to know the people and getting transparent and vulnerable with those people, they’d find that they’d get much better results and there would be absolutely no process to do.

How do you do that in an organization?

Jim: Like you said, it’s a very wise thing. You’ve got the sage of desert here.

Jade: He’s been called many things.

[laughter]

[crosstalk]

Clayton: Sage is a four letter word.

Jim: That’s my story on him and I’m going to stick to it because I like it.

Roy: In Arizona, they spell “sage” A‑S‑S.

[laughter]

Jim: Oh, is that what it means? In Arizona, they have a sage among them. I’ll stand next to him. He’s got a bright, red passionate love suit on and he’s very cherubic looking.

[laughter]

Jim: He smiles more than anyone, cackles a time or two. So, anyway, I’m getting all these people. Then, everything works out.

It is funny in boot camp, though, we try to make everything that’s stupid illegal in boot camp, because it’s happened before and it’s wrecked stuff. We go, “OK, that becomes against the law, that becomes against the law.”

All you’re left with is you, these other people, and the question in the beginning is, “What do you want?” That’s what they’ve been working on here for a couple of days. What’s so beautiful is they answer it, and they answer it more deeply. They start to smile, and their wrinkles actually go away, their stress has disappeared. It never fails to impress me how beautiful people are when they do try to be authentic.

Jade: They become humans.

Jim: Yes.

Jade: I think that’s what we’re missing so much in a lot of these organizations, at least the ones I’ve been working with. There are very few humans working there. There might be robots and reflex machines, but there’s really not a lot of actual, wonderful, beautiful people. They’re trapped in there somewhere.

Jim: I’ve noticed with you four ‑‑ I’ve been thinking about you four. This is a great team here, they really love each other. They’re always laughing. You can hear Jade’s laughter booming…

[laughter]

Jade: There is a laugh track.

Clayton: Check that out on video, yeah.

Jim: They’re always laughing, and it’s like, “Well, that’s it.” If you’re laughing you’re going to live forever, you know? Let’s at least believe that, what the hell.

[laughter]

Jim: Laughing, that’s what’s so great about my marriage. My wife loves to laugh. She laughs at my stupid jokes. Someone was just telling me that they really like listening to our podcast. He said, “I’m jealous ‑‑ Michelle thinks you’re the funniest thing.” I was like, “I know, I don’t blame you for being jealous!”

[laughter]

Jim: It’s just such a great thing to have to laugh. They’re starting to laugh a little more in there. You have to cry too. I said this morning, “It’s good to cry at work.” What a dumb thing to have to say. Of course, no‑one’s paying me very much to say it either.

One young woman who’s brand new to the workforce said, “Well, thank you for telling us that.” I told her afterwards that she was so encouraging, and that it was brave of her to encourage me on such a radical point.

Jade: Yeah.

Jim: It’s not radical, of course, that humans cry. I don’t know how I got into this [mumble] just present that’s what happened to me today that was impressive.

Clayton: Jade’s point of being human ‑‑ I think if you had a personal relationship with someone and they were telling you some issue, or explaining something about them, and they got emotional, started crying, all the things you’re not supposed to do at work. That’s an interaction that you have with that person as maybe a friend, a spouse or whatever.

You have this human‑on‑human connection, but then someone exhibits behavior like that at work where they act like they’re human. It’s like, “Whoa, this doesn’t follow the guidebook. I’m not supposed to have this interaction with this person. I’m not supposed to love them…”

Jade: “This is an HR problem.”

[laughter]

Clayton: Yeah, it’s an HR problem…

[crosstalk]

Roy: At the very least, I’m uncomfortable because now I feel like I have to reciprocate and I’m not comfortable doing that.

Clayton: That’s part of it, yeah.

Derek: I was working with a client. One of the topics that came up in one of their ‑‑ they do lean coffee on a regular basis ‑‑ is, “How do you foster relationships?” It’s against the HR policy to friend somebody on Facebook who is your direct report. You’re not allowed to be emotionally connected to people who report to you. How does that work?

[crosstalk]

Derek: How do you get results…

Jade: …Ask him, “How’s that working for you?”

Jim: I’m going to take a wild guess that it’s not working very well. It might be, but there’s a lot of surreptitious Facebook friends. It’s like when it’s not legal to make love with people you work with. OK…Then a lot of [inaudible 14:24] takes place.

[laughter]

Jim: Any time you try and outlaw basic human qualities, you just create lawbreakers.

Derek: Maybe they’re just trying to ingeniously promote that behavior?

[laughter]

Derek: They’re trusting in the rebellious attitude of their employees.

[crosstalk]

Jim: …That’s what the boss says, then that might work. It seems like a long way to go.

Jade: Our question was, “How do we do this in organizations?”

Jim: Yes, that was the question you asked.

Jade: We have to be organized very differently. The organizations still.

Jim: We have to be committed, personally, to loving our neighbors and ourselves. That’s enough. We don’t really need a degree or a different boss. It’s true that some people might come down on you, and you have to be willing to move on. Your own love and life is more important than a particular job.

The example we have before us today is the guy that brought these people to this boot camp. Took a big risk. I had a boss, he’d say, ” [inaudible 15:38] you’re acting like a one‑armed paper hanger!”

[laughter]

Jim: That’s what ‑‑ boom, he’s working his ass off trying to keep it all going, taking a big risk. He cares. I did say to him and his wife both ‑‑ he brought his wife and his child, which is very telling. He’s just a very admirable guy. If you’re in a position of authority and you want to have a great team, you have to do the sorts of things he’s doing for his team. He’s discharging his responsibility as an adult [inaudible 16:15] in their behalf.

Roy: What good is having a lot of responsibility if you never use it?

Jim: That’s my point. That’s the guys that’s sitting around trying to control people.

Derek: Now that you’ve opened up that door, one of the interesting things to me about this boot camp is that several wives attended.

Jim: Yes.

Derek: It was interesting. At the end of the first day, I challenged the other interim guys. I said, “I suspect we’re going to lose a wife between today and tomorrow.”

Jim: Not permanently?

Clayton: [laughs] No. That they wouldn’t come back.

Derek: One or more won’t come back, this is probably too awkward for them. We ended up gaining a wife ‑‑ a spouse ended up showing up that wasn’t there during the first day, and we didn’t lose any.

Why is it that as a world, we try so damn hard to separate work from who we are? Why do we insist on being prostitutes to our work? What dynamic is at play that we just can’t, for whatever reason, allow ourselves to integrate who we are with what we do?

Jim: Possibly it’s our heritage of slavery. Work was something you wanted to spare your loved ones, because basically you’re checking in to be a wage slave at best.

Jade: I think some of it is the shackles of modernism. That’s how it’s supposed to work, things are supposed to be very clean, sanitary, separate and compartmentalized. It’s not actually how we work best as humans. We’re very messy and sloppy, and things are all over the place.

Roy: And things are fun. We have heard so many times, “Hey, you guys are having too much fun. You can’t be working hard.” Or, “You can’t be doing good work, because you’re having too much fun. You need to stop that. Work is a place for work, not a place for fun.”

Jade: Like Jim said, my laughter tends to permeate the building. It causes trouble.

Clayton: A lot of people just hate their jobs. They have crappy jobs they don’t like, but they’re too afraid to get out of them.

Jade: That’s because they don’t like themselves.

Roy: They think they’re supposed to hate their jobs.

Clayton: Yeah, they think they have to do this rat race thing and all that stuff, but if I hated my job, you bet your ass I would not ever want to think or talk about it. I would totally separate those two things.

Jade: I think that the modern story is that you do hate your job and you hate your boss. You hate all these things. If you went around telling people that you loved your boss, which I encourage you to do…

[laughter]

Jim: In this place, yeah. I love my boss…

[crosstalk]

Jade: People would think you’re insane, right? They wouldn’t want to relate to you.

Roy: I’ve got friends that get upset at me when I talk about the fact that I love my job. They get mad at me like it’s my fault that I enjoy what I do.

Jim: It is your responsibility. You have created it.

[crosstalk]

Jade: You’re breaking the system.

Roy: That’s true, but I’m not ‑‑ like I’m slighting them, I guess, which is not what I’m doing.

Jim: Derek, I think you and I were in a workshop somewhere in an open space. We went to this thing. We just barely knew each other. The thing was the work‑life balance. It made me so mad to even hear that phrase that I went in there to attack it. Before I could, the sage…

[laughter]

Jim: …of the desert spoke up and said, “I don’t think there even should be such an idea as work‑life balance.” I went, “You got that right.” We just really got into it.

[laughter]

Jim: Everybody in the room was afraid to go talk and brag about how they achieved this balance, which, by the way, I’ve asked thousands of people if they’ve ever lived the work‑life balance.

Jade: What does that even mean?

Roy: That means you do as little work as possible.

Jim: It means that you must have civil war between your job and your home.

Jade: Yeah. It’s like oil and water.

Jim: Work‑life balance. Good grief.

Jade: Work‑life integration, right?

Jim: That’s exactly right. That’s my only solution I’ve ever been able to come up with, is you integrate your work.

Derek: I look at it, if you’re not doing your life’s work, stop whatever you’re doing and start doing your life’s work. What it means is, I’m punching a clock that has no meaning to my life at all. I’m simply showing up.

Jim: But I have a mortgage.

Derek: I think we said of the business, you’re no different than a prostitute. “I am only doing this transaction for money.”

Jade: Some of them like their work. [laughs]

Derek: There is no love. But that might be their life’s work.

Jim: That’s different.

Derek: I’m not degrading prostitutes here. I’m just saying…

[laughter and crosstalk]

Jim: My life’s work is my sexuality.

Derek: If I go to work every single day and I’m miserable and feel like I’m just being taken advantage of, but I’m willing to do that because there’s some paycheck on the end of it, I don’t see how that’s any…to me, is indistinguishable from prostitution or whatever you call it. I’m selling myself for…

Jim: It’s a type of slavery, is the way I look at it.

Derek: Yeah, slavery, prostitution, you name it.

Jim: It’s voluntary slavery similar.

Derek: If you get to a point where I’m doing meaningful work, wouldn’t you want everybody that’s close to you to be part of that work?

If I’m doing my life’s work and I’m doing something that’s meaningful to me, by de facto standard, wouldn’t I want all of the people that I love to partake in me? If I can’t separate me from the work that I’m doing, and if I want to give me to the people I love, by default, am I not including them in the work that I’m doing?

Jade: I think that’s a great point. I get asked a lot about that, about the things that I do with Gangplank and giving so much away and doing all this stuff. “Oh, how selfless.” I say, “No, no, no, no, you don’t understand. This is the most selfish thing I can do, because this is all about making the world better for me.”

Jim: It’s self‑indulgent at its core.

Jade: Yeah, which I think has the greatest benefit. It benefits other people, as well, but, really, it’s about making the world better for myself.

Jim: If it didn’t, you’d still do it, right?

Jade: Yeah.

Jim: It’s just coincidental that we’re pursuing virtue in this BootCamp. It’s just a happy ‑‑ very happy ‑‑ coincidence that virtue tends to pay off. If [inaudible 22:23] were necessary, I’m sorry to say, I’d be recommending it [laughs] because the fundamental unit is to make your life effective, to make it achieve what you want to achieve in the time you’re willing to spend on it.

That is, as you say, Jade…The only problem I have with the idea of life’s work is, it’s too hard for young people to have that…”I don’t know what my life’s work is.” I got my 18‑year‑old saying that. I’m like, [laughs] “I really didn’t expect you to at this…”

Jade: [laughs] “You still got plenty of time to figure that out.”

Jim: I said, “How about if you pursue what you want, and that’ll probably…If you’re human, you’ll end up making that so noble that you get to keep doing it forever.”

Derek: You have been but [inaudible 23:08] we encourage, if somebody’s 17, 18, whatever age they are, and they don’t know what they want, we can start by saying, “If you don’t know what your life’s work is, you should get to work understanding what your life’s work is, whatever that is.”

Jim: Yeah, or just pursue what you want, and trust that that will work out.

Derek: Yeah, that’s what it means.

Jim: Right, same difference.

Derek: If you have something you want, you start there, and maybe that uncovers other things that you really want. But if you don’t start ‑‑ it’s like planning, like, “I want to plan the perfect career for me.” [mumbles] I don’t know. Why don’t you…?

Jade: Good luck with that.

Derek: Why don’t you start doing what you want to do? You might find out that that’s not what you want to do, and you…

[crosstalk]

Jim: Right. Typically, you’ll find that you spent too much money and the whole decade of your 20s, typically, on something that someone else told you would make you secure.

Jade: That sounds just like product development.

Jim: Personal development?

Jade: No, product. We indulge in these things. We get these great budgets. We put together these wonderful plans on this thing that we think that we want. Then, we actually build it and realize that it’s not the thing that we want.

[crosstalk]

Roy: Or that other…

Jade: Where, if we actually pursued what we truly wanted, we would build a really great product that we would be proud of, that our teams would be excited about, that everybody would be invested in making successful.

Jim: You might even be disappointed in the first few rounds.

[crosstalk]

Jade: Of course, but, ultimately, if I continue to pursue that…

Jim: “Wait a minute. I thought of this beautiful thing, and this turd came out.” It’s hard, but if you just do it, you’re so much better off.

I spent a bunch of time pursuing poetry and fiction writing. Then, when I saw a computer, I learned what writing was, for me. It was like, “Oh, yeah, baby. Yeah, baby.” You pursue shadow things, maybe, at first, a little, when you’re a kid. Plus, it’s a list of things to choose from that’s pre‑ordained. Didn’t have any idea of a personal computer.

Derek: I think my advice to young people is explore. Get out there and taste things, because whatever the current list is, is not what’s really available. In the end, you can…

Jim: That’s the old people’s version.

Derek: You can do great things that people don’t even know about yet. Once you get a taste of that, that’s where the good stuff is, is creating the stuff that nobody’s ever seen. But the only way you’re going to do that is to be exposed to a lot of different stuff, so you can have new ideas to create from.

Jim: Find the stuff that you can’t avoid doing, that you just must do, regardless, and then increasingly make more and more room in your life for that. It was funny. About a year ago, I asked Michele, “Michele, is there something that you just do, that when you do it, you’re totally happy?” She says, “Oh, yeah, when I play tennis.” I go, “OK, how about tripling the amount of time you spend playing tennis?” She did, and she’s much happier.

It seems like, again, a dumb thing to say. “If there’s something that you do that you love, do it more.”

[laughter]

Clayton: “The easy answer is to play more tennis.”

Jade: “Imagine that.”

Clayton: “Good idea.”

[laughter]

Jim: I heard you in your talk, Jade, that great talk ‑‑ everybody needs to go listen to Jade’s talk at Livermore x.

Jade: TEDxLivermore?

Jim: TEDx conference. You said that your grandfather gave you the money to build a computer. Wow.

[crosstalk]

Jade: Not only that, he took me down and did it with me.

Jim: That was a good thousand bucks, wasn’t it?

Jade: Yeah.

Jim: Did he ever spend ‑‑ did anybody ever spend anything better than to give Jade Meskill a thousand bucks to build a computer? Gave him his life.

Jade: Even more so, he gave me his time to do it.

Jim: He did it with you?

Jade: Yeah, we did it together. It wasn’t just a check. He took me down and we bought the stuff. We built it together.

[crosstalk]

Jade: Not only that, he told me he learned things that he didn’t know he knew.

Jim: I would guess so. That’s the deal. They’re little learning machines. That’s why we love them so. That was so cool. Do something like that for your kids or friends or whatever. One little gift like that makes all the difference if it’s the thing they love.

Jade: I ran into somebody the other day at Gangplank. They were doing some stuff and they said, “I just can’t believe that a place like this exists. I would’ve never been able to do…” this thing that they were doing “…without having it.”

[crosstalk]

Jade: I was like, “That’s amazing.”

Jim: Right. That is amazing.

Jade: And so easy, so simple.

Jim: If you’re struggling at work, you’re on the wrong path.

Derek: Don’t stay in pain.

Jade: I think that really comes down to what we’re talking about. If you’re fully present, then why are you…?

Jim: We’re having fun. The guitars aren’t out yet, but when they come out, things get even better. We got a couple of guitar players, and I’m going to learn to dance. So there, Michele.

[laughter and crosstalk]

Jim: I’m on it. I’m on it. That was my new alignment. That’s the evidence to my new alignment.

Derek: We can challenge his integrity now, Michele. We’ll help you do that.

Jim: That’s right. The Hippocratic Oath will take it from here.

Clayton: With that, we’re going to go to Jim’s dancing lessons. Thanks for listening. Thanks, Jim.

Jim: Thank you for having me.

Jade Meskill: Hello, welcome to another episode of the Agile Weekly Podcast. I’m Jade Meskill.

Derek Neighbors: I’m Derek Neighbors.

Roy VanDeWater: And I’m Roy VanDeWater.

Jade: We wanted to talk about a pattern that we’ve noticed lately of [talking very slowly] people who like to slow things down. That’s for you listeners listening at two speed. We’ve seen on different teams, different companies, different environments that people have this fear of taking action.

What are some of the ways that you guys have seen people slow down the process of moving forward, of moving to something new?

Derek: I see a lot of discussion, so when I’m afraid of something, I think we’d call that slowly slowing something down until I’m comfortable. “Hey, you guys are all going way fast. I’m not comfortable. Let’s slow it down.”

“Hey, can we talk about what’s the best way that we can solve this problem”? Or, “I’m not so comfortable. We haven’t talked to Roy about it and I think we really need to have Roy involved in this conversation.”

Or, “I don’t think the boss is going to be OK with that. I think we need to set up a meeting and figure out if we would even be allowed to do something like that before we can really make a decision.”

Sometimes it will revolve around a decision, but a lot of times, I see it just around action. We should be doing something, we should be moving something forward, but instead we’re going to talk about it.

“Let’s talk a lot about what the new product should have in it. Let’s talk about what the product should be like. Let’s talk about who should be on the team.” Instead of doing things to move some step closer to doing something.

Roy: Why don’t people just do things?

Derek: Because I think you have to then own the result.

Jade: How does that affect an Agile team? So if you have a team that is trying to become Agile, be more Agile, what side effect does this have on them?

Roy: I think Jim McCarthy talked about it in terms of, “You are slowing things down to the lowest common denominator,” or, Derek, you’ve put it this way too, where you are slowing things down to the comfort level of the least comfortable developer.

Jade: What does that do?

Derek: It frustrates people who want to go faster, but what it really does is it retards people’s ability to have cycles of doing, failing, correcting. Doing, failing, correcting. Doing, failing, correcting.

If it takes me a long time to have action ‑‑ there’s a whole bunch of frustration and buildup and everything that goes along with that ‑‑ and then when we actually do something and we don’t get the exact result we want or it’s not quite right, we have to go back and we have another long process.

Two things happen ‑‑ we expend an enormous amount of energy, which is really, really valuable, and time which is the also really, really, valuable.

We also slow down our ability to learn and correct. If we choose an action and it’s not the right action but we learn something from it, that’s probably quicker than if we debated 10 different…

If we debated three different ways to do something for 15 minutes and it only takes three minutes to do each one of those things, we could be done and know for certain which one is the right one quicker than if we sat and talked about which one might theoretically be the right one.

Roy: It’s also frustrating as a developer. All of a sudden you’re demoted from having new ideas. It’s now become a bad thing to have new ideas and a new way of doing things. Anything that you suggest is going to start another chain of endless discussions. You’ll get into the mindset of, “I better keep this to myself, because I don’t want to talk about it”.

Derek: I think there are studies out there that really show that. We get so afraid of putting out a wrong answer ‑‑ it is so bad to do that we stop putting out the scary ideas, and the scary ideas are usually the ones that have the best results.

I think when you start to train yourself, “I’m really afraid of throwing this out there, doing it or trying it,” you debate it and you debate it and you debate it. You’ll debate 20 really awesome things that will set you all the way forward in taking the worst idea.

I see this all the time when we do the ballpoint games. If you look that up, invariably, I’ll see somebody who would throw out an awesome idea that would probably quadruple to 10 times the team’s productivity in this particular game. They usually laugh and step back and be like, “Ha, ha, just kidding”.

In reality, if they would go forward with that idea, the team would be way more effective. I think when people slow things down, it gives them more doubt and more time to second guess and to criticize their own thoughts and actions. It breeds more inactivity ‑‑ it literally becomes an energy sink.

Jade: So what happens to those people that were saying they want to slow things down to their most comfortable level? How do you deal with those?

Roy: First off, do those people actually ever get comfortable? Is there any amount of discussion that actually ever gets those people at the comfort level they want to be.

Jade: Sure, if nothing happens, right?

[crosstalk]

Jade: If I could use it as a weapon to stop things from changing…

Roy: The only way to effectively give the person the value that they are looking for is to continue the discussion and definitely never do anything. That sounds like we could just skip to discussion and not do anything.

Jade: [laughs]

Derek: They think a lot of times those people would prefer that. I don’t think they’re in love with the discussion. I think they’re in love with the idea of [laughs] “Well, let’s make myself comfortable with this.”

Roy: If they don’t want to do it, why don’t we just give them the power to say, “I don’t want to do this”?

Jade: How do you do that though? You have a team of people who are trying to work together.

Roy: In the past we talked about using the decider protocol ‑‑ it requires unanimous vote, so if one person’s out, then it doesn’t go through ‑‑ so everybody has the power to say no. Every person is going to get listened to ‑‑ not listened to in the “talk‑forever” sense ‑‑ but listened to in the “have‑their‑way” sense.

Derek: I think it comes down to a couple of things. Certainly if you’re using the core protocols, there’s a lot built‑in that allows you to do that, but if you’re not, you can still handle it in one or two ways. One is we refuse to not do anything, so we’re going to do the best idea that we currently have, and if you have a better idea, awesome, let’s hear it, but just slowing down to discuss is not going to be allowed.

You can say, when we’re in a discussion point, it becomes, “Hey, I think we should do XYZ.” If multiple people are, “Yes, let’s do XYZ,” and somebody continues to, “Well, I want to slow down,” part of me says…at that point, do you just check out and say, “I’m going to go spend my time doing something else”? Or do you say, “I’m going to do X”? “I’m no longer going to wait for you. It’s taking too long. I’m going to suffer whatever consequence comes from just taking action ‑‑ that inaction is too much of a penalty already. I would rather suffer some other retribution for taking action than suffer the penalty in the problems with taking no action.”

Roy: I think there’s a culture component to this as well ‑‑ if you have a culture in which everybody needs to be comfortable, you’re going to have problems in terms of going fast because as we often say, “If you’re not uncomfortable, you’re not going fast enough.” So creating a culture where it’s OK to be uncomfortable starts promoting that type of thought.

If you have a culture of uncomfortableness, that’s probably going to be very tightly linked to a culture of “No Criticism”, and a culture of dishonesty. If we’re a culture that’s all about you being comfortable, Jade, then I can never criticize anything you do because I’m going to be making you uncomfortable.

Jade: Which is true.

Roy: Right, exactly.

Derek: [laughs] I think you’re touching on something really interesting. There’s something behind the motivation to slow things down. It’s not that people are completely unreasonable, or just not decent human beings. They’re afraid of something. Have you ever worked with someone to help understand what it is that is behind their need to slow things down and help them overcome that?

Derek: Yes, I see a couple of patterns. One is lack of confidence, so…

Jade: Self‑confidence?

Derek: Yes. “I don’t trust that I’m capable of doing this, whatever this is, so I don’t want to take the action until I’ve got complete assurance from other people that it’s safe for me to take this action,” ‑‑ there’s a lot of validation that needs to happen.

We need to go lift 50 pound block, but I don’t think I can lift the 50 pound block, so I want to discuss it, not necessarily because I think I want to slow it down, but I want you guys to pump me up to the point where you make me believe I can actually do it. When we get to that point, then, yes, I’m full‑on willing to go do it.

Another one that I see is ‑‑ like a flip‑side of that ‑‑ “I don’t feel comfortable admitting that I have a lack of confidence.” On one the discussion is “I’m really nervous about this, and I want to go over this again, and I want to understand,” so somebody is like, “Will you help me understand? Will you help me understand? Will you help me understand?” What they’re wanting is that self…

Jade: Affirmation.

Derek: Right, affirmation, and then I think there’s the flip‑side where, “I don’t know how to do it, but I don’t want to tell you I don’t know how to do it,” so what I really want to do is I want to debate this thing to death, because the thing you are asking me to do, I have no clue, but I know how to do this other thing over here, and even though I know it might not be the right thing, I’m going to argue to death that it’s the right thing because if we do the thing you want, then I have to admit I have no clue how to do that.

Roy: Another variant is lack of trust that the other people know what they’re doing. Argue it to death so that instead of having a high level discussion about it and agreeing this is where we’re going to move forward and trusting that Derek is going to do it right, we argue about it endlessly and insist on ironing out all of the details, so that I can have full control over making sure that Derek does it the right way, because I don’t trust him to do it.

Derek: There’s that control component there too ‑‑ fear that people won’t do it how I want it done. I’ll debate it to death just because I want to make sure that this stupid you gets every single detail right.

I can’t agree to take action that I’m not going to personally do until I know that you’ve affirmed every single decision that can possibly be made about that action.

Roy: Which is interesting because I’ve definitely worked on teams where I did not trust the other people to make good decisions. It was for good reason because they made stupid decisions all the frigging time.

[laughter]

How do you deal with that? I guess that’s part of the culture of honesty ‑‑ you need to be able to say, “Hey listen, you make stupid frigging decisions, so let’s talk about this.”

[laughter]

Derek: It’s bringing the better idea to the table, right? If everybody has to do the work, maybe it’s, “Hey, that sounds great. Let’s pair on it.” Or, “Hey, that’s great, but why don’t we check in every hour and make sure that we’re going down the right path”?

There are a lot of ways to deal with very real problems, without necessarily having to slow down forward movement.

Roy: Part of it though is that nobody actually wants to talk about the fact that they don’t trust the other people. Nobody says, “I am afraid that you aren’t going to implement it the way I want to see it done.”

Jade: If you had a high trust environment, you probably wouldn’t be having this problem.

Roy: Yes.

[laughter]

Derek: Another thing that seems to happen is, just like people are not good at breaking down requirements or stories, or you name it, people are not good about breaking down decisions. A lot of times, it’s like we’re trying to negotiate every single detail in this really big thing before we take one step forward.

Instead, if we said, “Can we all agree that we want to go east? Yeah, we all agree, we want to go east. OK, let’s start walking east and as we are walking east, let’s make a decision about how far we’re going to walk,” or whatever, right?

A lot of times, that’s another delay tactic, “I don’t want to start moving because what if we start going east and in another two hours, we decide we need to go north? We could have gone diagonally and gone a lot faster, so I don’t want to move from this seat until I know exactly where I’m going.”

Roy: Just assuming from the principle that for the most part, your gut feels that sometimes you may be wrong and that you will suffer by having to walk back in the opposite direction to get back to where you started to then start heading north. Usually, when everybody agrees, “Let’s go east,” you’re probably going to end up going east.

Derek: You can slice it down into decisions that are small enough to say you can find that baseline, “Where is the real fear at”? Is the fear in moving altogether or is the fear in going east? What is it?

If we can get agreement of 75 percent on the stuff, that allows us to get moving while we figure out the other 25 percent. If you’re trying to schedule something with somebody with tight schedules and neither one of us could hook up, this week I just said, “Can you come out between this date and this date”?

No details. No, “This is what we’re going to do. This is what we’re not going to do,” just, “Can you make it out during this time? Yes or no, that would really help me.”

The person was able to say, “I have no idea what I’m committing to, but I can commit. I will be available sometime within that week. Can we please talk in the next day or two to determine what those details are”? [laughs]

That allowed the conversation to move forward, but didn’t require all of the details.

Jade: Let’s wrap it up here. We’ve got about a minute left. What’s our advice to people who are stuck in this challenging situation?

Roy: Go faster.

Derek: Anytime you start to feel frustrated with the speed that’s something moving, it’s a good sign that you should demand the action or decision be made.

Jade: You need a tool or some ability to make quick decisions and take action.

Roy: If the team or people are insisting on not being able to make decisions, get from them, very concretely, what it would take in order for them to be able to get to a place where they’re making a decision. If you can’t get that, that’s a huge problem.

Check out, probably, at that point. Just leave. Go do something useful because you’re wasting your time.

This person’s telling you, “I’m not comfortable. I don’t know what it will take to get me to be comfortable,” so talking to him isn’t going to help.

Derek: That’s exactly it, right? It really is. If you get to that point where you’re frustrated because stuff is not moving, say, “We need to get this moving. Here’s what I think we should do. Can we get consensus”?

If there’s no way to get consensus, you’re better off going and doing something else.

Roy: Avoiding the temptation of large groups and just have management go in and say, “We can’t come to a decision. I’m going to go do this. Anybody is welcome to join me.”

Derek: Or, “I’m going to go do something else that needs to be done that’s not related to this and when you guys get to the point where you know what the hell you want to do, let me know. But I’m not going to sit here and spend more and more time trying to get you comfortable.”

Jade: Great. Thanks for listening to the Agile Weekly Podcast. Check us out on Facebook at facebook.com/agileweekly. We’d love to hear from you guys. Thanks for listening.

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

David Foster: I’m David Foster.

Roy vandeWater: I’m Roy vandeWater.

Clayton: Today we’re talking about having fun at work.

Roy: What’s that?

Clayton: Maybe people listening might not know what having fun at work is.

David: Yeah I think that’s fair.

Clayton: Are you working if you’re having fun at work? I feel like you can’t really do a good job of working if you’re not having fun at work.

Roy: [laughs] I definitely feel like there is so much existing baggage in the world like I have heard so many people saying, “you’re having too much fun,” or “I’m hearing you guys having fun, get back to work,” or “you guys couldn’t possibly be working because I can hear you having fun.”

Clayton: Yeah. That’s because a lot of times fun at work is conflated with goofing off. I have personally experienced a lot of times where I have been being very productive and getting a lot of stuff done. There’s been lots of laughter, joking and having a good time all around. Stuff that if you were overhearing the team room, you would assume that nothing’s happening which is very different. I also have seen a lot of times, plain old goofing off.

The important part is that the goofing off time has to be very transparent, so that there isn’t the temptation to assume that people are always goofing off. One way this was solved when we were working out of Gangplank with the “Street Fighter” and “Blitz” machines, which was a lot of fun ‑‑ Video games at work. They were in a totally separate area of the work space. When people decided to stop working and they wanted to go have fun, specifically have fun playing video games.

It was very clear that they got up from their pairing station and they walked over and they played. If someone was maybe doing that too much, you would notice that they were missing from the team space and they were in the fun space. You could make that distinction, it was very clear. If it was a situation where people were…their version of fun was watching YouTube videos, which I’ve seen something like that or browsing Imager.

Those are the things that are a lot harder to do because then it’s hard to tell when someone’s working and when they’re not working like when they’re goofing off. That’s more detrimental to the “having fun at work” movement than anything.

David: Are you suggesting that the fun needs to be something that is going to be done in a team way? Or that fun, as a team would be the best way of doing that?

Roy: I don’t know if I agree with that, I feel like the YouTube and Imager stuff that you are talking about, basically everybody knows anyway. Maybe it’s harder to have the confrontation with somebody, because you can’t point and be like, “Hey, I saw you over there in the corner the entire time you worked out your machine.” But everybody knows. That’s really just the team not being brave and bringing it up to people who are abusing that type of fun.

Clayton: But I have seen those people, when someone brings it up and makes a joke about like “Well you know, some people watch YouTube all day.” I’ve seen those people say, “That’s not true, I don’t watch YouTube all day.”

Roy: First off, don’t be passive aggressive and second bring it up

[crosstalk]

Clayton: Yeah, but I am saying when you don’t have that clear separation and there is not transparency, it’s so easy to just defend yourself and say that’s not true, it’s a he said, she said thing at that point.

Roy: Yeah, but it does not matter, you’re not trying to justify to management like you are not ratting this person out. Your saying, “Hey, I notice this behavior in you, I have a problem with it whether or not you perceive it to be a problem is separate. This is my reality, I realize you have a different reality, let’s reconcile this.

Clayton: That conflict is where the “Don’t have fun at work” stuff comes from. People that we’ve seen that say, “Don’t have fun at work,” or “you are having too much fun at work,” or ” All we do over here is goof off,” is when they have their back turned and they hear the laughing maybe that is joking around while you are doing work and maybe the laughing is you just watching YouTube videos and they can’t tell the difference, so the easy answer, the legalistic answer, is no fun at work any laughing is bad.

Roy: OK, yeah I think that is an issue to avoid.

David: If you are in a culture working in a company that has a culture that is like that, that doesn’t actually understand the value of being able to have fun at work, rather they think that work should be toil. Have you seen anything that a group can do to be able to introduce that in such a culture? Or do they have to be brave enough to be able to go ahead and do it?

Roy: If a team has earned trust by delivering on the stuff that they promised regularly, it’s going to be really difficult for the organization to criticize why they’re having fun at work.

If you have that trust you can say, “Hey, I know you are having a problem with me having fun, but I delivered when other teams didn’t.”

Clayton: Would that be a prerequisite then, that if a team understands that then first they might want to be thinking about how can they make it so that they are accountable or can be held accountable for the work that they are doing, demonstrate, “Yes, we can actually do this” and then be able to start changing the culture that way.

Because I think there’s a weird trend basically where there’s probably some things that would start out in the beginning. They would be having fun, and it would hurt them. They would maybe go slower, or people would spend too much time doing “fun things.” That would be detrimental to the team in your organization. Then I think as teams maybe mature they get to a point where they can’t go.

The only way they can be as fast as they are is if they are having fun and they are enjoying what they’re doing in that regard. There’s definitely maybe the dip I guess where there’s some period where you’re probably going to see diminished output. If you’re measuring output, which a lot of people do, then that’s an easy way to say, “OK. It was fine that you guys had Nerf guns for a while, but you failed three sprints. So no more Nerf guns.”

That might not have anything to do with it, but that’s such an easy target that people can jump into.

David: Yeah. [laughs]

Clayton: One thing that actually we’ve been doing for quite a while is at the end of the day we’ll have a card game when we play just some various card games. It’s a good way for us to have fun at work.

What we’ve noticed is that there’s been a lot of really good conversations that have happened in this context because it’s so still very work‑related, and things that we would talk about during the work day ‑‑ It just so happens that maybe they come up at this time. I don’t know if it’s the relaxed environment or whatever it is, but there’s something about that time that makes a big difference.

Do you guys agree?

Roy: Yeah, I agree. It’s like the informality of it makes it a safe environment to bring stuff up you wouldn’t otherwise feel comfortable bringing up. I’ve noticed a lot of conversations happening there that I was surprised even came up.

David: I think part of it is just because it is at the end of the day, and because of the nature of the cards, you’re playing games so you’re naturally unwinding anyway. That lends itself to being able to being more comfortable to be able to have those kinds of conversations where maybe during the course of the day when you’re busy getting other things, usually you’re involved in meetings, and you have a certain set of tasks to do.

But at the end of the day lends itself to that along with the card game. But I agree, I think that has been a very healthy activity to do.

Roy: Yeah, but if somebody were to walk past and see you playing cards, they’d be pissed, especially if it was your boss or some. That’s part of the problem. You can’t outwardly tell that this is actually a very productive time of day.

In fact, there have been days where the most value I provided and the most value I received was during the half hour or 15 minutes or whatever of playing cards at the end. But any observer that is unaware of that would just think I was goofing off during that time and playing a game.

Clayton: I’ve always laughed when I’ve heard managers, and managers say this because they want to try and sound cool or they want to be your buddy. They say things like, “Hey, I don’t care what you guys do as long as you get the work done.” I’ve heard people say that.

I always think, “OK, I’m going to bring a TV in. I’m going to wheel a TV in. I’m going to have ESPN on all day long. I’m going to get a Lazy Boy, and I’m going to kick that up in the middle of the aisle. Every 30 minutes I’m going to blow my vuvuzela on the floor, as long as I get my work done.”

Roy: Man, we actually did that in here at one point.

Clayton: Right. Nobody actually believes that. No one does that. That’s the exact same person that if you started playing cards, they’d be like, “Oh, playing cards? Oh, just goofing off, OK.” I think management generally speaking does a really bad job of understanding how fun fits into a team and then staying out of the fun. The fun aspect is very important for the team if the team values that.

I guess there are some teams I’ve seen that don’t really value having fun. But if the team does and that’s something they can be responsible about and they can be accountable to it and they can be transparent about it, I think that’s a fantastic thing.

Roy: But “staying out of it” is maybe the wrong term. Maybe it’s being passive aggressively discouraging it because I think a manager that participates in it and helps promote it can actually be a good thing.

Clayton: Sure, yeah. If the team has certain values, then the manager can play into those or can adopt some of those things or be sympathetic maybe. That probably does go a long way. You look perplexed, David. What are you thinking?

David: I’m not perplexed. I’m in a position where I do believe that I understand the importance of fun, especially with teams that I’m expecting to be creative and innovative in some of their solutions. I don’t think you can actually do those kinds of activities without being able to have fun. At least that’s not been my experience. But I may be in a culture where that is not seen as the way that you get work done.

I’m trying to think how would somebody in that position, in a management role perhaps, introduce that concept to a team that has never been exposed to that, in a way that can be seen as productive.

I’m thinking of some of the teams that I work with. What would happen with that team if I came in a started encouraging them to actually have fun in some way?

It would be a positive thing, but I’m trying to think through what the ramifications of that would be for a team that has never had that, or been allowed to do that.

Clayton: Yes, it would be tough. That’s why you see a lot of companies that take the approach of “Oh, we have developers, and so in order to be a cool place to work, we’re going to put a ping pong table. Because that’s what they do in Silicon Valley, right”?

That’s the joke you always hear. I think that’s exactly the kind of scenario. If you took your average corporate development team, and you gave them that sort of thing, I don’t think it would make sense. This feels like a trap maybe.

So you have to start really small. I worked with a team that was kind of in that boat of thinking work was just toil. They didn’t like it. But for their Scrum board, I glued Monopoly pieces on to pins and that was this little hint of fun, like “Oh, this is a little different. I like the dog, I want to be the car.” Whatever. That was probably the foot in the door to exploring having fun while you’re doing your work.

So I think you have to start really small like that. Going out and buying a whole bunch of Nerf guns and the Nerf basketball hoop and setting that up in the tea room is probably overkill at the beginning.

Roy: And it doesn’t really help. I think that’s part of trying to add a punch of perks, to use perks to create a culture. The problem is that the culture isn’t the perks. But if your team has a strong culture, the teams end up creating those perks for themselves.

They might find fun in Nerf guns or whatever and bring them in themselves. And then they are self‑aware enough to realize, one, that it isn’t decreasing their productivity, probably even helping. And two, that they have the authority to do it because they’ve built up the trust with the people that they work with.

Clayton: I can definitely see that happening. The thought I was having, or was trying to formulate was, would this actually be a catalyst towards maybe getting a paradigm shift to occur within a team that has been so mired in a culture that is the opposite of that?

Is this something that can be seen as a catalyst? Perhaps not. Perhaps it is something that has to happen naturally with a high‑performing team once they get to a certain level. But I am wondering though, if maybe this is one those things.

Because it’s so different from what many of the people, especially in the enterprise world, are used to. Maybe the introduction of something like this might be enough to completely knock them out of their comfort zone? I don’t know.

Roy: It’s an interesting idea, because I’ve always thought of a high‑performing team generally has fun. So fun is a byproduct of a high‑performing team. I’ve never really thought of the idea of using fun, to take a team, to have them become high performing.

It feels a little off to me. I think that’s going to be very difficult to make that work.

Clayton: I think there’s something about…I remember back in school, you might be sitting in the classroom and the teacher’s trying teach you something, some lesson or whatever. And that feels like school and you’re in a class room and it’s the same thing.

But then when you go on the field trip and you basically are learning the same thing. But it’s this entirely different environment, it all of a sudden seems so cool. So I wonder sometimes, with teams who maybe are trying to explore fun or learn how to have fun.

Like if it’s OK, to test their boundaries, if maybe getting outside of the normal work space is a good idea. Is it a matter of “Hey, let’s go work from a coffee shop for the day”? Or whatever the case may be.

Something like that to get outside that zone, so that it feels a little bit different. To break the idea that everything about work relates to the stale corporate environment.

David: Yes, I agree with that.

Clayton: Alright, I think we’re about out of time so thanks for listening.

Roy: Bye bye.

David: Bye.