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.

Agile Process Frameworks vs Individuals and Interactions

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.

Agile Process Frameworks as Guide Rails for Novices Only? (Dreyfus Model)

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.

Dumping Frameworks on Teams. More Helpful or Harmful?

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.”

Where It Goes Wrong? Measuring Agility by Process Adoption vs 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.

The Journey of Adoption vs The Destination of Framework Adoption

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.

If You Don’t Think You Suck, You’re Probably Already Dead

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.

Prescriptive Agile Coaching Trying a New Approach

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.

If You Tolerate It, You Insist On It

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.

Autonomy is Largely a Matter of Perception

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.

What Happens If We Just Pretend

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]

Vanilla Prescription Goes a Long Way For Most Teams

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]

Focus on Results While Demanding Excellence and Continuous Improvement

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?

The Power of Core Protocols Ask for Help and Decider

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?

Defaulting to Breaking a Sweat Asking For Help

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.

The Love of Lazy

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]

The Obsession with Rewarding Effort and Hard Work

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.

The Hero Culture

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.

Separating Value from Effort

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.

No Tolerance For Wasting My Time

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.

It’s Not Fair, That It Takes So Little Work But Costs So Much

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.

Praising Effort as the Default

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.

Optimizing for Automation and Future Laziness

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.

Pattern Matching for Future Laziness

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?”

Removing the Unnecessary for Future Laziness

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.

Optimizing Physical Environment for Future Laziness

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.”

Having to Unlearn Behaviors Taught in School

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]

The Craziness of Effort Unveiled

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.”

The Taxicab Principle

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]

How To Stop Praising Effort

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]

Automated Testing Struggling to Go Fast

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]

Letting Technology Get In The Way

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.

Test Driven Development Helps Reduce Some Problems

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.

Relying on Backstops Creates Bad Habits

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.

Testing vs Checking

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.

The $465 Million Deployment Mistake

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.

Business Rules So Complicated They Are Untestable Is a Smell

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.

Automated Testing Suites Are Liberating

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.

Automated Testing Frees QA Staff to Do Meaningful Work

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.

Where Do You Start?

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.

Automated Testing Enables Automated Deployment

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.

The Efficiency vs Innovation Problem

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.

Alignment on Best Practices to Minimize Pain, Openness to Explore

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.

Technical Darwinism, The Easiest Path Becomes The Standard

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.

Unreasonble Standards Get Ignored

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.

Standards Help Reduce Wasting Time

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?

Standards at Team vs Organization 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.

Danger in Valuing Experts of the Standard

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.

Conventions are Good, Policies are Inflexible

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.

Who is Accountable for the Decisions?

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.

The Innovation Slider Button

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.

Lack of Standards Allow Immature Teams to Avoid Accountability

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.

Innovation Big Wave Riders

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.

Why Do We Fall for the Multitasking in Agile Trap

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?

The Organizational Multiple Resource Trap of Splitting People’s Time

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.

Tearing a Person in Half is a Powerful Metaphor

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.

The No Projects Movement Time Fallacy

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.

Which Project is My Priority

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.

Coordinating Availability

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.

Using Split Resources as the Scapegoat

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]

Bucking the Norm Causes Issues

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.

Collecting Resources to Build Your Empire

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.”

Multitasking in Agile on a Team is Ownership Smell

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.

Competing Desires, Makes Focus Difficult

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.

The Dreaded Resource Allocation Spreadsheet

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…

The Urgency Game

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?

How Do You Stop The Madness

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.

Fire Fighting Culture

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.

Asking For Help Can Feel Silly

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?

When Should You Ask For Help

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?

When Shouldn’t You Ask For Help

Roy: When shouldn’t you ask for help?

Why Don’t People 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.

Putting Yourself In Ask for Help Debt

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.

Being Forced To Help

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.

Missing Trust

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.”

The Cost of Asking for Help

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.

People Like To Help

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.

Creating a Culture of Asking For Help

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.”

Are You Asking For Help

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]

Some Examples of Ask For Help

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.

What Does An Organization That Asks For Help A Lot Look Like

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.’”

Are People Too Isolated

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.”

Barriers Preventing Asking For Help

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.

How Important Is Prioritizing Presence Over Planning

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.

What’s The Trouble With Planning

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.

An Involved Team Is More Energized

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?

Planning Is Not Doing

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…

What’s Next Instead of What’s Now Mentality

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.

The Assignment Is More Important Than The Plan

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.

Go Do It, Then I Will Talk About It

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.

It’s Not About Doing Agile, It’s About Doing Something Meaningful

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.

What If Everybody Just Trusted Each Other

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.

Agile Hates Process

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]

Stupidity Should Be Illegal

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.

Where Did All The Humans Go

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]

Laughter And Crying In The Workplace

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.

Human Resource Violations For Relationships

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.

Loving Our Co-Workers and Ourselves

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.

Separating Work and Life

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.

Why People Hate Their Jobs

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.

Doing Meaningful Work

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]

Build What You Want

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.

Find The Stuff You Can’t Avoid Doing and Must Do

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.

If You Are Struggling At Work You Are On The Wrong Path

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.

The Fear Of Taking Action

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.

What It Means To Own The Result

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?

The Effects Of Slowing Down

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”.

We Stop Trying When We Are Paralyzed By Fear

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.

Dealing With Uncomfortable People

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.

The Decider Protocol

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.”

Culture Of Uncomfortableness

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.

The Motivation Behind Slowing Down

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…

Lack Of Self-Confidence

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…

The Need For Affirmation

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.

Lack Of Trust

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]

Lack Of Decomposition Contributes to Slowing Down

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.

Demand Action If The Slowness Is Frustrating

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.

Are You Working If You Are Having Fun At Work

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]

Creating Separation and Transparency in Fun and Work

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.

My Culture Doesn’t Understand Having Fun At Work

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.”

Accountability and Trust Pave the Way For Having Fun At Work

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]

Daily Card Game

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.

Just Get The Work Done

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?

The Importance Of Fun

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.

Starting Small

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.

Having Fun, Correlation or Causation to High Performance

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.

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

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Clayton: I tried to think of all the reasons why we didn’t record a podcast, but they were all excuses.

Roy: The real reason is we went to the bar and went drinking instead.

My Boss Told Me To Do This Driven Development

Clayton: That sounds like an excuse. Today we’re going to talk about a common pattern that we have observed in a few different places, and it goes something like this.

You’ve got maybe some direction from the product side of the fence where the product owner’s got a boss, and they’ve got a boss, and somebody comes down and someone’s boss’s boss says, “The team should do this.” So the product owner comes in and says “OK here’s what we’re doing, because my boss told me to do this.”

Maybe that gets going a little bit, gets some traction and there’s some idea of what the team’s supposed to be doing, but then maybe someone on the technical side of the fence, like the dev manager or the dev manager’s boss, might say “Well, I want something to be done on the team and I don’t want to go in the backlog to get that stuff done. That might take too long.”

They force the dev manager to direct the team to do something. And since the team reports to the dev manager, the team feels obligated to do that. It’s like a bunch of different parties in the organization playing puppet master with the team. And the team never really gets a whole lot of traction. Would you say that’s a fair assessment, Derek?

Development Managers Undermining Product Owner Authority

Derek: Yeah, I mean, the first pattern is that usually the product manager, product person has trouble a extending…The pattern I tend to see is the product owner has trouble establishing authority and priority in the backlog because of stakeholders that they report to.

About the time they figure out how to get that done and they actually start to get the team baked a little bit and get going, what happens is the dev management side starts to realize that they’re no longer in control of their team, which was probably an illusion to begin with. And so to reassert control or authority back over their team, they tend to start asking their team to do things that aren’t part of that prioritized backlog.

Then the team a gets confused and there’s all sorts of tension between the product owner and the dev manager and the team doesn’t know what to do because they want to do what product wants them to do but they don’t want to be fired and they report to the dev manager. And so there’s just this crazy alpha thing that starts to happen and then the team generally starts to go fairly batshit about that time and all productivity goes out the window.

Clayton: Yes, I’ve always wondered when we see that if it’s a situation where the team feels obligated to do what the product owner says because they feel like, I read the Scrum book, or someone told me about Scrum and that’s how it’s supposed to work.

But, the fact that they all report to the dev manager, if the dev manager can instill a certain control, I wonder maybe it’s because usually the product owner is not at the same level or above the dev manager in the organization. So, they don’t really have the authority to go tell this person, “Too bad. You have to do things through the backlog.”

Mis-Alignment Within The Organization Around Product Owner Authority

Derek: What tends to happen is they tend to report usually to different tree structures. Then their bosses tend to report to different people. Often time in an organization they don’t report…their tree structures don’t cross paths, until you’re at the top tier of the organization.

What happens is the struggle goes up a level or two, and then at that level it’s like, I don’t want to bring this to my boss. Clayton, you and I report to the CEO, and I’m the VP of project management and you’re the CTO.

Our underlings are having this out a little bit, which really we’re having it out, we’re just doing it through our direct reports. But we don’t want to go to our boss and have it out because our boss is going to say, “Are you being a bunch of stupid little children? Why can’t you get along”?

Clayton: No, we can’t solve this pithy little problem on our own.

Roy: I think that’s the answer. It sounds like the development manager and the product owner just need to talk, and be like, “Hey, this isn’t working.” I like the idea of the development manager being organizationally apart from the product owner. I feel like one shouldn’t be above the other.

Loss Of Perceived Control

Derek: The trouble that you run into is when you start to go, at least on the Scrum side, you start to do something that’s more Scrum‑oriented, you start to give a lot of power to the team through empowerment, so the direct dev manager feels like they’re losing a lot of authority that they probably never really had anyway, because they don’t feel in control.

From a product perspective the product owner starts to take a lot more authority about the direction of the product. A lot of times the CTO or the senior dev manager or the dev director or the program director, or whatever you want to call it on the dev side, usually used to have a ton of influence in how the product was developed.

They start to feel like their control, or their influence, is going away. I think a lot of it is insecurity of, “Wait a minute product, you don’t actually need me and my management structure, you just need my developers.” Now a lot of times what you then see is it’s almost like the product owner is almost like the manager or the developers because the developers have respect for the product owner and are listening to the product owner and doing work for the product owner.

I think what happens is you get panic and the panic is like, “I have this urge that I still have control over these people. I’m going to ask them to do something and if they do it I know I still have control.” If they don’t do it and they refer to the product side of the fence then I know I’m losing my control and then that creates blowback upstream.

Clayton: Yeah, we’ve seen teams that have been fractured along those lines where there have been some people on the team who have the allegiance to the dev manager and not the whole structure. Then some of them they just don’t like that person or don’t get along with their manager.

They gravitate on the other person that has somewhat resemblance to the manager who is usually the product owner at this position of authority. You get this kind of fractured team.

Even if the two people aren’t trying to do it purposefully as a power struggle, maybe the dev manager overhears some conversation from the product owner or the product group saying, “I wish the teams would go faster.”

Maybe they’re not even trying to be malicious about it, but they think, “Oh I need to jump in there and make the teams faster. That’s my job, I manage the teams.” Those are the things that you could accidentally cause a rift in the team when you don’t even mean to.

Roy: I think it’s just a matter of making a mental switch from commander/control manager to more of a servant leader, right. Whereas a development manager you start to think more in line of like, “How can I help the team”? Rather than “How can I get the team to do what I want”?

With the product owner that’s a pretty common thing I’ve seen on multiple scrum teams, where the product owner start to take up the role of like the manager of the developers rather than being a member of the team. I think that’s a mistake, it’s very important to make the distinction between like, “You’re the product owner, not the team owner.”

The Product Owner As Part Of The Delivery Team

Clayton: Derek you were sharing some drawings that you had about how you’ve seen some team structure where the product owner is also the manager and they’re outside the team or sometimes they’re inside the team and sometimes they’re also the scrum master and all these different things.

I thought that was pretty interesting, I think in my experience. There are so many product owners that don’t ever treat themselves like a team. Most of the time they don’t, except when it behooves them. If there’s a decision to be made or they’re involved somehow and what the team is going to do next or something like that, then they’re definitely a part of the team.

When it comes to maybe being responsible for everything or like the not special treatment scenarios, they always view themselves as like, “Oh, I know I’m just separate, I’m not part of the team. I’m this product person throughout the organization. I report to the different tree.”

Derek: Yeah, I think it’s difficult. I go back‑and‑forth between where I think the product owner really…I definitely think the team should not be reporting to the product owner from an organizational structure or perspective. I definitely don’t see a ton of value in that or any value in that, I see a lot of conflict.

I go back‑and‑forth between whether they’re part of the team or not part of the team. Certainly they’re not part of this, the development team or the product team or whatever you want to call, the people doing the work…

Roy: Right, like they’re not going to pair with one of the developers.

Derek: Yeah, but I get a lot of questions. Should the product owner be a stand‑up? Should the product owner be part of the retrospective? A number of [inaudible 08:48] and I get really indecisive because on one hand I really think they are the customer. If we really think about it they are a proxy for the customer.

I don’t think the customer should be part of the team but I think they should be in damn close proximity interacting with the team and collaborating with the team a ton. When it comes to stand‑ups, yeah they should probably be there just so that if the team has questions there can be some dialogue that happens. When it comes to retrospective, I don’t know, I’m a little more at horn.

[crosstalk]

Clayton: …retrospective because that’s one pattern I’ve seen a lot, is the product owner will treat the retrospectives as optional. Where when they think they want to be there or there’s something that’s on their mind then they’re definitely going to be there and they’re going to be the loudest voice in the room.

When there’s some other conflicting meeting or maybe they don’t have anything to say to that particular retrospective they treat it like, “Yeah, I don’t really need to be there.”

I have seen where the team will make some decision about something that affects the product owner when they’re not there and then they get all up in arms like, “Well, hold on, you guys can’t make choices without me.” “Well you optionally decided not to come to the meeting, so what do you want”?

Roy: I feel like it is important for the product owner to be present at the retrospectives for exactly what you mentioned. Just because they don’t have a problem, like the rest of the team might still, so they want to bring up with them. They probably should be bringing that up throughout the week, but I totally think they should be part of the retrospectives.

They should be sitting with the team, and participating in stand‑ups. Other than having the authority to choose the priority of the work, they should be a team member. I agree they shouldn’t be pairing on any of the work because there’s a conflict of interest there, but they should be involved in all the other ceremonies.

Too Much Familiarity Can Lead To Lack Of Candor

Derek: One of the things I see as a problem with that is there becomes too much familiarity, and then they actually do not do the product ownership role well enough. If I’m the customer of a service, when I’m no longer happy with the service I can voice very strongly that I’m not happy.

I can even say, “I’m so unhappy that I’m willing to go get my service somewhere else.” I’m sorry, Target, if you piss me off, Wal‑Mart is more than willing to take my money and they’re pretty close to the same thing.

Where if I work at Target, it becomes very difficult for me to say, “Hey Target, if I have a bad experience I’m going to stop working here,” because I have a bunch of friends. If I’m negative about it, then people stop shopping there, and maybe I lose my job. I see that happen with product owners, they consider themselves too integrated into the team.

The benefit is there’s more, “Hey, we’re all in this together,” which I think is really good, but they lose their objectivity with the team to say, “Ultimately…”

Clayton: Maybe they would get to a point where they’re too comfortable? They spend so much time with the team, and they think the team’s doing a good job, they know they’re trying really hard, all those kinds of things. If I’m the Target consumer, do I think everybody at Target’s trying really hard? I guess, but I don’t really care. If they piss me off enough I’m going to go somewhere else.

Roy: I think that’s bad product ownership. It shouldn’t matter. I feel that that is not having the courage to say what you think, not being honest with yourself about how you really feel.

Clayton: Does it make it easier to get in that position if you spend too much time with the team, or you treat yourself like you’re in it with the team?

Roy: I agree that that definitely makes it easier, but I don’t think that excuses that behavior.

Living In A No Product Owner World

Derek: In a perfect world, there is no product owner. The team is the product owner, or they’re sitting with the customer who is guiding the product, or you’re doing something that is lean start‑up enough that you are getting instant feedback and everybody is providing value to team. The problem is, we don’t live in that world.

Most of these organizations that are trying to do an agile adoption are so far from that, I don’t think they can jump right into that. In the same way, I don’t think they’re adult enough to be like that. You’re absolutely right, I should be able to say, “No hurt feelings.” It doesn’t matter how much Clayton and I are friends.

If I believe the work we’re doing is not quality I should be able to have that discussion. I shouldn’t have to worry about his hurt feelings. The reality is, that’s not the case of most people in corporate America going through transformation.

Roy: But it is what they should be striving for. That’s why we use the core protocols. We have that kind of atmosphere within Integrum. It’s not that I don’t want to hurt your feelings, it’s because I respect you and appreciate the work that I’m going to give you this feedback, tell you the truth.

Derek: This is why I struggle with Agile a lot. If we really look at the ideal, Scrum is bullshit. Creating this big schedule, doing all these burn‑downs, doing a lot of this stuff ‑‑ to me, if we’re all adults, we’re all acting in the right way, we’re all part of the product ‑‑ why do we need a Scrum Master? Why do we need product owner? Why do we need any of this to begin with?

Some of the process is there just as tools to help us build discipline. Once we have some of that discipline and we’re mature enough to do that, all that stuff becomes optional at that point.

Roy: Like bootstrapping the team and then letting it run on its own?

The Product Owner’s Authority

Clayton: I think that’s fair. Most people that think they’re at that level [inaudible 14:30] if you think you’re an expert programmer, you’re probably not an expert programmer. If you think you don’t need any discipline reinforcing process, you probably aren’t disciplined enough to go without it.

I wanted to go back to one thing you mentioned at the beginning, Derek, about the scenario where the product owner is giving some stakeholder feedback, for instance the scenario of, “The product manager told me that the next thing we’re doing is this, so we’re doing that,” and comparing that with what they’re supposed to be doing, which is being the customer. I think those two things are misaligned.

Do you think that takes away from the product owner’s credibility? They’re not representing the customer, they’re representing some other person…

Derek: Yes. I had this conversation today in spades. A common thing that I hear all the time is that if Clayton is the boss, I am the product owner, Roy is part of the development team, and I come in and say, “Hey Roy, we’re going to switch this sprint and we’re going to do this big project X,” and you feel like this is just the dumbest thing.

We always try to do it, we never really do it. You don’t understand it. You ask me, “Why are we doing that? Why are we not doing the big thing that you said was so important last week”? My answer is, “Because Clayton said we need to do it, so we just need to do it. Mom said we need to do it.”

I become the barking dog with no teeth that has no bite, because I have now told Roy I have no authority at all. I just do what Clayton tells me. From that point forward, everything I say is utter BS. Roy’s going, “Why am I even listening to Derek”?

Roy: I should just listen to Clayton.

Derek: Two seconds later, Clayton is going to walk in here and tell us whatever he told us was crap anyway.

Clayton: You seem expendable at that point.

Derek: Right.

Clayton: OK. I just wanted to cover that real quick…

Derek: If you’re in that position ‑‑ this is what I’ve been coaching…

Clayton: It’s the real world follow‑up.

Understand The Why If You Want To Be A Product Owner With Authority

Derek: …The real world follow‑up, because I want to make sure that people understand, is never ever say, “Somebody upstream told me.” It is your responsibility as a product owner, if Clayton tells me, “Our new priority is X,” I need to ask Clayton why.

I need to understand why, so that when Roy asks, “Why are we doing this”? I don’t say, “Because Clayton says.” I say, “Because as a business, we need to do X‑Y‑Z, we need to achieve this, we need to do that.” When I’m able to do that, I have the respect and authority necessary to guide the team in the future.

Even though I’m not the one who came up with the idea. I’m not taking credit for the idea. I’m basically shielding…You don’t need to understand what every part of the business is doing, Roy. As a team, you just need to trust me that I’m doing the right thing for the product and the team.

Clayton: All right. I think we’re out of time, so thanks.

Jade Meskill: Hello, and 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.

What Happened to Extreme Programming (XP)

Jade: We were sitting around, trying to decide what to talk about, and the topic of eXtreme Programming came up. Hey Derek, what happened to XP?

Derek: [laughs] I think what we were talking about it is, we were laughing, making fun of some other industrial frameworks and enterprise things.

Roy: With trademarks.

Derek: You can infer what you want to infer, and we were laughing, but we do get a lot of our clients that for right or wrong, call what we do the Integrum right way. I made a comment that I was doing a lot of research on some of the elements of process, and trying to dissect things, and find commonalities, and deep dive into it.

That I was…I don’t want to say appalled, but amazed at how almost identical the Integrum way is to traditional XP in almost every way, shape and form.

Roy: We never claim to be original. [laughs] That’s right.

Derek: Right, which is hilarious, but it’s funny because we don’t sell that really do XP even though we firmly believe in XP. There is no marketability for…

Roy: Right.

Derek: …extreme programming.

Roy: You probably don’t sell the Integrum way either.

Extreme Programming Is Really Hard To Do

Derek: We don’t sell the Integrum way either, right? It’s just part of what we do, but I think the conversation started to diverge into, “Well, yeah, people stopped doing XP because XP is like really fuck hard to do.”

Roy: How much does XP speak about the organization around the actual development team?

Jade: Not much, I mean, it demands on on‑site customer which is very, very difficult to do. It’s even more difficult, I think, than having the product owner from Scrum.

I’ve been talking a lot about XP at the company that I’m working on right now. A lot of the engineers get excited about it, until they actually go to implement it.

It looks really great when you read the book. It’s really easy to get excited about the values and the principles and all those things, but doing it, is very, very difficult.

Agile Our Silos So We Can Keep Our Efficiencies

Derek: When I look at it, I mean, I think one of the things I find interesting is, I think, XP tends to say, “Stop the silos and everything you need to be successful, pull that into your team,” which, I think, honestly is probably the most scalable way to think about the world. I think what happens is all of these enterprise frameworks that are coming out, for lack of better word, or the agile scaling frameworks. What they try to do is say, “How do we build our silos back up in an agile way”?

We’ve got these independent agile teams that are doing things, but we are not allowing them to actually deliver things end‑to‑end. When we put some sort of ceiling or some roof on them where they have to interface back with the organization, which generally becomes the limiter that stops them from actually being hyper‑forming and it’s says like, “We need to have all those control valves to deal with it.”

Where, I think, maybe more of the XP way and I certainly don’t want address it, so I’m projecting here. But, I think, they’re kind of saying, “Hey, if you’ve got your customer and everything is self contained. It’s almost like every team is its own start‑up.”

I think if you look at what’s most scalable, that is probably the most scalable to do high performance. It might not be the most scalable for, “I want everything to be uniform. I want the most efficiency.”

That’s the problem. Big companies want efficiency, so they’re like, “Well, you want to implement Scrum the same way for everybody, so that it’s easy for somebody to go from one team to another team.” They know what they are doing. There is no cost to have to switch. Everybody is doing the same thing. We’re reporting the same way. We are all using the same tool.

Autonomy Leads To Chaos and Rework

Jade: We’re all making sure we’re not accidentally doing rework.

Derek: Right.

Roy: Because I feel like that’s kind of the problem with having a start‑up idea is that you could have one start‑up over here building some minimal viable product from something over here and then have another start‑up all the way across the company doing the exact same thing and essentially wasting resources.

Derek: OK, and the way I look at that is let the free market decide. If you’ve got two or three teams that are all trying to solve a similar problem, they are probably going to solve it slightly different and when they do that, the best one is going to rise to the top.

I think what happens is we get so concerned about, “Well, let’s not waste money allowing three different teams to do it.” That we add so much crap that none of the three teams deliver anything because they are quagmired in, “We have to have the perfect architecture or the perfect answer to this. Or it’s got to be the end all for all three of us.”

When in reality, a small part of it is really the same for all of us, but for the rest of us, it’s not.

Roy: So are we talking about an organization or the head of an organization like the parent entity, or whatever, who really acts more like a venture capitalist…

Derek: Sure.

The Budget Already Belongs To The Group

Roy: …in all of these little sub organizations that essentially get a budget? You have to figure out what they do want to do with it and it’s up to them to figure out the best way that they can add value back to the organization.

Derek: All big enterprises I know already do that. They already have organizational pieces. They already have the ability that they are putting budget by group by something, right?

The only difference is they are trying to squeeze efficiency between groups, or they try to say, “How can we make it so that we can communicate everything to everybody”? It’s unrealistic.

[crosstalk]

Optimizing for Efficiency, Stifles Innovation

Roy: Is the ironic part that by trying to maximize efficiency, they generate a ton of waste?

Derek: I don’t think they generate a ton of waste as much as they stifle innovation.

Roy: I guess what I mean in terms of waste is the bureaucratic overhead of dealing with the organization hierarchy, so you end up with a ton of middle managers and middle managers between managers and you end up with all of that type of waste that…

Derek: But to them it’s not waste because they are getting the value of being able to know what everybody is doing.

Roy: I see.

Conway’s Law Applies to Software Development

Jade: This is where Conway’s Law starts to play in, right? The software that is developed is a direct reflection of the communication processes over the organization itself, right?

If you have this very complex, very highly controlling, very convoluted communication environment, your software is going to be a direct reflection of that. I think that also plays into the XP principle of self‑similarity.

That was a hard one for me to comprehend for a long time. I had to really think about how self‑similarity really works. It’s based on the same idea, right?

That if you have team that is functioning in this way, it’s going to generate software that functions in this way. If the organization is functioning that way, it’s going to generate teams that work that way.

Team Equals Product

Derek: It’s a classic Jim and Michele McCarthy’s “Team equals Product.” I think that there is so much truism to that, but we don’t want to admit it, right?

Jade: Right.

Roy: Especially as a management team where the product is a development team.

Derek: We want our products to be nimble and light and clean and simple and all of these words, but we build our organizations the exact opposite of the traits that we’re actually looking for. I think I read an article on Medium or one of these.

There are companies trying to do “no management structure,” right?

Jade: Yeah.

Derek: I think there are some other examples. I think this is…

Jade: The whole aristocracy.

Organizational Innovation

Derek: Yeah, I think there’s problems with this stuff. I don’t want to sound too idealistic or like happy‑hippie. I don’t think anybody is saying that it’s the magic pill and that everything works and that people have it done, but I think the next real innovation is going to be organizational innovation.

Meaning we’ve squeezed the crap out of efficiency for technology for the most part. I think our next big wave where we’re going to get real innovation, innovation where we’re going to see like leaps and bounds and technology advancement, not efficiency is going to be when we can figure out how to optimize how we behave as human beings into organizational structure, like work structure.

Jade: How does XP play into that? If we think that the ideas, the core principles and values of XP are fundamental to the way that we work, how do they play into that next revolution of organization?

Revolution In The Organization

Derek: I think some of it is they are just like they were revolutionary and radical ideas for software teams. I think they’re revolutionary and radical ideas for managers and organizations meaning, think about it if you said, “We need to keep all organizations simple.”

A good example of this, to me, would be Netflix’s vacation policy. “Our vacation policy is you can have as much vacation as you want. We don’t really care. Check with your team. Make sure that your team says that you’re providing value and as a team, you guys figure that out. We’re not going to have a policy.”

I’ve seen three and four person companies that will go to war over what their vacation policy is going to be. Which is just, to me, insane, but it’s like that institutional, but like you have to have a policy. There is no way.

We’re not talking a 30,000 person company switching from like, “Well, we’ve got regulation and we’ve got history and we’ve got accrued hours and we can’t just flip the switch and go to this like really simple vacation policy of, ‘Don’t be an idiot. Do what’s right.’”

We’re seeing brand new companies that form that have so much organizational baggage from the people starting those companies. That they are saying, “We can’t do this.”

Roy: I wonder how much of that though is people trying to avoid personal conflict. For example, with their vacation policy and only having a four person organization. If you instill this policy and you break the policy by taking three months of vacation in the year or whatever, now I can point at a policy and it’s not me accusing you.

It’s me pointing to the policy and it’s you versus the policy. Whereas, if you’re being a jerk, but we don’t have an agreement ahead of time, then all of sudden I have to bring it up with you. I have to take responsibility for how I feel.

Jade: I think that plays a lot into it. When we started Integrum, a lot of people who were mentoring me were freaking out because we wouldn’t define those things like vacation policy, like some of things, because we didn’t want policy.

It’s amazing when you create a policy, how everyone becomes a lawyer in the company. I’ve seen it in many different companies that I’ve been in where as soon as the policy comes up, everyone is figuring out the loopholes, the ways around it, all of those things. Where if you don’t have a policy, it does force you to deal it with on a human, person‑to‑person basis.

Hiring People You Don’t Trust

Derek: That’s not scalable. What starts happening is A ‑‑ we don’t trust people, so that might work really well for this little group, but I can’t imagine doing it for…It’s like, “Why are you hiring people you don’t trust”?

This goes back to the core things. To me, when we talk about some of the simplicity, some of this empowerment, some of the self‑organization and self‑direction, you have to get to a point where you have such vulnerability and such courage as a leader and as a manager or an owner or CEO that you just unlock the awesome.

The minute that you take good people and you start to put things around that start to show that you’re not vulnerable or that you’re not trusting, like Jade was saying, they start to build walls around that almost instantly not even knowing. Just like a self‑defense mechanism, it turns into justification.

You cut out all the ability to be the best human being you can be. I think when we can get to a state on teams where we’re cutting through all the crap, and we’re just being the most raw that we can be together as people and not having to deal with all the other crap, we unlock all sorts of potential. But that’s so hard to do.

Roy: Some of that too is that by trusting the people to make the decisions what ends up happening is they probably make better decisions than if you instill the rules on.

Going back to your vacation idea, if you instill a two or three week vacation policy on somebody, they’re going to make sure they use up every single day. But if the rule is “don’t be an asshole,” I would not be surprise if people all of a sudden took one week instead of three or whatever. And I bet that extends way beyond vacation policies.

Derek: Our number one complaint through hundred employees over time, the number one complaint with, say, vacation or lack of vacation policy is “I don’t like this because I don’t know how much time I can take. So I think you guys are being mean to me because you’re trying to get me to not take vacation by not telling me how much vacation I can take,” which to me is just, boom, mind blowing.

How does saying, “Take as much as you is feel necessary and as much as the team can” gets turned around into, “This is an evil Jedi mind trick that’s getting me to not take vacation.”

Jade: We’re not that smart [laughs] .

The Right Amount of Flairs

Roy: There’s an infamous scene from “Office Space” where the guy is like, “You need to have 17 pieces of flairs.” He’s like, “OK. So I need to get 17 pieces of flairs.” He said, “Well, you don’t need 17 pieces of flairs. You just need to have enough.” He’s like, “OK. Well, I think 3 is enough.” He said, “Well, 3 isn’t really enough. We were thinking more like 17,” or whatever.

I think that’s the case in most organizations is I bet people are suspicious and think that there’s a hidden number behind the scenes, and they are just not allowed to know what that number is.

Derek: What’s funny is we even had some people that asked the question. I don’t know. What do you guys see [inaudible 13:09] ? I don’t know. In most places, two or four weeks, but it depends on what your project is. I think we’re pretty open about that. I don’t think we were saying, “Well, we’re not going to tell you what the magic number is.”

Jade: Or we’ll get mad if you go over the secret number.

Roy: Right, exactly. We have secret meetings about the fact that you went over, and when you come back from vacation, your ass is fired.

Derek: [laughs] What’s crazy is we would have some people that would take a little more vacation, and you’d have other people almost get mad at them. It’s like, “They’re following the same thing that you’re following. You just have [inaudible 13:40] hang up that you don’t want to do it.”

Roy: Although them getting mad is how the system self‑corrects too. If somebody’s obviously abusing the system, then everybody else gets mad. That’s how you deal with that organizationally.

The Zen Of Extreme Programming, Value Is What You Like

Derek: I think that it’s just difficult for people to do. I think when I look at the XP stuff, the reason XP stuff is so hard is because it is so, so simple and so liberating. It’s like Zen.

If you listen to us, Ron…I love our conversation about value and argument, and as much as it sucks to say, “Value is what you like,” at the end of the day, that’s what value is.

It seems too simplistic and too easy and too raw, but I think that’s how a lot of these things tend to be. If you break them down to their bare essence and be human and be simple about it, then you get pretty tremendous results.

Jade: I remember the first time I came across XP in the late ’90s, I saw it, and I said, “This will never work. This is insane.” We just couldn’t apply it. I was working at a small place that had a very tight‑knit team.

Roy: I was still in elementary school.

Jade: Shut up.

[laughter]

Jade: And still rejected it. Because it is. It’s beautifully simple, but very, very hard to live by.

And on that note, thanks for listening to the Agile Weekly Podcast. We’ll catch you next week.

Roy: Goodbye.

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

Derek: I’m Derek Neighbors.

Clayton: I’m Clayton Lengel‑Zigich

Roy: And I’m Roy VanDeWater.

Jade: Guys, today we wanted to talk about an article that will be published in Agile Weekly tomorrow.

Roy: Product tie in there.

[laughter]

Commitment Considered Harmful

Jade: Subscribe to the Agile Weekly Newsletter at AgileWeekly.com. Written by Allan Kelly, the title is, Commitment Considered Harmful. I know we have no opinions or thoughts about this, so this might be a very boring podcast.

Roy: I’m curious, why is commitment considered harmful? By who, maybe is a better question?

Jade: Allen has to say that he has seen through some of his interactions with clients and other people, that…this is a quote from him. Commitment protocol for filling an iteration is actively damaging for software development teams in anything other than the very short‑run.

Derek, you’re shaking your head.

Derek: I don’t know. Maybe it’s too many years of therapy coming out.

Jade: Too few?

[laughter]

The Boss Will Manipulate You

Derek: If I follow the trail…when I first saw this article, I immediately thought that it was part of the no estimates crowd shtick of stuff.

Jade: He specifically states that he does not follow the no‑estimates crowd.

Derek: Yeah, but I certainly thought it was going down that route. What I tend to see is this pattern of, there’s something, there’s something, there’s something, and it’s all rooted in two things. Every software manager is evil and the people will manipulate the system or me.

To me, going back to McCarthy’s core protocols and the perfect boss, I expect to work in a place with fucking adults. At some point, how long can we basically say, the boss might manipulate me? Well then go to a fricking job that doesn’t have a boss that manipulates you.

That’s got nothing to do with commitment. The boss that’s manipulating you with commitment or estimates is going to manipulate you if you don’t have commitment or estimates either, because they’re a manipulating asshole.

Roy: Yeah, that argument’s just too broad. You can replace whatever with, there’s this thing that some people have used, so you don’t do it.

Attack The System, Not The People

Jade: Let’s step back a second, though. We do a lot of consulting. We’ve been to a lot of companies. How many have you showed up at that are full of fully functioning adults?

Derek: Not a ton, but I think my problem is attack that problem. Don’t attack the lack of commitment as being a problem. I hear commitment. I hear estimates. I hear accountability. I hear all of these things.

The very first thing that was thrown out here is, “Well, you can’t have commitment, because people will game it.” Well, people will game anything. So if you have a culture that is OK with people gaming things.

Roy: We talked about it in the past that‑‑what is it? I think, Jade, you quoted somebody that said, “96% of a person’s ability to self‑improve is dictated by the system.” Do you remember who that was?

Jade: W. Edwards Deming.

Culture of Commitment

Roy: There you go. That may be the same problem in this case. What if it is a culture of a commitment that is holding these people back from becoming the adults they can? Because they are currently being rewarded for making false commitments or for gaming the system.

Derek: Right. I would argue that in that point they’re not really making commitments. The word ‘commitment’ is being bastardized to control somebody to say, “You have to tell me how much you’re going to do,” and then I’m going to threaten you, or lord over you, or manipulate you.

Jade: They’d beat you with a stick.

Derek: Beat you with a stick, beyond that. Well, to me, that’s not a commitment. A commitment is me saying what I really can believe, and me truly believing in that and doing that. That’s not somebody else saying, “Hey, Jade. I want you to commit to mowing my lawn tomorrow. All sorts of bad things are going to happen if you don’t mow my lawn. You’re OK with that, right? Your job is depending on it. You’re OK with it?”

I feel like to me, that’s not a fair thing for commitments, or for estimates, or for anything else.

Bad Managers Abuse The System

Jade: No. I think that what we would argue if we were working with a team, and they said, “Well, we’re doing commitments.” I think from our point of view, we would say, “OK. Why don’t you look at the work that you do?” Maybe the team, they look at one story, and they say, “This is all we can do.”

The manager, I think the way that people abuse commitment, and say, “Hey, you guys have 150 hours over the next sprint, that all you are going to be working on this.” You have to have 150 hours of work to do.

I think we would say, “If you want to commit to doing 20 hours of work, and that’s all you want to commit to, that’s all your going to commit to.” That’s an acceptable scenario, as far as I think we’re concerned with how commitment works. That’s now how most people… Bad managers aren’t going to abuse that, and so that comes out his commitment is bad.

Does Quality Suffer

Derek: What about the idea though, if you’re feeling rushed, and that making the commitment is the most important thing above all else, like keeping to your word, the idea that you allow quality to suffer because of that. That you might choose to take some shortcuts or to cut some corners, because you are trying to push it out the door.

You don’t necessarily do all the good practices that you want to have, and maintain a quality suffer project. Those things will buildup over time to create a ton of technical debt that you can no longer maintain.

Jade: Yeah. That’s just part of, I think, if you’re committing to doing something and you have some standard for what it needs to be done. If the standard of done means half‑assed, then, OK, fine. No, that’s not really how you want standard done.

I think that is part of the bigger picture of, “What does it mean to be done?” If we’re going to rush through something, are we really done? Did we really “hit our commitment”? Probably not.

Derek: I think that it’s kind of the straw man out there, right? People like to throw it out. I see so many teams that have no sense of commitment that have really crappy quality.

Like to me, those things are not linked. I think what happens is when somebody is forcing you to the trough to drink water and really just slams your head in, you’re going to do stupid things. But I don’t think that’s because commitment is bad.

I would say that a team that is truly committed and committed in everything they do, they say, “Hey, we’re going to have…we’re going to write tests first. We’re going to make sure that our product owner is happy with the work that we’re doing. We’re going to commit to all these things and we’re going to commit to do what we say we’re going to do.”

You can’t say, “We finished everything, but it doesn’t meet the product owner’s requirements and it’s not tested and it’s not…” because at that point you don’t have a commitment either.

Jade: But technically, it’s done.

Derek: I know…

Do What You Say You Are Going To Do

Jade: The way you said, the phrase, “Do what you say you’re going to do.” I think that was a big shift that we had at Integrum of the concept. It sounds so simple, right? Do you what you say you’re going to do.

I think that’s really to me is what commitment means. I’m going to say I’m going to do something and then, I’m going to do it, but that’s not easy.

Derek: No. It’s not easy and I think commitment isn’t easy. Like committed to do something is difficult, right? But it doesn’t have to be this, you know, abusive tool.

The Truth Killer

Jade: I think to me the thing that I really love about Agile when it’s done really, really well is it becomes the truth killer. So if you can go around and say, “My team is so awesome. I’m so awesome,” and all this stuff and make all these promises and never, ever fulfill them like you’re just a lying piece of crap.

Who can trust you? Whereas, if you say, “Hey, I can only do this really, really small thing,” but I think a lot of developers have problems with this because when they say, “Oh yeah, I can do this. I do this,” and somebody says, “OK, so you’re committing to that and I’m going to kind of hold you to that. Let’s talk about it at the end,” and then, you can’t do it.

The developer doesn’t say, “Man, maybe I think I’m way full of myself and I should not commit to nearly as much, less time, next time. I should commit to half of that, because I didn’t even get close.”

Instead they say, “Well, the problem was this and the problem was that.” Everybody else in the world was the problem and it wasn’t me.

I think that’s just…if you’re honest with yourself about wanting to improve and you really want feedback, the only way you can do that is to measure yourself. So if you’re not saying, “I think I can do X,” and then, going out and doing it and measuring can you do it, how the hell can you improve?

Commitment Adds Stress

Derek: So we can go from the standpoint of commitment adds at least some level of stress to the…

Jade: True, it does.

Derek: …to the developer, right? Because now they are kind of freaking out about this promise that they made and trying to keep it. But what positive benefit does a commitment actually get?

If I’m a developer making a commitment, what benefit do I get by, other than stressing out about it? Is that stressing out, is that the benefit that I get? That I get more accurate at estimating sounds, I get more accurate at committing sounds great.

But getting better at committing if committing itself doesn’t give me any value, am I just getting better at something that doesn’t matter?

Commitment As A Trust Builder

Jade: I think you can build some trust. Or if you say you’re going to do something and you do it and you repeat that multiple times, you can build some trust that when you say you’ll do something, you’ll do it.

I think, it also is a discipline thing. Having a commitment, I think, helps you be disciplined. Discipline, I think, is a very difficult thing to have in software development.

A lot of teams lack that and I think that’s just another mechanism that helps reinforce that.

Commitment Is A Two-Way Street

Derek: I think the other thing is commitment is a two‑way street. It’s not just the developer who’s committed. The idea is that I’m saying, “I will do this if you don’t bring in anything else to me to do during this period.”

Jade: Like the Scrum?

Derek: Yeah. I mean, I think it’s part of the whole contract. So when people say, “Like we do Scrum, but we don’t do this and we don’t do any of this stuff.” It’s like, “Well, how can you even live up to the basic premise of Scrum, which was we’re going to agree to do X, Y, Z, you agree to leave us alone?”

One of the things I’ll add is any developer out there that thinks that estimates, commitments, everything else are horse crap, come work for me and let’s talk about how we pay you. Is every week I’ll decide what we pay you?

I’m not going to tell you what you get paid until after you’ve done the work and it’s entirely negotiable up to me whether I think you deserve the money or not. You may get money. You many not get money and you’re going to be happy about it.

That’s what you do to every damn product owner you work with when you have no ability to say, “This is what you’re getting.” They’re spending money on you. They are giving money to you to do a job.

If you don’t do what you say you can do, and you continue to extend…this is why so many companies have problems is contractors or independent third‑party companies where they get to the point where they’ve not delivered what they said they were going to deliver and everybody ends up pissed off and everybody gets sued.

This is why this happens. I think it’s almost juvenile or naive to think, “Why can’t we just meander and do whatever we want and you just pay us?”

Jade: This state of affairs would be totally unacceptable in just about every other industry.

Derek: Sure, it would be.

Why Software Developers Get Away With It

Jade: What is it about software development that allows people to think that that’s OK?

Derek: It’s creative. It’s an art. It’s an unknown magic. I give money to this group of people that have weird social habits. That I do not understand and I have never experienced them before. They do some magic.

The type of the keyboard and magic happens. Then, they have this thing that I cannot possibly understand how it works. I could never possibly do it myself. I couldn’t learn how to do it.

So, I just have to keep appeasing the magic over here.

Jade: But this happens to people that do understand that world as well.

Always Hoping It Will Be Different This Time

Derek: That goes back to the hope thing, then, right? If people are hoping that…at the beginning of this, you could have the worst possible sprint and have a retrospective where you’re talking about all these terrible things.

A lot of times when the sprint planning starts the next time, it’s like, “OK, we have a clean slate. Everything’s in the air for this time. Everyone is very hopeful.”

Because people want to be hopeful, right? They want to think that this time’s going to be different. So they repeat the same mistakes.

Jade: Robo Roy did you have something to say?

Roy: If I hold this is in, maybe it’ll get better. It’s getting better.

I think that’s one of our things is we don’t see ourselves as developers. Often times, it’s somebody delivering a service of some kind and having an output. I think failure is OK.

I think it’s entirely OK, but the failure shouldn’t be that we aren’t able to deliver something. It’s whether what we deliver or not necessarily is usable or meaningful, right?

We should be able to deliver something that somebody can learn from. The business should get something at the end that they can put into practice and say like, “Oh, this is right or this is wrong.”

Derek: Do y’all know the [inaudible] you’re saying?

Roy: Yeah.

Derek: I’m just going to sell it now.

The Power Of Doing What You Say You Are Going To Do

Roy: I think ultimately we just…as practitioners if we could do what we say we’re going to do, that would go so much further than where we currently are today, it’s not even funny.

Jade: So how do we get there? We’ve got two minutes to solve this problem.

Derek: Hey, I didn’t commit to anything. I would say the best thing that I think works for teams if they want to improve commitment is basically really take a deep dive in look at what it means to do what you say you’re going to do and also, understand that you can say you’re going to do smaller things than other people want you to do.

I can commit to less work than people want me to commit to and if I can do that and have success and build and learn and inspect it to death and improve, I think that is a better long‑term outcome than basically lying every time and not ever fulfilling my promises.

Jade: Is that part of the major problem?

Roy: Yes.

Jade: Is that people can’t reconcile that fact?

Jade: Yes.

Derek: They don’t feel empowered to say no to those things. Either by themselves or by some other constraint.

Don’t Be Stupid On Purpose

Roy: I think they are stupid on purpose, too. Most teams I see are still doing two week sprints, still doing like…I mean, if you’re not able to do what you say you’re going to do, go to a smaller block of something and say like, “If I say I’m going to do this in the next two hours, can I really do it.”

You’re much better off at failing at doing something in two hours, then you are failing in doing something in 10 days or 15 days.

Derek: I was working with a team and I ripped down the board and said, “Show me what you can do in one hour.” They couldn’t do it.

Roy: I think that’s a big problem. I don’t think it’s a matter of not allowing people to be creative or not giving them license to do something.

I think in teams that are high‑performing, they are not doing a bunch of planning. They are not doing a bunch of estimating, but they don’t need to because if they say, “Hey, we can deliver you something kick‑ass in four weeks.”

There’s trust that they’re going to do it in four weeks. I don’t have to think twice about it, right? Where you have to get into the legalism of things are when there is absolutely no trust.

The problem is the only way to build trust is to do what you say you’re going to do. Until you can do that, you’re screwed.

Jade: Tell us what you guys think about commitments. Any experiences that you’ve had with teams or yourself, failures to commit, all of these things.

You can find us on Twitter @Agileweekly, and on Facebook, facebook.com/agileweekly. Talk to you next week.

Clayton Lengel-Zigich: Welcome to another episode of the Agile weekly podcast. I am Clayton Lengel-Zigich.

Roy VandeWater: I’m Roy VandeWater.

Failing A Sprint

Clayton: Today we’re going to be talking about a very rare thing that we’ve heard about from certain people. It’s called, “What happens when you fail your sprint.”

Roy: I’ve never experienced this personally.

Clayton: Me either. Of course not.

Roy: Right. Hypothetically, if it did happen, what do you do?

What Constitutes Failing A Sprint

Clayton: I guess we should define it first. Roy and I were talking about this topic earlier today and I was thinking, “I wonder if we think the same thing ‑‑ what it means if we say ‘fail a sprint’”? Is failing a Sprint the same thing as, you committed to do five stories, and you only got four done? Are we calling that a failure?

Roy: Yeah.

What About The Sprint Goal

Clayton: OK, I think so, too. What if you committed to doing five stories and then, you also had a sprint goal and you fulfilled the sprint goal, but you didn’t do one of the stories? Is that a failure?

Roy: That’s interesting. I haven’t really made sprint goals all that often, which is probably a bigger problem, but that’s an interesting point. If the value of the sprint is to achieve your sprint goal and your stories are almost an implementation to try to achieve that goal, then maybe achieving the sprint goal is all you need.

Clayton: For example, I always like to use the travel website. If our sprint goal is to make it easier for people to book a rental car when they book a cruise vacation, and we fulfill our sprint goal, but we didn’t do one of the stories, does it really matter?

Roy: I think that one is a little bit in our sync, because making it easier is like a slighter scale. You can make it a teeny, teeny little bit easier by doing a text change. I think the important part…I think what I really consider a failure is when you promise to deliver something and you fail to keep your promise. When essentially, you lose trust with the people that you have promised to, because you didn’t do what you said you were going to do.

Clayton: Like maybe, the product owner. You say, “Hey product owner, leave me alone for the next week and I promise you that I will get this thing done.” Then, in a week, you don’t get it done. So now the product owner trusts you less.

Roy: Right, exactly.

Not Doing What You Say You Are Going To Do

Clayton: OK. I think that makes sense. If we define failure as making a promise and then not…basically, we’re saying you aren’t doing what you said you were going to do. We talk about that, we use that phrase a lot internally. If you say that sprint failure is not doing what you said you were going to do, a lot of people I know don’t like to talk about sprint failure because they don’t like to talk about failing.

Roy: Well, it’s confrontational, of a sort.

Explaining Away The Failure

Clayton: I see a lot of people, a lot of teams that will try to find all kinds of ways to explain why they didn’t really fail. Whether it’s, “Well we were working on these five things, but then something happened and we didn’t have to this anymore, so we didn’t really technically fail because we still did the important stuff.”

Roy: Or “We worked on all of these things, but then this major interruption happened or this outside dependency caused us to fail our sprint because we were waiting to get something back from them. We thought we’d get it this week and we didn’t.”

Using Failure As A Mechanism To Learn

Clayton: One thing I’ve always noticed or thought, personally, is that if you don’t view failure as that big of a deal, if you view it as a learning moment, or a way that you can improve, then it doesn’t really matter if you failed because who cares, you don’t have to try to explain it away.

Roy: As long as you’re honest about it, you try to fix it for the next time.

Clayton: Let’s describe that then. I think there was a team that you were working with or we were talking about that had failed their sprint, or they weren’t going to get it done on time. So they cancelled their demo.

Roy: They actually postponed their demo about three or four days under the idea of, “We don’t have anything to demo right now because we didn’t do the stories we said we were going to do, but we should have them done in three days so we’re going to go ahead and do the demo then.

Clayton: In the entire sprint review we include the demo and the retrospective. Did they do the retrospective or did they skip that part too?

Roy: No, as far as I know the iteration was essentially extended for an additional three days.

Partially Done, Should We Demo It

Clayton: In that case we would call that a failure because they didn’t get it done when they said they’d get it done. What advice would you give to a team that doesn’t get things done? Maybe they got 80 percent of their stories done. Let’s say that rather than being really bad and getting 80 percent of everything done, they actually got eight out of ten stories done. Would you suggest that they show something in the demo? How would they handle that in the demo? What would the team do?

Roy: I would say that if you actually complete something, then show it off because it’s going to go into production, but if you haven’t finished it don’t show it because when you’re demoing, you’re demoing to not just a product owner who knows what’s going on within the team and was probably made aware way before this that not everything was going to get done, but you’re also demoing to the stakeholders, potentially even users of the system and so I feel it’s important to actually show them what they are now able to have.

Clayton: So those are the things you only demo what you’ve actually shipped.

Roy: Exactly.

Clayton: I have always gone back and forth on showing things that aren’t done‑done or unaccepted, only for the sake of maybe really valuing extra feedback. I guess there are probably more bad behaviors that come from demoing half done things or not done things then you’d get a benefit from the feedback.

Roy: I’m on the fence on that too. On one hand I think you shouldn’t demo anything that isn’t done because you are setting this expectation that features part of the product when you are starting a new moderation and it may not be prioritized anymore because something may have come up. The specific details on how to post a function may completely change. Essentially you are demonstrating something that may never happen so you are setting expectations that you don’t have the power to meet.

However, gaining additional feedback totally makes sense ‑‑ that may be what drives the actual change so it’s really dangerous I feel, but if you were to be extremely explicit about the fact that this is not finished, there is no promise, you are doing it purely to receive feedback, I could see that it might be OK.

Clayton: So probably don’t ever do that because most people are not going to listen to you when you say you are not going to get this.

Roy: I could see tens of people attending the meeting and be, “Wow”! And then selling to all the customers and then it gets put on the back and it’s never going to get done. Then you are taking power away from the product all of a sudden cause now they have to finish it because all the customers are demanding it.

Disclosing Sprint Failure

Clayton: In a crucial demo part of this review, some people from the team might actually get up and showcase their features and show them on a projector screen. How do you think the team should address the sprint itself ‑‑ should they address the fact that they didn’t get it all done or should they skip over that?

Roy: It is important to be as transparent as possible. If a team has failed a sprint, totally own up to it. Explain why but be really careful that you are explaining why and not making excuses. I would recommend verbalizing all reasons things specifically the team did wrong. The example I made earlier where you are depending on an outside source and they weren’t able to get you the stuff you needed on time and you thought they would. I would word that as “We made a promise for things that we did not have direct control over and the way we would mitigate that in future is by only promising things we know we can deliver.”

Clayton: I was watching a video from Dan North speaking in the conference about high performing teams. One of the things I thought was really interesting was he was talking about the team he was working on ‑‑ which was really high performing. They had a component of their showcase, they were doing scrum, but the component of the demo where they talked about things they learned. I thought that was a better way where you can pretty much convey the same information but it’s not presented as, “We would have had that stuff done but excuse excuse excuse.”

We didn’t get things done being very afraid of failure and we learn these things that will help us in the future. I feel like that’s a much easier way to go about it even though its sugar coating the fact that you failed. I’m not necessarily advocating that but for teams that are transitioning, that aren’t as comfortable with conflict or perceived conflict involved with saying, “We failed.” ‑‑ technically what you learn might be easier.

Where Does The Retrospective Happen In Relation to Sprint Failure

Roy: There might be some difficulty with how you structure your retrospective with respect to your demo. You may not have identified a good way, you may not have learned what you are going to learn by your demo time because you might your retrospective afterwards.

Clayton: That’s a good point. What would you suggest is positive or healthy behavior that someone in a Scrum Master role might take to a team that failed a sprint?

Roy: I would absolutely orient a retrospect around it ‑‑ start out a notion like, “Hey we failed, how can we do better about it”? I have seen many retrospectives where it’s completely shoved under the rug or brushed over.

Clayton: There were some colossal failures but…

[cross talk]

Do Not Ignore Failure

Roy: Nobody wants to talk about it, it’s really painful and it’s conflict and probably there is going to be some finger pointing and yelling and pent‑up emotions. I would expect a high performing team, as much as you say it, failure shouldn’t be that big a deal so you can learn from it. On the other hand, neither should failure be a total non‑issue, right?

You shouldn’t ignore a failure and be, “Oh, whatever. We failed. We’ll fail again next week. We don’t really care about hitting our commitment anyway.” You have to find a balance and hopefully, the team cares enough to at least get somewhat passionate about making sure it doesn’t happen again.

Clayton: It gives them a really concrete thing to use for inspect and adapt, I think. I’ve always felt that as a Scrum Master, if there was a sprint failure, depending on what the circumstances are, as a facilitator you’re not going to go and force them down some path.

As the Scrum Master, there may be a responsibility ‑‑ you have to bring things to light, to really call out the 100 pound gorilla in the room and say, “Hey, I think we’re not talking about all the issues,” or maybe format the exercise or facilitate in a certain way, so that some of those things can come to light.

Hitting Commitments Is Possible

Roy: That is interesting, though, because I found that most teams don’t even believe that consistent success is possible. I know I didn’t believe that myself back when we were doing contracting work with Integrum. I always thought that Derek and Jade kept pushing us to try to hit our sprints continually.

I was like, “You know, that’s a nice ideal, but that’s not actually reality.” It wasn’t until I was on a team where we consistently hit our sprint week after week for months at a time and we had one failure and it was a big deal, but then we were right back on track again. It’s truly possible, but I know that until that happened to me, I did not believe it.

Clayton: One of the interesting things about that specific example was the answer to “The sprints are failing,” was not, “Work harder.” It was, “Do less until you start succeeding.”

That’s one thing that a lot of teams…I’ve seen teams that will fail weeks at a time, but then, they consistently commit to big chunks of work. Rather than saying, “Hey, maybe we need to slow down to go fast, so let’s do less and less until we are successful.”

Roy: Well, product owners, especially are really, really touchy about that. “Wow, these guys have $100 of capacity and they are committing to only 50 percent of that. All this wasted money and time. What do I do about that”? Then, the reality is they probably were only going to get 50 percent of the capacity done anyway.

Clayton: Right. If they’re failing they might.

Roy: They commit to a whole bunch, but they only hit a percentage of that. Maybe it makes sense to…Maybe what they’re doing is not committing to less, but committing to exactly what they are capable of.

Consistency Can Be Valuable To A Product Owner

Clayton: If I’m the product owner and I’m working with a Scrum team or on the Scrum team, I would prefer for my purposes to have something that was a little more consistent. So rather than be lied to every week ‑‑ and not maliciously lied to, but rather than have some rosy optimistic outlook of what this sprint’s, “Everything should be great this time around.” ‑‑ I’d rather have the realistic thing. If that means going slower and…

Roy: But, you’re not really going slower, right? You’re just not promising to go as fast.

Clayton: It appears that I’m going slower.

Roy: Sure.

Clayton: If that’s the case, I’d rather have reality that makes my prediction stuff much easier. Then, I think, that’s another place where inspect and adapt comes in, where you can find ways or with the Scrum Master and whatever the team can improve, so that they can go faster hopefully. But whatever their pace is, that’s all I’m going to get. I would much rather know what the reality is.

Roy: I agree ‑‑ it makes it a lot easier to improve over time because if you commit to your full capacity, then you have to go from zero to 100 percent immediately, right?

You either fail your sprint or you hit your sprint. But, if you can slide that capacity down to what you can actually hit, then you can slowly move that up and you have much more opportunity for incremental growth, rather than an all or nothing thing. Then you can slowly work your way up to 100 percent.

Changing Commitment In The Middle Of A Sprint

Clayton: One more bonus question before we go. If a Scrum team has committed to 10 stories and it’s the last day of their sprint and they realize they are not going to get the last two things done, and they say, “Oh, Mr. Product Owner, we’re not going to get these three, two things done, can we take that out of the sprint”? If they took them out, will you count that as a success or failure?

Roy: I would count that as a failure because at the beginning of the iteration, they promised to get those things done. It’s a bit of a gray area, so if they realize on day one of the iteration that those two things weren’t going to get done, that would be totally different than if they realized 10 minutes before the demo.

Clayton: I’ve never seen that street go two ways. I’ve only seen it where the team asks if they can have things removed, but when they finish, I don’t ever think I’ve seen a team that says, “Bring it on. Give me more stuff. We can’t wait to get more things.”

Roy: I’ve seen both, but it definitely never happens at the beginning of the iteration that they say, “OK, give us more stuff.” Sometimes, towards the end, I’ve seen teams finish the iteration in half the time and then, pull in a little bit additional work…

Clayton: OK. That’s good.

Roy: …and demo that as well. Now, if they didn’t manage to accomplish all of the additional work before the demo, I would not consider that a failure.

Clayton: To me, that says topic for another episode. All right. Thanks.

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

Roy vandeWater: And I’m Roy vandeWater.

Pair Programming Not Scientific

Clayton: Today we’re talking about an article that we came across, it was this week. It’s called the “High Costs and Negative Value of Pair Programming” Original Taken DownHacker News Thread. It’s by Capers Jones at the Namcook Analytics blog, we’ll put that in the iTune net.

Basically, it’s, like a white paper almost, about why pair programming is harmful, and it’s not really a good idea, and you shouldn’t do it, or at least, you shouldn’t do it yet, until you do lots of research about it. It struck a chord, I guess. We came across the post on Twitter, and it kind of generated some buzz on there. Then, we talked about it internally, so we were hoping to share our ideas.

The first point that I thought was, that resonated with me was the author makes mention that pair programming is something that came out of the non‑scientific. It wasn’t measured very well in the Agile community. I would probably give him that, that the Agile community has lots of things that we do that are not necessarily based on hard scientific evidence, a lot of its just anecdotal experience. That’s probably a fair statement.

Roy: It becomes very difficult, too, though. I think we’ve had something that we’ve run into in the past, right? Where it becomes, because of the nature of every team being different, different projects being different, the codes bases being different, like a lot of the pair programming and not just pair programming, a lot of the types of practices that teams are experiencing with are very difficult to measure in a scientific way. It’s very difficult to have a control group that’s identical except for this one variable.

Clayton: The thing that was…while I agree with that general idea that the Agile community is very unscientific about how they measure things, I felt the way that they went on about, goes without measuring things in the article was kind of lame because they just made up a bunch of stuff and put it in Excel it seems like. I don’t know. My guess is you have to take a healthy grain of salt.

The Nature Of Organizational, Team and Work Variety Makes Data Collection Difficult

Roy: The thing that I thought was most interesting in the beginning is that the author tries to make the point that there are a lot of different scenarios about pair programming that were not considered in most cases. He goes through all these different examples of single programmers using static analysis versus expert single programmers compared to average pairs and novice pairs compared to all these ten different permutations of all these different things.

Which, I guess, there are probably not many organizations that have all of these things and they are only going to have two or three at most. I thought it was odd that you go so far out of your way to make a big point of not comparing all these things, especially when there probably isn’t a whole lot of opportunity to compare them all?

Static Analysis A Poor Benchmark

Clayton: I thought the static analysis bit was interesting because he specifically talks about the number of defects that a single programmer using static analysis produces versus two pair of programming produce. I think the ratio is something like a single programmer using static analysis develops one defect for every 15 that the pair programmers develop? I guess maybe I don’t understand what static analysis is, because I don’t understand. Do you mind explaining real quick?

Roy: The idea that static analysis is going to evaluate your code and find defects for you? I have written plenty of defects that static analysis wouldn’t have caught. There’re plenty of things that static analysis would tell you that wouldn’t be defect that you could spend a bunch of time fixing. That seems like it’s just a silly thing to even bring up.

Static analysis can be important and it can hint you in the right direction and help you find different things with your code. The idea that it’s like this great tool for finding defects or even a tool for finding defects seems like a stretch.

Moving on, another downside the author states for pair programming is that it won’t scale. The example that he gives is a huge software project with 500 engineers. How could you get them to pair? How could you hire another 500 more people? Which seems odd, because any software project that had 500 people working on the same thing that sounds like a nightmare, no matter what you’re doing.

Can Pair Programming Scale

Clayton: Right. Exactly. You are going to have so many people doing many random things and wasting a ton of time, even pair programming at that point when you have a project that big, it becomes unmanageable.

Roy: If it’s 500 people across an entire organization all working on different things, then you could still pair. There’s nothing that says you couldn’t, the idea that it wouldn’t scale? That seems kind of silly.

Clayton: That’s the mindset difference, right? Because he’s thinking from the perspective of “I have 500 people and I need to maintain my current productivity level, which means I have to hire 500 more.” Instead of saying, “I have 500 people and that means I have 250 pairs.”

Is Pair Programming Only For Developers

Roy: That’s a good point. Kind of the next thing that is the problem with pair programming is why hasn’t this been tried with other business functions or other job functions? They talk about architects and BAs and testers and all these other things which, if you talk to those who are actually doing pair programming, they have tried to do some form of pairing with people who are not just software developers.

This one stuck out to me as someone that has kind of betrayed the experience the author has with pair programming and the idea that no one has tried that before.

Blended Skill Sets Amplify Pair Programming Effectiveness

Clayton: In fact, in my experience, the biggest gains from pair programming come when you have the most different types of experiences combining. Say, you have a graphic designer and a programmer, or something like…as different as possible.

Because, if you put two people that are almost identical in front of a computer, the most you’re going to get out of it is maybe a slightly lower defect rate, because one of them is proofreading what the other one is writing.

But, if you have two people that have totally different ways of approaching the problem that gives the pair a greater diversity of options to choose from, and it makes it more likely that they might pick the right one.

Lines Of Code, The Bullshit Indicator

Roy: The thing that struck me as the biggest bullshit indicator of the whole article was that one of the measurements that’s used in this calculation is lines of code. The measurement is how fast is an expert single programmer, based on how many lines of code they write?

That’s what is used in all the economic calculations. I wouldn’t doubt that pair programming is probably more expensive, and probably slower, than single people working on things, but that’s entirely ignoring all the other benefits that you can get.

If you’re just doing lines of code, if you’re working on a software project that all that matters is that you’re just pumping out lines of code, then just hire a bunch of monkeys and they can just pound on the keyboard. You don’t need pair programming at that point.

It seemed like an odd comparison. I would even say that if your software project is so simple that you can just crank out lines of code, then you probably don’t get any benefit from pairing as far as collaboration, or redundancy or anything.

If Collaboration Doesn’t Matter, Outsource It

Clayton: You probably don’t get any benefit from collaboration of any form. You should probably just outsource, and try to get your code written as cheap as possible.

Roy: Right, because if all it really takes is that you just are pumping out code, then you can just replace that person with someone else, and it doesn’t matter. But, that’s not the case, I think, in most software organizations.

Clayton: I was going to say, how many projects are actually out there where you can just put anybody in front of it and pump out code?

Roy: A lot of people try and do that, especially, I would say, shops that are doing outsourced software development, where they’re solving the same problem multiple times. They probably do just have a set way of doing things, where they could get pretty close to just pumping things out, and it doesn’t really matter who’s working on it.

But, for most organizations that are developing either products for customers or developing products for internal customers, where there is a need for that collaboration and giving some creativity, and having that redundancy, so that you don’t have the single point of failure with the one person who knows everything…

Over Valuing Individual Experts

Clayton: That’s true. That’s one thing that’s not really acknowledged all that much. I believe one of the lines in that article states something about like, “If you look at the data in Table three, you can clearly see that the most efficient course of action is to hire a bunch of individual expert programmers.”

If you’ve followed many of our podcasts in the past, then you’ll know that that does not really fly very well with the way we like to work, and that that sets organizations up for failure, because you end up with all of these single point of failure where if any one of them…Each one is a link in the chain, and if anyone is gone, then the organization falls apart.

Roy: The single expert programmer is usually a hero and a cowboy. They are the ones that are going to stay up until 3:00 AM heroing some solution for some problem, and then they’re going to cowboy‑code their way…

Clayton: They’re pumping out lots of lines of code.

Roy: Yeah, exactly, and they’re going to cowboy‑code their way through everything else.

If you ask any IT hiring manager, the idea that you can just go pluck expert programmers off the street…which, to the author’s credit, he does make the point that that probably only makes up about 10 percent of the hiring pool that’s available, the programming talent.

I feel like that advice is…”You should only hire expert programmers” is like telling your little sister, “You should only date guys that are really nice to you, and that are financially secure, and that treat you with respect.” That’s not going to be everybody in the world. That’s probably not very good advice, right?

Clayton: I don’t want my sister dating everybody in the world, though.

Roy: I agree, but the idea that a hiring manager is just going to go out there and find some expert programmer and say, “Hey, we can solve all of our problems by hiring three of you, instead of having a few pairs.” That seems silly.

The Cost Of Poor Decisions Has To Be Factored In

Clayton: It’s short‑sighted, too, to think of things in terms of moving faster because you have a pair, because it’s a single person moving faster. If you have a single person making poor decisions, and maybe moving very quickly but creating this monstrosity that’s going to be impossible to maintain, sure, you’re moving faster for now, for the next few weeks.

But then, all of a sudden, when defects come in or change requirements come in or whatever, and you start needing to adapt the system to meet the new demand, that’s all of a sudden when things start to slow down, because you didn’t slow down to begin with.

Roy: Yeah. The way that the example is set up in the article, it’s very tipped in favor of the single programmer, and not in favor of a more, I would say, real‑world scenario, or at least a scenario that we see with our clients that have a dynamic application or a legacy system, or they’re trying to build a new product.

They need lots of creativity, and they need that collaboration, so that they can get lots of different ideas, and so that there’s the redundancy. Those are the things they need. They don’t need people just pumping out code.

Knowing What To Build Is The Biggest Problem

Clayton: That’s, I think, we see in almost every organization that I’ve ever worked with. The biggest problem has always been with figuring out what to build. Not building something quickly. Building something as fast as possible has never been the issue.

Roy: I would say the other thing, I think, that we see a lot is there are scenarios where saving money is a beneficial thing. I think this article comes from the standpoint, the fact that they bring it up in the very beginning, that Agile is sort of not very good with economics.

Or at least, that’s the claim they’re making. Drives to the point, I think, where all they really care about is the bottom line. Which, you know, I think if you spend enough time in the community you realize that going faster and more better, faster, cheaper. That line, which is, I think, how a lot of people view Agile, maybe Scrum especially.

Clayton: And Lean as well.

Roy: Especially with Scrum, if we can do Scrum, then our teams will be faster. They’ll be cheaper. They’ll be better or whatever. If that’s the only thing you’re driving for then I think this article is appealing to you. If all you care about are dollars and cents.

Clayton: Maybe Agile isn’t for you if you’re doing that.

Roy: Right, and that’s why I would say that you probably don’t even have the culture in your organization to support pair programming if all you care about is the bottom line. Because there’s no way you could look at a pair versus a single person and determine that, “Oh, the pair is more expensive, but that’s OK.”

That’s not going to be your mindset. You’re going to think of them as, “This pair is more expensive,” and you’re not going to see the benefits that you get from pair programming. So you’re just going to ignore out of hand which is who this article appeals to.

Economics Of Pair Programming Vs Value Of Pair Programming

Clayton: Actually, it’s a huge disparity between thinking of these things as just a set of processes and tips and tricks to try to make things more efficient or to make things better, rather than looking at it as a value system, where you are completely changing the way that the human beings within your organization interact.

Roy: You’re changing the way that people will write that software.

Clayton: Right.

The Fallacy Of Decision Making Slowing Us Down In Pair Programming

Roy: The closing point about divided work. I thought this was just another one to seem kind of ridiculous out of hand as well. I don’t think there’s anything that you could compare between pair programming, two people sitting down writing software like a software feature. I don’t think that’s comparable to military command whatsoever other than the fact that there are two people.

The idea that you would say, “Divided work can be harmful because look at these examples of things that don’t work.” They’re not the same thing. It’s apples and oranges at that point.

Clayton: Let’s look at it from the perspective of decision making ability, right? Where if you have two people sitting in front of a computer and they have to make a decision? They could potentially argue about it for half an hour to an hour. In the software development world, like arguing about something for half an hour to an hour is not big deal. But, I could understand in the military engagement that might be a huge problem.

Roy: Right. [indecipherable 13:04] means software is malleable, right?

Clayton: Right.

Roy: You and I could sit down and pair program and we could come up with some solution. Then, maybe we go away for the weekend, we talk to some friend and they mention something that triggers an idea. We can come back and change that. There’s nothing. You can’t change sending your tanks into battle, and you can’t just do over. There’s no undo.

Clayton: But, it is pretty common to see, especially large groups get crippled by shared indecision. It’s like everybody wants to go in a different direction.

I can definitely see that extending all the way down to pairs as well, where two people with fundamentally different mindsets want to go in different directions. But, I think that ends up being a much large organizational problem in that probably speaks towards a lack of shared vision for the project.

Because of everybody is on the same page where their project’s headed, then the implementation details of going one direction or another, if they’re both headed in the same way, it doesn’t become as much of an argument.

Roy: I’ve seen that on teams where pairs will have very…especially, if you get two people that are very strong willed. They will have very different ideas of how the system should be architected or whatever the case may be.

But, when the team doesn’t have trust and they don’t have collective code ownership with standards, that’s when you get people who say, “We should use this library.” Then, the other person says, “No, we should use that one,” when really it’s the team that should basically be figuring out, “When we have to solve this kind of problem, we’re going to do it this way.”

[crosstalk]

Roy: Once you get over that problem, and you say, I think a great example that we always have with the old Integrum was authentication stuff. There are 50 different ways you could do authentication and rails. We picked one and that was how we did authentication. That solved the problem of two people pairing and saying, “Well, my pet library that I think is really great is this one.”

Then, the other person saying, “No, no, no. We should do this way.” Then, it was you had two different ways in this project that were inconsistent with what the team thought was the standard, if you can get over those kinds of things. That’s how you can solve some of those problems that they might seem like problems with pairing, but I don’t think they really are.

Pair Programming May Highlight Organizational Dysfunction

Clayton: That’s true. I think every single one of the items you listed really speaks towards larger organizational problems that have absolutely nothing to do with pairing. Like if these are the things, if these are reasons why you don’t want to do pairing, then maybe you shouldn’t be doing pairing yet because your organization is not ready and your organization needs some significant changes before you do.

Roy: If you’re totally swayed by the economic argument, then you’re missing all the other benefits that you get. If that’s where you are then you’re not ready to be awesome. If I put my Derek hat on for a second, I would say, “It’s expensive and it’s difficult to be awesome and if you’re going to fall back on some excuse about how it’s too expensive with all these kind of bullshit calculators that you wrote in excel, then too bad. You don’t get a taste of the awesome.”

Clayton: Fair enough.

Roy: Thanks. See you next time.

Clayton: Bye‑bye.

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

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

1. Test Driven Development

Clayton: Today, we will be talking about the much talked about Seven Agile Best Practices That You Don’t Necessarily Need To Do article. If you haven’t read it, it’s on the Agile DZone. It’s called Seven Agile Best Practices That You Don’t Need To Follow by Jim Bird.

We’re going to talk a few minutes on each of these. First one is test‑driven development. That’s one that somehow became synonymous with Agile teams, that Agile teams do TDD. What do you guys think? Do you have to do TDD?

Derek: No.

Roy: Yeah, I’m going to say that.

Clayton: [laughs] Next. Let’s explore a little bit why that became so pervasive. Why does everyone thing that you have to do TDD if you’re doing Agile?

Derek: Because there is a difference between Agile and good. So it’s like if you want to be good, you have to do TDD. If you just want to be Agile, like, “Hey, you don’t need to do TDD.”

Roy: Also, there’s a huge feedback component to Agile, right? It’s all about quick iterations and getting feedback early. I think test driven development is the programming embodiment of that. It’s the idea of asking for feedback before you even start coding and then, gaining feedback as you code towards the failing test.

Clayton: Do you think it would be fair to say that you would have to do TDD if you were doing extreme programming?

Roy: Yeah.

Derek: Yes. I would say you would. I don’t remember his full arguments on this, but I think it comes down to studies say TDD is not as good. If you know what you’re doing, then TDD is good, but if you don’t know. The only time that I really say that TDD should be super optional would be if your start‑up, you’ve got a limited amount of money and you have to meet the next date and slow at TDD because you don’t know how to do it.

If you are competent with TDD, there is no reason not to do it. If you are going to be long‑term with a project, then there’s no reason not to do it.

Roy: So part of the argument also talks about that statistically there’s an increase in complexity with TDD, oftentimes in terms of design, which I’d have to make assumptions, but I’m assuming it’s based off of probably not knowing how to do TDD properly, like abusing the crap out of mocks and spies and all of those patterns, and creating tests that are really brutally coupled to the specific implementation.

Derek: It doubles the lines of code, so therefore, it’s got to be twice as complex.

Roy: Right, when people, when teams get…

2. Pair Programming

Clayton: Speaking of doubling, pair programming. Do you have to have two people working, do you have to do pairing if you’re on an Agile team?

Roy: No. I feel like you have to be doing some form of pairing, like it may not necessarily be pair programming. But like people working by themselves, that’s not a team. Like leave Agile alone. Like I feel like a bunch of people working by themselves in isolation is not a team. So I almost feel like there has to be a pairing component in terms of like pair‑planning or pair design or pair…

[crosstalk]

Clayton: So the only way you can do that is by pairing?

Roy: No. I suppose not. And I suppose they very specifically mean pair programming.

Derek: Yeah, because I go to a whole lot of planning meetings that aren’t paired but I think that the people there are co‑creating solutions together.

Roy: Sure.

Derek: Again that’s one to me just like TDDing. If you want to be good, you probably should pair. If you want to be Agile, you don’t have to pair.

Roy: Right. Some of the arguments are for the idea like, that some people don’t like to pair and some people will be slowed down by other people like that.

If I’m really good and Clayton sucks, [sarcastic] using a realistic example, [laughing] then what we would have is like Clayton would be slowing me down all of the time, which I think is kind of the wrong way to think of that, it’s like I’d be teaching Clayton some awesome new stuff that he doesn’t know yet… [crosstalk] …and that’s more important in the long run.

Clayton: They hit on or he hits on some of other common arguments about introverts versus extroverts and like smashing creativity and you won’t have time to be innovative and all that kind of thing.

Roy: Like you won’t have the opportunity to go heads down and really solve complex problems but arguably, if you’re pairing properly, you’re turning all your complex problems into simple ones and you don’t end up with those types of huge complex Rube Goldberg solutions.

Derek: I keep saying that you know the problem with exercising for me is that it leaves less time for eating ice cream and clearly this is a problem.

3. Emerging Design & Using Metaphors

Clayton: OK the next one is emerging design and metaphor. One thing I don’t think a lot of people especially kind of the new Agile crowd I don’t think they really have embraced metaphor at all. I don’t ever hear people talking about the importance of metaphor not now at least.

Derek: So I can’t speak without using metaphors, like I think you have to have metaphors to be Agile.

[crosstalk]

Roy: They have to be sports metaphors.

Derek: Not always but usually, just because sexual ones aren’t very you know reasonable to do at work. I will remember a conversation with Chet, I believe about this, and I think they kind of said that XP dropped the metaphor at some point, and I want to say that the reason they dropped it is because it’s too fucking hard to do. Which speaks volumes for the shit that’s really good is hard to do. I think that people throw away the stuff that’s hard to do first.

Clayton: Like BDD. If you look at that, and you talk about “Let’s have ubiquitous language, and let’s have a shared language.” That’s really difficult. And there are a lot of times where people can’t even think of a way to describe some part of the system, so they just throw it away. [crosstalk] They give it up.

Roy: Exactly. You almost put it in the box of the metaphor: “Well this doesn’t fit our metaphor, so I guess we can’t do it.”

Clayton: Right. One thing that he talks about in the article is changing the metaphor, or having to get rid of it, or being pigeonholed by it. If the metaphor is meaningful, I think you can make it work most of the time. If you need to change it, I think you can have a good reason to change it.

Roy: It’s interesting to pair this up with emergent design because I don’t necessarily put those two in the same box in my head. Emergent design, the idea being “I’m not going to design this entire thing up front. I’m going to be able to build on top of it as it goes on.”

Clayton: Then that’s some of the fallacy that in Agile you never talk about design. This is, in practice, not true. I think if you go to high‑performing Agile teams, they’re talking a lot about design. They just don’t do the huge design up front stuff. But, they don’t not talk about it.

Roy: And, it stays flexible the entire time, so nobody’s totally stuck on a particular interpretation…

Derek: [sarcastically] How are you going to grow your architecture e‑peen if you have emergent design? Now, come on.

Clayton: There you go.

[crosstalk]

Derek: I want to back on this one a little bit. Look at some of the most prolific onboarding applications of computer history. If you look at Twitter, if you look at Facebook, if you look at some of these companies that have gone from zero users to several hundred million users in a very short period of time, all of their architecture was created using emergent design from a standpoint of they didn’t know what they didn’t know.

I believe there’s an article on this. We’ll try to see if we can get it in the show notes. Twitter had done a ton of performance testing. They had done a ton of load. They had done a ton of stuff where they could deal with literally hundreds of thousands of follows per second happening on the system. What do you know? Ashton Kutcher goes on “David Letterman” and says, “I want to be the first person to a million followers. Everybody go follow me right now.”

Total edge case in, “Yes, we support a hundred thousand users following another user, but we don’t support a hundred thousand people following the same user in a one second time frame.”

How do you deal with those things that come up? You can’t cover every edge case, and I think continuous deployment has moved us to a point where what you’re really doing is saying, “We discover by the feedback the system gets us.” And, we’re able to adapt and deploy so continuously and so quickly, that it doesn’t feel like we have architecture problems. I think this is something that the old‑school, old guard just can’t deal with. It’s like, “No, but we have to get it right the first time!”

Roy: I kind of feel like if you don’t have some form of emergent design you are, by definition, not doing Agile.

Derek: You’re screwed!

Roy: Right? Because, other than the human relationship and that component of it, I feel like the ability to pivot and change your mind as you gain new information is the fundamental core.

4. Daily Stand-ups

Clayton: What about daily stand‑ups? Roy, you just mentioned the human component. Getting together and talking to other people on the team on a daily basis. Is that something you have to do?

Derek: Is that what they said? I don’t know the wording. To me, if they said “daily stand‑ups,” no, I don’t think daily stand‑ups are mandatory. Do I think the people on the team need to talk to each other at least one time throughout the day? Yes. I think that is necessary.

Clayton: To really nit‑pick, I think what they’re really getting at is, “Does everyone have to stand up?”

Roy: We didn’t. We did an entire episode on whether or not you should stand up during a stand‑up. We came to determine that yes, you should.

Derek: I think it goes back to “Do you want to be good, or do you want to be Agile?” I think you could be totally Agile without doing any kind of formal stand‑up. I think if you want to be good, it’s just like using a white board versus using a tool. Can you do things without using white board? Sure. But, you get some benefits from the other one that you don’t.

Roy: I’m guessing that part of this is driven through experiencing bad stand‑ups that are a waste of your time. Because just like any other meeting, you can screw this one up, and make it a total waste of everyone’s time. Where it’s just like a status report, and I go, “Yesterday, I did X, today I’m going to do Y, no blockers.” Nobody is listening to each other. You’re totally defeating the purpose.

Derek: I see another one too with a lot of teams that are co‑located and within the zone proximity. “We sit next to each other all day long and we pair, so why do we need a stand up? We’ve got a physical board. We sit next to each other. We talk to each other every day. Everybody already knows what everybody is doing. Why the hell do we need to do a stand up every day?”

Clayton: I think what’s funny is that most the time those people don’t actually know what is happening.

Derek: No, they don’t. I see that too.

5. Collective Code Ownership

Clayton: Speaking of everybody knowing everything, what about collective code ownership? Is the idea that everyone can work on any part of the system and everybody knows the system to some degree? Is that a reasonable thing? Or should you say, “It’s OK that Derek doesn’t know how to do this right.”

Derek: Some people are too dumb to work on parts of the system.

Roy: Right, they shouldn’t be allowed to work on parts of the system.

Derek: People won’t say that, but that’s what they’re saying when they say that. “Not everybody is as knowledgeable, not everybody is a god like me.”

Roy: Actually this article does say something specifically along those lines and not everybody should be allowed to modify parts of the system.

Clayton: I think what they’re getting at is it’s not realistic that that is the case. It isn’t realistic that everybody on the team can work on any part of the system. To me that sounds like, why is your system so complex?

Derek: What it sounds to me is why do you hire stupid fucking people? If you have people that you hired to code and you don’t let them go to certain parts of the code because they’re not competent to go to the code, why are they employed by you?

Clayton: That’s a good point.

Roy: Or if you don’t let them go into the code because the person that owns that code is extremely territorial over it, then why do you have that territorial person employed, and why are you letting them boss you around?

Derek: I don’t know if you could be Agile without having collective code ownership. The first time you have to say, “Sorry, Clayton is on vacation, I can’t really deal with this problem.” By default, you are not able to respond.

6. Writing All Requirements As User Stories

Clayton: That’s true. You couldn’t respond to that change right?

We’ve heard that user stories are a representation of a conversation. Why wouldn’t you write every requirement as a user story? Is it un‑Agile to have a requirement on the system that isn’t a user story?

Derek: This one I think they’re pretty in line with. I think that the multiple formulas that exist out there are really good. I think they help people write good, small parts of the system. I think somebody could go write one or two sentences on a board and still get stuff done just fine, if you have the conversation. I think the actual card and the conversation are far more important than the stories themselves.

Roy: One of the values of a user story is that it can’t give you enough information to substitute for a conversation. I can’t write a user story that tells you everything you need to know, so you have to come talk to me.

Clayton: They talk about using a use case, or a test case, or a wire frame, or something which they are great examples of things you can add on to a user story as you have that conversation, but I don’t think it’s an and/or. If you were to say that you didn’t write everything in user stories, I could see somebody getting a little crazy with writing too many use cases, and then you go off the deep end in that regard.

Roy: Right, and then before you know it you have a full spec outline ahead of time so that we don’t have to spend this entire time arguing with the developers and negotiating someone’s criteria.

Derek: You get off the rails pretty quick, right? If you don’t keep it nice and short then we start assume, “Oh Roy, you’ve got 80 pages of Cucumber specs for me.” So I don’t need to actually ask anything about the system.

Roy: It’s all here.

Derek: Clearly you’ve thought of everything, right?

7. Relying On a Product Owner

Clayton: The last one talks about relying a product owner. The single ringable neck and having one person that is supposed to be the gateway to the customer. If most Agile shops are doing some form of Agile are probably doing Scrum and they probably have a product owner. How did all the Agile people miss the boat on this one?

Roy: I kind of think it would be OK if there was more than one product owner. It doesn’t necessarily have to be a product owner as long as there is just one backlog. You still get into the problem of if you have this one backlog and you have two different people that are both your boss.

They’re arguing over what a specific story is supposed to be like. I can still see a ton of problems there. You have to have somebody that makes the final call. Somebody at the top of your organization has the authority to say this and not that.

Clayton: I think there’s a distinction between being the voice, the single point of contact with a customer and the person that makes decisions. Should the only person that ever talks to customers be one person and the product owner?

Probably not, and you should probably find lots of different ways to have that interaction and get that feedback. If you had more people talking to the customer and more people making decisions, I don’t think that’s what you would want.

Derek: This one is really odd for me in the sense of I’m starting to find that actually in some ways I believe that having a product owner is non Agile. Part of it is, I think that if a team, when I look at small startups and I see them do things with no product owner.

They really are doing things by committee. They really are doing things by unanimous decision. I think it’s because they have got strong vision, and they’re aligned. To me the need of having a product owner who is the one all that says, “I’m going to make the decisions so we can move forward.”

I think that’s almost a crutch that says that you’re not providing enough vision that the team is actually aligned behind the product, because if they were, you could get to a unanimous decision fairly quickly. You could be biased towards that action.

Roy: That’s a really interesting point. I hadn’t thought about it like that. The reason why we always think that you need a product owner is because you have dissenting viewpoints on which way to go.

That’s because tradition decision making is made by majority vote, in which case you have a bunch of people that aren’t happy. If you’re always unanimous, then you have a team that is acting as one anyway so it’s like it’s one single [inaudible 00:16:15] .

Derek: You probably have a much better product. To be clear, I think product ownership is very necessary is most organizations because they’re having to deal with them as a dysfunction to how they currently work. I think you could absolutely be on a highly Agile, adaptive, high performing team, and deliver great product, and not have a product owner.

Clayton: I think we’re out of time. Thanks guys!

Roy vandeWater: Hello, and welcome to another episode of the Agile Weekly Podcast. I’m Roy vandeWater.

Derek Neighbors: I’m Derek Neighbors.

Clayton Lengel‑Zigich: I am Clayton Lengel‑Zigich.

Standard Patterns Of Growth

Roy: Today we are talking about establishing a growth path within an Agile organization. The general idea that you have a bunch of employees within the organization that all want to improve themselves, or maybe don’t want to improve themselves. How do you show them what they can do to get better, and incentivize them to want to do those things?

Clayton: Do you mean like get a raise?

Roy: Sure, I think that’s the classic management 1.0 way of incentivizing people to get better.

Clayton: “I want to climb the ladder, so I can make more money.”

Roy: You start out as junior developer, you go to senior developer, then you become manager, then you eventually become a [indecipherable 00:52] level officer. Each one of those titles is associated with a salary band. I think that’s…

Clayton: Standard corporate stuff?

Roy: Very conventional. Then you have less people at the top, so it’s a standard pyramid structure. What else can you do?

Money As A Motivator

Clayton: I guess we should talk about money as a motivator. I think there’s some literature out there, and some studies that show for knowledge work, money is not a great motivator. There are probably some people who still associate money as a status thing, or titles as a status thing, so they want that thing.

Roy: That’s still the way that most businesses do it today, so I would definitely say the majority of people think that way.

Clayton: Would an Agile organization be somewhere that people are so engaged in the work that giving them a bump in their pay is not “Make it or break it” territory?

Roy: There are definitely studies that show that once you get beyond a certain salary range, I think I heard you talking about it, Clayton. I think you said 80K or so.

Clayton: I think that’s what is in Drive.

Roy: I’m sure that number may be different, it’s probably different for every person. But that beyond a certain salary range, people are much more motivated by the work they do, and the people they are surrounded with, and the environment in which they work, than they are by the actual salary.

If you look on the list of things that they look at, as far as making a decision to switch to a new job, it’s very low on the list. They need to make enough to survive, but other than living comfortably, they don’t really need all that much money. Most people aren’t choosing a new job to get rich. The people that do that become entrepreneurs.

The Free Market Dictates Something Different

Derek: I think some of the things you potentially limit is if you have good people somewhere else that you are trying to attract, the problem is if you say 60K or 70K, or whatever that number is, the number you care about, then as long as you provide meaningful awesome work, that’s great.

What if there’s this really great person but they’re making 130,000, and their mortgage and their car payments and everything total up to that? In order to attract that really good person now, that person has to sell their home, sell their house.

I think that if everybody was level set starting at zero, I absolutely think that that works. But how do you be competitive, and luring good talent, when other companies aren’t following that same suit? What happens? How do you deal with that?

Roy: I can understand what you’re saying there, but I think there’s a difference between trying to lure people over with your culture and then dropping the salary down, and matching their existing salary but then luring them over with the culture. What I’m saying what wouldn’t work is having a crappy culture but having an awesome salary, that’s better then what their making now.

Making Great Culture The Baseline

Derek: Yes, I agree with that. But I think one of the things that you start to do is, do managers start to have a conversation where they really talk about, “Hey let’s level set, and it’s really not about money, and let’s make the culture really awesome.” You make the culture really awesome and you start to set this baseline.

What happens when there’s an incredible employee that everybody wants on the team. Everything’s great, but now you’re going to pay that person twice what the current people are there because they can’t do it? There starts to become some issues.

I absolutely agree that throwing money at the problem to make existing employees more happy is not a path to being good.

If you’re paying someone 80K, and you’re giving them crappy work and they’re not doing what you want, and they’re not learning, and they’re not growing, giving them 90K is not going to make them happy, is not going to make them grow. It might bump them for a few months or a year, but then they’re going to be right back to where they were at.

But I think it’s sticky if you just start to say, “Oh we don’t need to pay anybody more than the base that Dan says, and then life is good from there.” I don’t think that’s a very realistic approach either.

A Better Path Of Career Advancement

Clayton: Getting back to your original question about growth, or career growth. I think you had talked about how do people advance, and we were talking about the corporate ladder.

What I’m wondering is, what could a manger or management team do to outline some things, like a better path? What could they do to set expectations so that people knew, “Hey, in order to level up, these are the things I’d have to do”?

Roy: I feel like those expectations and those things to level up need to come from the team, or need to be based in the reality of that organization. Just saying “I need you to work twice as much,” if there is no demand for that, that may not be realistic.

I feel like it needs to be very applicable to an individual team. Certain teams may value a certain type of behavior more than others.

Holding Yourself Accountable To Your Team

Derek: Let’s say that, as an organization, that you decide that technical excellence is very important. Would it be fair for someone to say, “Hey, if you want to level up, and be viewed as the next level in the organization,” that you would always demand technical excellence? Here are some different ways that you could show that that’s happening. Is that the kind of expectation or metric you could use?

Roy: I kind of agree with that, but like I said, I feel like if people feel they are holding themselves accountable to the team…I am a part of a team of so many people. As a team, we run into this problem, and as part of solving that problem, I need to get better technical excellence.

Let’s say we are a team that’s having huge problems with technical debt. Because I am passionate about the team, and I demand that my team does great work, I am going to have to become passionate about technical debt in order to make my team great. But if it’s not a problem, if technical debt’s not a problem, for whatever reason, then maybe I don’t need to be awesome at technical excellence.

That’s kind of where I am coming from. It’s applicable to the individual team, and the problems that they are facing.

Encouraging People To Learn

Derek: I think there’s a couple of problems, potentially, with that. One is you are saying that “I can impose on you that you have to grow, you don’t get a choice about that, but then it is your choice on what you can grow on.”

I’d say, “If it’s so important that I get to make all the choices, why do you get to make the choice whether I grow or not? What if I think I am really great, and I don’t care, and I don’t think that I need to grow to deliver this product? STFU.”

The only reason I bring it back to that is I think that what we’re really talking about is, “How do you encourage people to learn?” My answer to that largely is, “I don’t think you can.”

What I mean is, I think that you got growth‑minded people and you’ve got fixed‑mindset people. I think that the first thing that continuous learning organizations have to do is starting to say “We’re not going to waste our time with people who don’t want to learn.”

Converting People From Fixed Mindset to Growth Mindset

Roy: But you can convert people from fixed mindset into a growth mindset. I think that the best way to do that would be through the team, and have a team really be pushing for that type of behavior.

As a manager, I wouldn’t be encouraging people to learn. As a manager, I would be demanding greatness from a team, and the team would figure out a way to help Clayton learn whatever.

Derek: But wouldn’t it be fair for the team and say, “I don’t want to fart around with trying to make Clayton learn. I want to do this other really magnificent thing”?

Roy: Yeah, after they have tried to make Clayton learn.

Derek: But why? If you are going to totally give them the power to do what they want as a team, why can’t they just say “Because we don’t want Clayton on our team?”

Self Direction vs Self Organization

Roy: It’s too easy to cast away people that could potentially be great, just because nobody gives him a chance. It’s really easy to make the easy call of, “Oh, we just don’t want this person, because it’s really difficult dealing with their problems.”

Derek: I guess where I’m getting is, I think that what you’re saying is that there is a difference between self‑direction and self‑organization.

I think it’s totally OK for an organization to say, “We think, for our organization to be successful, people need to have these type of skills, or need to have these type of abilities, and that we’re going to chart your success how you’re getting to those.”

Earlier you were saying, “I don’t think you should chart what I should be growing towards, you should let me totally define that.”

Roy: I don’t think that’s what I intended to say. Maybe that’s what I communicated, but I think I failed to communicate, if that’s the case.

Lack Of Organizational Mindset

Derek: I think if you’re going to say you’re stuck with certain people, potentially, on your team, and you are stuck with that there is an expectation to learn, I think it’s OK to say “This is the expectation of what we expect you to learn, and that we can chart, do you have growth towards that?”

I think in a perfect world you’d say “Hey, you work with the people that you want to work with. If people are dragging you down, don’t work with them. You define how you want to grow, and what the best skill set is.” I just don’t think most organizations are mature, and have teams that are mature enough, to fully operate in that capacity.

Roy: That’s true. Most organizations aren’t even working in a capacity where any of the individuals of the team have the emotional maturity, or interactive tools, to deal with giving people feedback.

If I had a problem with somebody on the team I wouldn’t even know how to address that. Maybe the best thing I would know how to do is go to my manager and complain, and that’s it. Or maybe complain about it behind their back at the water cooler. But I don’t know how to actually deal with a problem.

Derek: I think we even did this at Integrum at one time, maybe if we can find it, we’ll post it. We listed out like, “Hey, to be a good Agile coach, what are all the skill sets that you need? What are the things you need to grow in?” and then like, “Hey, can we self‑assess ourselves to say, ‘Hey, if we’re looking at this, where am I deficient, where could I grow the most, and can I be deliberate?’ Can I do deliberate practice on how could I be better at coaching somebody?”

Roy: Even in that, I remember when we did that exercise, we ran into some specific technical issues, implementation details that didn’t work out for us.

Derek: I guess that’s part of [indecipherable 10:55] . I think this is really difficult stuff to do.

Simple Rules

Clayton: Derek, you’d mentioned the concept of simple rules. I think it was from…What’s that podcast?

Derek: “Partnerships and possibilities.”

Clayton: You mentioned simple rules, the idea of having very simple things. I like the idea of saying, “To be a certain level of senior software developer,” maybe, “You value openness,” or something.

I think there’s a lot of different Agile frameworks and different things out there that would list, say five, six values that are pretty easy to adopt. Something like openness seems very simple, and there’s probably a lot of different ways that most people do not practice being open or transparent.

I think that’s a very easy indicator, where you could say, “What behaviors have you changed, or what behaviors have you adopted, that show that you value openness?” Those are the kind of things that you would want to drive towards.

As far as growing on the team or in the organization, if you had a list of those kind of things, it seems like it would be fairly easy for individuals to pick those things, and decide which ones they think. Maybe they would need some help with the self‑assessment part, or becoming self‑aware about how good or bad they are at those things.

Roy: It’s funny you should mention that as a specific example, because actually I had a discussion earlier today about openness. The problem that the team was having was, they have individuals on the team that are braided by the rest of the team whenever they make a mistake, and that those types of mistakes are never forgotten or let go, it’s constantly being brought up.

In this case, estimating for example, they estimated higher than everybody else. It’s like, “Oh, look at this person who doesn’t have any experience and estimated higher than everybody else.” Now, they’re afraid to make any estimates at all unless they look at the team to see what the team has done first.

Making fun of that didn’t allow for the openness, but I don’t think the team is even in this point where they realize that their behavior caused this non‑opened culture. They probably think, “We totally criticized him, and that was nice and open, and we know how he feels about it.” They didn’t realize that they shut down the very thing that they claimed to probably have tried to create.

How Much Effort To Waste Before Giving Up

Clayton: Derek, in your example where the team would decide, “Hey, I don’t want to help this person try and learn anymore, I don’t want to make them learn anymore.” In a situation like that, how much effort would they have to put in before they said, “This person just doesn’t want to learn, so I’m not going to waste my time.”

Derek: I think that’s the organization’s call. I think it’s either you give people the power to say who’s on and off their team, or you give people and say, “Hey, here’s your team, and you guys need to learn how to work together as a team.”

I don’t think there is a right or wrong to that. I think there’s pitfalls to both sides, and if you’ve got somewhat immature people on teams, it gets really petty that you are just swapping people from team to team.

You’ve got somebody who doesn’t have skills, who doesn’t want to learn, so they go from one team to the next team, to the next team. Maybe they are a reasonable potential talent, but nobody’s mentoring them, or giving the time. I think there is some danger in there unless you’ve got some mature organizational pieces, but I think it could go either way.

Roy: I think we’re about out of time, so thank you for joining us. If you have any opinions, please join us on the Facebook page, at facebook.com/agileweekly. We’d love to hear what you think about this. Thanks, bye bye.

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

Jade Meskill: I’m Jade Meskill.

Roy vandeWater: I’m Roy vandeWater.

Clayton: Joining us today is David Foster. Say, “Hi, David.”

David Foster: Hi.

Jade: No, say, “Hi David.”

Roy: Hi, David.

Clayton: All right, good job.

[laughter]

What It Means To Be A Senior Developer From A Manager’s Point Of View

Clayton: As usual, it’s guest choice for the topic. We wanted to talk a little bit about what it means to be a senior developer, and maybe even more specifically from a manager’s point of view. How do you define those things, and what’s the whole process?

David, this is something that you’ve been working with for a little bit now. Can you explain where you are, and what struggles you’ve had so far?

David: There’s three development managers in our organization, and we’ve been working on this for the last several months.

We recently transitioned from an organization that was definitely more hierarchically driven. We wanted to be able to move into more of a management stance where we’re actually empowering the teams, and letting the teams make decisions on their own. Which of course calls into question, what is our role as managers?

We look at it as if the teams’ products are the software that they’re actually building and delivering for the product owners, then our product is actually the teams themselves. What would be our responsibility in helping the teams to be better teams?

We decided that one of the things that we could do was try and set a vision for what we saw as being the kind of characteristics that a senior developer should have on a team. A “Senior” being defined as somebody that would help with the growth of the team, help with the creation of the team, and making sure that the team is running well, as a team. They would be a lead, in that respect.

Titles Are Stupid

Clayton: I think some people would say, “Titles are stupid,” and, “Why do you need a senior developer role?” What do you say to that?

David: I would probably agree with that, from the perspective of having an organization that is completely run by titles, where you’re just pigeonholing people into some position and role, based on what you’ve hired them for.

We definitely want to have teams where the teams can organize themselves, according to whatever the context is that they find themselves. What is the problem that they are trying to solve?

In order to distill that into what we’re looking for, the criteria we came up with were really more along the lines of the kinds of things that we would expect to see from an Agile team member.

Not so much somebody who’s just a senior developer, as defined by typical enterprise cultures these days, where it’s defined by the kinds of things that they do from a skill perspective, and the kinds of things that they do from the coding perspective. These are really more of the kinds of skills that we would see in an Agile team.

Loyalty And Length Of Service

Roy: What about loyalty? I feel like the title of “Senior” is oftentimes a reward for loyalty. Like, “I’ve been with this company five years. Shouldn’t I get some recognition for that?”

David: Yeah, that’s basically what we find ourselves with in the company structure, because the company definitely has that, from an HR perspective. They definitely have that, where the actual salary is banded to a specific kind of a title.

There’s a senior‑level band, and that has a salary range that’s associated with it. If you want to actually progress according to the company’s HR department, then you have to be able to fit within these bands. That’s kind of a constraint that we had as a management team.

We want to be able to have a fairly flat hierarchy, where we’re not really telling the teams what to do. We’re not really acting in the traditional role of a manager, the teams can decide for themselves. But we still have to be able to help them along with a career path within this organization that is still hierarchical.

Impact Of Not Having Hierarchy

Clayton: Jade, I was going to ask you. We’ve never really had a big hierarchical situation, or really big on titles at all. Do you think that ever had a negative impact with Integrum?

Jade: It’s something that we’d discussed a lot when we were first starting the company. We tried really hard to map people into all these different levels. It just got so confusing and so hard that we decided to throw it out the window and say, “Who needs this crap? We’re going to do this totally differently.”

As far as did it cause any problems with the organization? I think it caused problems with individuals who are looking for that recognition. Either they wanted it on their resume or for their ego, or whatever it is, they wanted to be called a “Senior Developer.”

As from the actual organization standpoint, I don’t think it caused us any problems. You guys were there. What do you think?

Roy: I remember interacting with a few people while I was still in the intern, and that I was at first somewhat treated a little bit as an intern, and then there was somebody else who considered themselves a “Junior Developer.” I don’t think anybody in the organization would have said, “Oh, this title is ‘Junior Developer.’”

I remember that being kind of interesting, because I remember acting not like an intern, and it very quickly stopped. I was no longer treated like an intern. I still had the lack of knowledge. I had the amount of knowledge as an intern, I just acted a little bit more confidently.

I think that was interesting to see, that he was still stuck in the “Junior Developer” role, and couldn’t get himself out of that, to step out. I don’t know, Jade. I think you know who I’m talking about. Did he actually have…

Jade: Is this the person that became our senior intern?

Roy: Yes, that’s right.

Jade: [laughs]

Falling Into The Prison Of Your Assigned Title

Roy: Was that a self‑assigned title?

Jade: Yeah, very much so. I think he mentally assumed the role of intern, instead of imagining himself as coequal with the rest of his team.

Roy: Because I see that as one of the big problems with titles, is you put yourself in the box. David, we’ve had this interaction with a few different people, where somebody says “This is my title. I shouldn’t be doing this other stuff. Even though I am passionate about it, and I think it should be done, that’s not me, that’s not my title. I shouldn’t be doing that.”

David: Yes, we were definitely running into that. We know that by actually going this route, which is a complete change from what existed before, that there’s going to definitely be a major friction created by this.

We expect that we’re going to have people that are going to just be completely uncomfortable by this, because when we actually show these criteria that we would expect from one of these developers, they’re not oriented along the ways that they’re used to. “I just want a check list.” It’s not going to be like that.

It’s really going to be “These are the kinds of things we’re looking for out of a senior‑level developer, and we expect you to figure out, and set your own goals, for how you’re actually going to achieve these things that you may be lacking.” That is definitely different.

We don’t really know what that means, in terms of how many people are going to be uncomfortable with that. But just like you said, Roy, we’ve had some people that have already butted up against that.

“We’re empowering you to make decisions, we’re empowering you to find solutions for yourself,” and there are people that are really uncomfortable with stepping out of their box, their prescribed box that they’ve been given. It’s definitely going to create some friction.

Having A Roadmap To Progression Helps With Self-Awareness

David: I’ve worked in jobs that have a traditional hierarchical organization, and one thing that was nice about having all those hierarchies was that you knew what was expected to go to the next thing.

Sometimes it was very cut and dried, and I think that’s one thing that’s difficult if you have a very flat structure. It’s hard to know what you need to do to improve. Most people I don’t think have the self‑awareness to realize where they’re deficient, or where they maybe could be more valuable, if they were to do certain things.

I think that’s something, at least the stuff that you’ve been talking about so far, that I’ve liked about the way you guys are trying to define what it means to be a senior developer. It’s that those things are very tangible things that I think you could grow towards.

If you looked at one of the requirements and said “I don’t really understand what it means to do X, Y, Z,” I think you and the rest of the management team could say, “Here are some more fine‑grained details about what it means to do those things.” I think that could be very helpful for people who want to actually grow in their career.

Roy: I think it’s important, though, that there aren’t step‑by‑step instructions. Because if you have step‑by‑step instructions, anybody could follow it. At first that sounds like a good thing, but part of what you’re looking for, as somebody who is in a lead position, or whatever, is a mindset and a self‑awareness that you can’t get.

If you tell somebody, “Just do the grind. Follow these steps. Kill 300 boars in the forest and you’ll be level 12, then we’ll give you your salary increase.” That shows that somebody’s willing to throw themselves against a wall for however long, but that doesn’t necessarily show that they have self‑awareness, and leadership ability, and an understanding of what’s going on.

That insight to be able to figure out how to personally improve themselves towards these values is very important.

Personal Improvement In Relation To Compensation

Jade: How is personal improvement tied to compensation?

David: Difficultly. At a very high level, what we’re looking at is…We don’t really have any junior developers, we really have senior‑level developers and then we have mid‑level and then we have what are called “Principals,” which are above a senior‑level developer.

Roy: When you’re talking about these titles, you’re talking about people who have these titles, or people who actually fit these roles?

David: I would say that people that are in those titles, that are in those job bands. I would not say that these are people that are actually necessarily in those roles, as we’re trying to define them now.

A mid‑level would be somebody who’s…In general it’s somebody who’s a really good member of the team. They’re definitely a contributing member of the team, they definitely work well with the team, and they’re learning how to be a more productive member of a team environment.

The senior would be somebody who’s actually able to help the team grow. They’re helping to nurture the team, they’re helping to grow the team, working with the product management, or the product owner, to really help make the team be more productive.

Then they’re able to, perhaps even go and create a new team, start a new team. We take an individual that is actually operating at a senior level and actually say “OK, we’re going to build a new team around you, because you definitely understand those principles.”

A principal would be somebody who would be helping to foster the creation of maybe multiple teams. That’s kind of how we’re looking at that. Compensation would be tied probably more towards those levels of activities.

Multiple Skillsets Necessary To Build Strong Teams

Jade: So what happens if you come across someone who’s really great at getting the team to be cohesive, to be effective, but they’re not strong technically?

David: That is a team problem, and we would expect a team to try and figure that out. How they figure that out we’re not really sure, because we haven’t had a team empowered yet enough to actually address that.

We definitely have that problem with some of the teams, but the teams have to be able to ferret out what that means to them. Do they want to just shelter somebody and keep them going along, or do they want to actually confront the issue and actually make some changes?

Jade: What if it’s not important that they’re strong technically, the team’s good enough to take care of that? They’re really great at getting people to work together and assemble and do all the things that you need to do?

Roy: That sounds valuable me. It sounds to me like if the team feels that this person is contributing a ton of value, maybe they don’t have that much technical experience, maybe they should be made aware and know that that’s an area of improvement.

Trying Things Differently Is Hard On The Organization

David: I think the personal performance, and performance reviews and all that stuff, there are people that are maybe exploring, self‑organizing teams, or doing things differently, or having a flatter organizational structure.

It’s the same thing with facilities. You’re trying to do all this new stuff, and then you go to HR and they are operating in a much different capacity. For as much as I think the Agile community tries to shoehorn Agile stuff into HR, maybe it just doesn’t fit.

This example you’re giving, Jade, think that is a totally reasonable thing. Why wouldn’t you be able to set the compensation or to have the person on the team? I think the answer is because they don’t fit into “Software developer level one, tier three” category, so you don’t know how much to pay them.

You are trying to use this antiquated system to figure all this stuff out, and maybe you should just not worry about that, but that’s hard to do. You can’t just tell facilities, “I’m going to kick down the cube walls,” because someone’s going to freak out. That’s not how they operate.

Jade: I think it’s a big challenge. Especially as we look at compensation, individual compensation has direct repercussions on your behavior on a team. It gets very complicated very quickly, as you start to muddle those things together.

Roy: It gets really weird too, because sometimes you think you are rewarding a good behavior. You’re rewarding a good outcome, that can lead to some really bad behaviors.

Salary Disclosure Is Taboo

David: The most radical example of fixing that problem would be where the team has some salary budget, and you basically just tell the team “Here’s you’re budget, and you divide it amongst yourselves.”

Jade: Yeah, there’s people that do that.

David: Which is a very scary thing. Even for smaller organizations, that usually doesn’t fly. I think when it comes to payroll and compensation, those things are so stuck in the old way of doing things.

Roy: Very taboo.

David: Yeah exactly, it’s taboo. Can you imagine if you took the average kind of corporate Scrum team, even if they were a pretty good self‑organizing team, and you said, “Here’s everyone’s salary, and feel free to move everyone up and down the slider, according to where the team thinks they are.” I can’t even imagine doing that.

Jade: We’re pretty progressive and pretty crazy, and we have not even touched that issue.

Roy: Every time we talked about bringing it up, we keep switching over to something else. It’s crazy too, because from a logical perspective it doesn’t even make sense.

The idea, and I don’t know if it’s an American culture thing or a world culture thing, but you are never supposed to talk about how much you make, and you are never supposed to bring that up with other people. You’re not supposed to know how much other people make, and if you do find out, you keep it to…Why is that such a cultural thing?

Jade: That sounds like another topic. [laughs]

Roy: Fair enough.

Humans Act Irrationally On Some Of These Topics

Clayton: It underscores the fact that some of this stuff gets int territory where we don’t act super‑rationally about things, which makes it even harder.

I think we are about out of time. David, did you have any parting thoughts, or anything you’d like to leave behind? If there’s another person in your position who’s considering doing something, did you have any advice for that person?

David: The simplest advice I could give is just figure out a way to get yourself out of the mix with the teams. It’s a really hard thing, as a manager, to want to go in and mess with things and to toy with things. The sooner you can get yourself out of that, the better off the teams will be, and being able to perform.

Clayton: Great, thanks.

Roy: Thanks.

David: Thank you.

Clayton Lengel-Zigich: Welcome to another episode of the Agile weekly podcast I am Clayton Lengel-Zigich.

Roy vandeWater: And I am Roy vandeWater.

What Does It Mean To Revisit A Decision

Clayton: Today we are going to be talking about the churn of revisiting decisions. I guess by that, what do we really mean, Roy?

We mean a team makes a decision about maybe how to implement something or some approach of solving some problem. Then maybe even after the fact it gets, I guess, revisited or gets talked about again and kind of the impacts…Does that sound about right?

Roy: Yeah.

Clayton: An example that we actually both saw this week was a story got demoed to the product owner kind of informally and it got accepted. After the story got accepted, and actually on the board physically moved over to done, with the green pin, and the whole nine yards, someone on the team kind of started objecting about “well we really should have done it this way, and I wasn’t involved, and something, something, something.” What was that impact of that on the team, do you think?

Roy: It felt really odd, because the team had made the decision to move forward in a particular way, and I think we kind of have agreed, probably not explicitly, but kind of agreed as a team, implicitly, that if you’re not there, then you’re going to kind of abide by the teams decisions.

It sounded like this person wasn’t present when some decision was made, and when they got back, the story had gotten accepted and they’re like “well we could have it this other way,” and the team’s like “OK, yeah it could have gotten done this other way, but it’s done now, so why would we spend more time on it.” We delivered a value we set out to deliver and if it becomes a problem, we can revisit that decision.

When There Is New Information

Clayton: I see people revisit those kinds of choices when they make a decision based on the information they have at a certain time, and then they get more information later, and then they want to re‑hash it again. I think maybe what you’re getting at is: hey, we finished it, it’s done, we delivered some value, let’s just move on. Do you think there’s still room for learning new information, and fixing it, or making it better?

Roy: There’s absolutely room for learning new information. Learning new information is always better, because it allows you to make better decisions moving forward. That’s the whole reason why we have retrospectives.

I definitely think that, like in this type of situation where if it becomes a problem, we’ll totally revisit it and we might choose to solve it in a totally different way, since we now have newer information. Just because you have newer information, you have to be careful about whether or not the cost is worth the value that you’re going to get out of it. In this case, some features delivered that provide some value x.

That feature could be rebuilt in a way that either reduces technical debt or whatever, but if rebuilding it, still only allows it to deliver value x, you have two choices. One that has zero cost, which his leave it like it is. One that has a significant cost.

It’s going to take some amount of time in order to build it, but delivers the same value. If you look at it from that perspective, it makes sense to go with one that’s got zero cost.

The Cost Of Re-Work

Clayton: Do you think that an argument could be made that “It really doesn’t have zero cost because now we know something new. Now that we know this new thing that changes how we would’ve done it and we would do it so much better this time”? Is that the motivation you think that a lot of times decisions get revisited?

Roy: I can understand why that would be a motivation for a why a decision gets revisited. But I would say like, “Great! You learned a whole bunch of new stuff. That’s going to be awesome. The feature’s that we’re building moving forward. Let’s build those because we don’t have a shortage of work to do.”

Nobody has that problem. People who have that problem don’t have jobs anymore.

Clayton: [laughs] Do you think that some of this conversation comes back to the simplest possible solution where you’re trying to do just the simplest thing you can do, which is often times very difficult to do the simplest, to deliver whatever that value is?

Because that sometimes when you’re making those choices about what the simplest thing to do is, you maybe make trade‑offs or maybe you don’t get a lot of consensus?

The Trade Off’s Of Technical Debt

Roy: I think Derek’s actually been…I don’t know if he said it on the podcast before but I know that he’s definitely said to me in conversations before as saying like, ” A team that is not creating any technical debt while they’re moving forward is probably not a high‑performing team.

A high‑performing team would be moving quickly and making the trade‑off of sometimes accruing some technical debt that they know they’ll have to pay off later in exchange for increased performance.”

Clayton: That would be more calculated debt, not the big bottle of mess that…

Roy: Right, exactly. It’s the type of debt that an investor goes into. Not the type of debt that a…

Clayton: You get from running up your credit card buying stuff.

Roy: Right. Exactly. Right.

Decider Protocol To Make Decisions

Clayton: One of things that’s in the protocols that we like a lot. We like to use decider to make decisions as a team. If you have new information later, you basically support the best idea that exists at the time.

You have to have the faith in your team that they’re going to support the best idea. You can always come back and make a new proposal to change things but you would never revisit something. You would always be doing it in the spirit of moving forward.

Roy: Well, the commitments, you are to support the best idea at the time, right? Regardless of where it came from or what it is, but while that’s the case, you will also always continue to seek to improve that idea or find a better one.

Clayton: If you find a better idea, great, but your situation changes as well. You are no longer in the same green field state at the end of the course of the decision, right? Like in our example, you’re no longer at that same state where you haven’t built this feature yet. You now have something.

That changes the scope of your decision. You can’t think of it in the exact same mindset as before you started it.

Roy: Do you think if you’re using the decider because of the format for the decider protocol and the way that it is basically so structured to deliver that consensus, you never really are revisiting things because you are always making a new proposal to improve? Is that kind of what you’re getting at, I guess?

Clayton: Yes, it is, but I have definitely found myself, in certain cases, with the decider feeling myself a little bit conflicted, because I felt like I had a better idea that completely against the previous Decider and as part of accepting, thumbs‑upping or glad‑handing a decider, you promise not to sabotage the decision.

Sometimes, I feel like I’m sabotaging the decision when in reality I’m actually proposing a better one. Like I’m not really sabotaging it because everybody else on the team has the opportunity to thumbs‑down it, right?

I’m just presenting the time with an alternative choice.

Avoiding Decisions Until Certain People Are Present

Roy: I think, everyone can probably think of somebody that they work with on their team that has a tendency to maybe revisit things or revisit decisions, especially ones that they were not part of. Do you think that’s something that a team should really be concerned about?

If there are people on the team that are always bringing kind of the old, decided stuff, should they go out of their way to avoid making decisions until that person is there?

Clayton: No. I think if you’re, see I’ve been thinking about this because I’ve been experiencing something very similar, and I think what is important is that if you are not present at the time the decision is made and you come back and you have some additional information, you have the responsibility to disclose what you know.

Then, it is up to the team to choose whether or not to revisit that decision. I would say it would be good for like you to make a decision, me not to know about it, come back, find out and then, say like, “Oh Clayton, by the way, were you aware of this?” Give you some information.

What would not be acceptable, though, is me pushing the agenda and the opinion I have. I wouldn’t be like, “Clayton, you are doing it wrong. We need to do it this other way. Let’s undo your decision and do it my way instead.”

That’s a totally different message than, “Here’s some new information, what would you like to do with it?”

The Emotional Needs In Decision Making

Roy: I guess, I feel like the reason that people, there is turnaround like revisiting decisions, or at least the intent, most of the time is the people who will want to revisit things aren’t doing it just for the sake of conversation or they’re genuinely curious about why the decision was made.

A lot of times, I think, they think that there are some drastic, like the train’s going to go off the tracks if I don’t step in and tell them this new information. A lot of times, I think, that’s why it’s so difficult to have those conversations because it’s not from necessarily like a rational, “Let’s move things forward.”

It’s from a, “Everything’s going to fall apart, unless you listen to me and we talk about all the reasons why you made that decision all over again.”

Critical Missing Information

Clayton: Yeah, it’s a difficult situation to be in. I can understand that emotional need and sometimes I think I may even be a legitimate thing, right? Like you might actually have mission critical information where you know the train is going to get derailed, but it’s really tricky on a personal level to make that determination.

Roy: Do you think in a situation where there was something that was kind of extreme like that, would it be appropriate for a team member to come back and say, “Hey, I know you guys decided that without me and even we decided that we were going to do this way, but I know this new information, X, Y, Z, I think we need to re‑decide. We need to revisit it”?

Clayton: I don’t know if it’s like a revisiting decider or it’s like a, “Hey, here’s some new information. I propose we revisit this decision. One, two, three and then, you can just throw it aside on whether or not to.”

Roy: Even if they weren’t, the team wasn’t trying to use the core protocols. you were just making a proposal. But, for us teams that aren’t using the core protocols, it seems maybe it’s a fine line between when it’s appropriate to revisit it and when it isn’t.

Clayton: I think if you have mission critical information and you bring it up and the rest of the team hears it and they don’t say, “Oh, you’re absolutely right. We did not consider that. Let’s revisit this decision,” then it’s not important enough to revisit the decision.

However important you think it might be, right? I think you’re going to have to lean on the knowledge of the team. Where if the entire team hears this piece of information and decides it’s not important, it’s not important.

Length Of Feedback Loops On Decisions

Roy: I think another aspect of this whole thing is the feedback loops like how long or short they are. In a situation where maybe there’s like a more senior developer on the team that has more experience using some technology.

The team gets a story about doing something with that technology and nobody really knows how it works, and maybe they don’t implement it correctly or they make some bad choices about that. I think the tendency of this more senior person is to come back and say, “Hey, you guys did it wrong. You really should have done it this way.”

But if you had a shorter feedback cycle, maybe if you’re doing it at a one‑week iteration, would it be OK if you said, “Hey, you know what, I wasn’t here. The decision was made to do it this way. It would be too much work to go back and totally change it. It’s already almost done. Let’s finish it up and then, we can maybe next week or the next iteration, we could revisit it”?

Clayton: I don’t even think that’s necessary. I think that’s more like, “Hey, I just want you guys to know like this is how I would have done it. I totally understand why you guys did it, but in the future when it’s this type of thing, I have some vast experience. Try to include me in the decision. I’ll do what I can to be available for that.”

Roy: You’re saying that you’d…trying to include yourself in the future decisions about that thing, but not really worry about, “Hey, what’s done is done.” You’re not going to worry about it.

Clayton: It’s kind of like a signaling thing. I am offering myself as a repositor of information on the subject, right? Like whether or not I actually know anything about it.

Then, giving those people the choice to use it.

How To Stop Revisiting Decisions

Roy: As far as like minimizing that type of turn or I guess on decisions that are being revisited, is that just a matter of stopping that behavior? Should the team just not accept the fact or they shouldn’t accept anyone revisiting things?

Or does it make sense to have more of a formal structure for making decisions? Everyone has a framework for coming back to the team with information.

Clayton: I think, as far as making decisions, decider is a great way to go, so there’s your structure framework right there. It provides, like you mentioned, avenues for revisiting the decisions because you through out a new proposal.

If you want a framework, it’s there. I think the deep root of the problem is if you have people that are continually not there. That, to me, signifies a huge problem.

If you have a team that’s working together on a commitment, they should be continually working together on a commitment, right? They should all be present and engaged most of the time.

I understand that there are some exceptions. I think that most teams that think they are ‑‑ the ‑‑ exception, really are just making excuses and probably should be together more often.

Presence Prevents Revisiting Decisions

Roy: Component would be just like the presence of everybody on the team…

Clayton: Right.

Roy: …with each other.

Clayton: If everybody is there, then you don’t have to worry about revisiting a decision. You might still gain new information, right? That still needs to be brought up, but new information is based off a decision that the entire team made, right?

It’s a little bit different. Then, it’s not a, “Hey, I wasn’t included and I want a part of this, too.” It’s a, “I was included. We made the best decision as a team. I was part of that. I take as much responsibility as you guys for this decision, but we just found out something that forces us to revisit it.”

Roy: Do you think that a team that is working on like a Scrum format or that have the dedicated planning meeting in the beginning of the sprint, do you think that they could avoid some of this stuff if they spent more time trying to decide exactly how the implementation would work during the planning period versus being a little more vague at that time and then letting people figure it out as they go?

Clayton: I think that’s totally up to the team and it has to do with trust levels on the team. I think that a team that’s initially forming needs to be very specific about how they actually implement different things.

But that specificity is going to start building the trust and start building the idea of, “This is the way our team does things.” The team gathers around this culture. “This is the way we solve problems.”

Then, over time as the trust builds, you can start back off on the specificness because now everybody knows the way the team does things. Like if I’m working with somebody I’ve worked with for two years, I can something vague, “Like we need to make a log‑in page,” right?

But if I’m working, whatever the job is…but if I’m working with somebody that is I’ve just met for the first time yesterday, we’re going to have to get a lot more specific.

Roy: Coming to a conclusion, maybe revisiting things isn’t always bad. You should always disclose new information you have to team. Using a decider is a good way to make decisions so that you have a framework for making changes to those decisions, I guess.

Clayton: Right.

Roy: Maybe spending the appropriate amount of planning, based on how much the team has standards, I guess, for the work that they’re doing. Sounded all right?

Clayton: Yep. I think that’s it. Thanks for it.

Roy: Thank you.

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

Derek Neighbors: I’m Derek Neighbors.

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

Roy VanDeWater: And I’m Roy VanDeWater.

Finding Yourself In A Not Ideal Situation

Jade: Guys, we wanted to talk about what happens when you find yourself in the less than ideal situation.

Roy: That’s never happened to me.

Jade: You’re always in the ideal situation?

Roy: Yeah.

Facilities Preventing Team From Sitting Together

Jade: That’s good for you. For the rest of you, who aren’t as awesome as Roy, let’s start with a hypothetical situation, in that you’re working with a team where the facilities prevents them from actually sitting and working together. Just the way it’s set up, the way people are distributed, everything. They just can’t physically be together. They’re in the same building, but they can’t physically sit together.

Derek: Is that when it’s time to work from the library or at a local coffee shop? It seems to me you can take a non‑ideal situation and make it into an ideal one. I feel a self‑organizing team shouldn’t let facilities get in their way. If a team is producing results and making it difficult for facilities, I don’t think any management out there is going to be, “No, no. We really got to break up this team. Even though they’re performing, facilities is more important.”

Clayton: I think that’s the interesting thing about facilities. You have the entire org structure that the team is under. Then there is always somebody else that’s entirely separate that is almost never in that building that is in charge of the facilities people.

The idea that there’s this bigger group working together to solve some goal of, “Our teams need a place to work together. They need to be able to sit together.” You’d be able to go talk to the facilities people and say, “How can we make this work?” That never happens.

The teams complain about not being able to sit together. The facilities people say, “Hey, man, I’m just doing my job. I got to keep track of all these desks and cubes.” It always seems to get in the way.

Hacking Your Way To Proximity

Derek: I think there’s a couple of things. One, is you can hack your way through. I think that’s what you’re talking about, Roy. We can’t figure it out, let’s go steal a conference room. Let’s go somewhere else. We’re not going to let somebody stop what we’re doing.

I think that’s pretty practical most of the time. Except for when you have to be on the network. You can’t go to the library because you don’t have VPN access, or something to the network.

Jade: Or you’re doing something highly confidential.

Derek: Or you don’t have conference rooms, or you don’t have laptops, or other things. Some of it goes to, can you do baby steps to get there? “Hey, Can we pair? Can we both squish in one cube?” We can’t all be in the same spot, but instead of me being totally siloed, can I be near two other people or, can we move to some part of the area where at least more of us are close…?

Roy: Proximity. Maybe work for the corporate cafeteria or something?

Derek: Right. So, I think there are some things that you can do that are kind of “Hey, can we baby step to get there to explore the benefits, or, start to show the benefits which then might help accelerate facilities’ issues or other pieces that are there.” But, I think it’s tough. I think Clayton put it well, “Facilities don’t give a shit about your team”.

Jade: Let’s imagine it’s not the person, right? It’s the environment not conducive to working together. So, what are some other situations that you guys have found yourself in where you’ve had to work around something that’s preventing your team from being as performer as they could be?

Testing In Legacy Code

Clayton: I think one thing I’ve seen is you get teams that have big, kind of old legacy nasty projects, and they want to maybe try and improve their technical practices. And so, I think right now if you were to go out and start, kind of Googling around for maybe TDD or BDD things, a lot of the things you run into are either technology stacks that are newer, or they’re using what seem like contrived examples.

And so, I think a lot of people get turned off where if I say, I heard about this BDD thing, and I go Google for it and I stumble upon Cucumber, which is in Ruby, and, I get upset that it’s not in Java or, whatever my language is. And, yeah, you can go find those things have been ported, or exist in your language. But, it doesn’t feel the same because it kind of takes the new and shiny off of it.

And so, I think in those cases, having to take the stuff that’s new and exciting but, kind of having to map it back to your like, the daily grind, I think turns a lot of people off. It’s difficult to do.

No Local Development Environment

Derek: I think one of the ones I see a ton is a local development environment doesn’t exist. A team development environment exists and a test environment doesn’t exist that actually mimics production in any way, shape or form.

It’s so impossible to get to that because we don’t have access to our local machines to install things, or, our machines are so crappy and old, we can’t install them. Or, we don’t have licenses to the software to install it. Or, the list goes on and on and on about why teams can’t do that. They lose so much time.

Hey, we’re working together, and, we’re doing something, and, we have to wait 15 minutes for something to compile on the test server so that somebody from test can look at it instead of just coming in coding, and, letting them run on their local machine. Various things like that tend to be these prisons that are non‑optimal. It’s not our fault, we have to talk to ops and deal with that or somebody has to order hardware or something completely out of our control.

Jade: So what are some simple tricks that you’ve used to at least help alleviate some of those problems.

Derek: Usually one of the things that can alleviate it is usually you can get the local stuff done. So it’s like, if you can at least get the point where everybody’s got the full stack running locally in the same way that cuts a lot of the problems out.

At least you never have to wait for a server to be able to look at or do something. I think the other things that we see all the time are go get rogue hardware. Find any empty cube that’s still got a machine in it that is slated for somebody who is not currently working there, pull it over to your thing and ask for forgiveness.

Later when you turn it into your CI box or into your dev bill box, the chances are nine out of ten times nobody even notices it’s gone, and when they do it’s like wow. OK, maybe yell that for 20 minutes…

Clayton: That’s why facilities hates everybody.

Derek: Right

Product Or Marketing Won’t Let Us Deploy More Frequently

Roy: Another one that I’ve seen a few times is when the development teams wanted to play really often because they see deployment as a painful something, and by deploying often they’re hoping that they’ll force themselves to making it better.

But that marketing or sales or product owners, whoever, are not comfortable with deploying that frequently, either out of fear of the deployment process isn’t rock solid or because they can’t market in that way where they release regularly or it doesn’t fit their business model.

One of the tricks I’ve seen to solving that is when they set up an internal fake customer box where they deploy to every commit to practice the deployment that replicates production as close as possible. So that when they actually do deploy to production it’s something that they have done every day for the last however many days instead of something they haven’t done since last year.

Believing It Is Possible, The Art Of Pretending

Clayton: I think a big part of it is just believing that it’s possible. Having a local environment I think you can hear so many excuses, like the self prison stuff. I think a lot of it is that people are wanting to ask permission first for a lot of things.

But a lot of times you tell them about a story like GitHub or something where they hire a new person, get a laptop and 30 minutes later they’re committing to production. I think to them that seems impossible. Obviously it is possible for some people and it’s all just computers and stuff and you know that you can automate it and you know you can make it work, and you probably aren’t a special snowflake.

So you can kind of get over that hump of thinking that it’s impossible to do those things, I think that goes a long way.

Derek: It’s true, it’s like that typical, “Yeah, we like to do that in the perfect world but we have this limitation. OK well maybe the limitation is a problem which you can solve, and you can be in this perfect world with the rest of us.”

Poorly Defined Roles

Clayton: I think another big example of the non‑ideal state is I would guess a lot of people would go get their CSM and they’re in their training and they talk about the different roles, and here’s what the team does, and here’s what the product does, and they go back to their office and the product owner really doesn’t spend all of their time with the team.

They used to be a product manager so they have all these other tendencies. Half the team came from some other team and sometimes the other manager comes over and asks them to do work on this other project. There’s all these things that don’t fit into the roles at all. I feel like that’s got to be a huge problem for a lot of…

Jade: That would never happen. [sarcastically]

Clayton: Right. [laughs]

Derek: Right, and they come back and try to adapt everything to fit into their existing business, their existing corporate structure, right? So, a kid like, “OK, I understand that scrum is supposed to have a product owner that is present all the time but we can’t have that. So we’re going to adapt it to meet our company’s needs, and that will make it better.”

Clayton: I think in a lot of those cases you just have to, to some degree, just buck up and say, “Hey, in order to have a successful scrum team we need to have a product owner that has authority and has presence and can be with the team.” That’s just how it has to be.

So we’re not really going to find some way to weasel around that. As far as the kind of hacks and stuff go I don’t know that there’s a whole lot you can do other than basically just being real honest about what you have to do to be successful in that role.

A Coaches Approach

Jade: As our role as coaches, Clayton you talked a bit about just believing that it’s possible. Let’s step back from the specifics and let’s talk about our philosophy. How would we approach this? You show up and you walk into an environment that is so complicated, so convoluted that there are no simple, obvious ways to start to make these type of improvements to work a little more towards the ideal. How would we start to approach and unpack that problem?

Clayton: For me I think that comes down to looking back to looking at some values and principles. You’re not going to be able to go in and necessarily find a list of 15 things that they’re “doing wrong,” and if you fix those things, then they’d be better.

But if you stick to the values and principles and you start observing some of their interactions in the existing processes. You say, “Hey, I think one is kind of misaligned with the values that we’re trying to go for.” At least, get into that baby step of just exploring that possibility. That’s probably a good first step. You can start finding real small things to break things down. You have to take those trivial problems and break them down into smaller chunks.

Roy: I think, something that’s important, though, is getting the team that you’re working with to actually believe that something like this is possible. I think, you alluded to that earlier, Jade, where there are bunch of people working these types of environments, these oppressive environments, their entire life.

They think that something like 10 minute build or an easy deploy or testing before you develop quota or anything of those things are just impossible. That really is unachievable fantasy land of perfection, rather than a real practical thing that you can actually do. I’m not quite sure how you could convince them that that reality can be true.

Derek: I think, for me, the way that I’ve been framing this lately, is it’s permission versus policy. Most of these organizations are really strong policy oriented and don’t trust their people. For me, the first thing, is whoever is asking me to be the coach, do they really believe in what they’re doing? If the answer is yes, I ask them for permission to give me latitude to really push the bounds of things.

I think, that’s the only you can show teams that the culture is changing, that the system is changing and that they aren’t allowed to have permission. Because, more often than not, they’ve been slapped down so many times, they are not going to believe it by default.

Then, it’s a matter of taking every opportunity to deal with those civil disobedience issues, where it’s, “You know what? There’s a server that’s been sitting on that for the last five days. Nobody has touched it. Nobody can tell me what it’s for. I’m picking it up. I’m making it the CI box. I will do that and I will take all the heat for that as a coach. I’m willing to go tell the executive sponsor that I’m doing it.”

If they say, “No, can’t do that.” I say, “OK, great. We’re done with this coaching engagement. You are not serious about the change.” I’m giving you an out that you can blame me. You don’t even have to say you know about this. I find that executive sponsors are serious and say, “OK,” stuff tends to start to happen and unfold.

They need that catalyst or the change agent to stand up for teams and stand up for change. I think, you have to know how hard to push, right? I’m not suggesting you go in, you just start tearing everything apart.

Jade: I formatted this machine. I hope that was all right.

Derek: Yeah, I think…

Jade: That was our production change.

Picking Your Battles

Derek: …you have to pick the battles and see where you get the most lead for the team. The team starts to push harder and then, pretty soon, you really do have a civil disobedience going where it’s get harder and harder for shitty managers to push back against empowered teams. That’s part of the goal is to get people to say, “Hey, we do have the power to make good decisions. If we don’t, hey, we’ll be let go. If we’re making decisions…”

Clayton: I think I’ve seen teams where they knew based on the Scrum rules that they were supposed to be able to dictate to some degree how the stand‑up meeting went, but they would laugh about it every time. They hated the stand‑up meeting because there was a controlling manager that made them do it a certain way.

To them, it was impossible. There was no possibility of any change, whatsoever, because that one little example. If they couldn’t change this in that meeting, they couldn’t do anything, so what’s the point? That was their big barrier to even believing. You could convince them that there are teams that have a 10 minute build and do CI and all this other stuff but, “Not in our world. It just doesn’t exist.”

Jade: I think, that’s it for this week’s episode. Thanks for listening. Check us out on Facebook, facebook.com/agileweekly. We’ll talk to you soon. Good‑bye.

Clayton: Thank you.