Agile Weekly

Roy van de Water, Derek Neighbors, and Jade Meskill discuss the need for frameworks.

 

Transcript

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

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

Derek Neighbors:  And I’m Derek Neighbors.

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

Roy:  Like Rails?

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

Derek:  No. Yes. No.

Jade:  OK.

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

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

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

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

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

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

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

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

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

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

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

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

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

Roy:  I agree with that.

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

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

[crosstalk]

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

Derek:  Not really.

Jade:  To do right.

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

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

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

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

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

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

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

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

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

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

Jade:  When have you seen the best results?

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

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

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

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

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

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

Derek:  Right.

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

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

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

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

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

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

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

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

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

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

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

Roy:  We are more agile than you.

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

[crosstalk]

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

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

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

Jade:  Measuring the rules of scrum.

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

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

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

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

Jade:  So, it really comes down to results?

Derek:  I think so.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jade:  Yes.

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

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

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

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

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

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

Derek:  Right. Exactly.

Roy:  They want something that may change it.

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

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

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

Roy van de Water, Clayton Lengel-Zigich, and Jade Meskill discuss trying a different approach to get a high performing team.

Transcript

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

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

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

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

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

Jade:  [laughs]

Roy:  Wow. I have not.

Jade:  [laughs] Imagine that you have.

Roy:  Is it like “Breakfast Club”?

[laughter]

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

Jade:  [laughs]

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

Jade:  [laughs]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[background noise]

[laughter]

Jade:  That was the jenga board that just…

Clayton:  Oh, probably. [laughs]

Jade:  The life size jinger that just crushed.

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

[laughter]

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

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

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

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

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

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

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

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

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

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

Jade:  You are done.

Clayton:  …you are done.

[laughter]

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

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

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

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

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

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

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

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

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

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

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

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

Roy:  But from their perspective it was so fast.

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

[laughter]

Roy:  He popped his collar.

Clayton:  I was like James Dean there.

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

Jade:  Pretty rebellious.

[laughter]

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

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

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

Roy:  For you?

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

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

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

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

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

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

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

[laughter]

Jade:  That’s rough for a web app.

[laughter]

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

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

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

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

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

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

Jade:  Having that good conflict?

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

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

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

[music]

Jade:  If there is something you would like to hear in a future episode, head over to integrumtech.com/podcast where you can suggest a topic or a guest.

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

[music]

Sharon:  I’m Sharon.

Diana:  I’m Diana.

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

Diana:  The challenges.

Sharon:  They’re not alone in their struggle.

Diana:  They want to be a better leader.

Sharon:  Listen, it’s good.

Diana:  Nothing but the truth.

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

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

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

Roy van de Water, Clayton Lengel-Zigich, Derek Neighbors, and Jade Meskill discuss the benefits of laziness.

Transcript

 

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 van de Water:  I’m Roy van de Water.

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

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

Clayton:  Really?

Jade:  Yeah.

Roy:  Do we really have to talk about it?

Jade:  I don’t know.

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

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

[laughter]

Clayton:  So many more jokes to be made.

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

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

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

Roy:  I’d shoot myself in the face.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Clayton:  Yeah, basically.

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

Clayton:  Right.

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

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

Roy:  Take a really long time, right.

[laughter]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Clayton:  Do the right thing on…

[crosstalk]

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

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

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

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

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

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

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

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

Roy:  I’ll put it off.

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

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

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

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

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

Derek:  I cheat a lot.

[laughter]

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

Jade:  [laughs]

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

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

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

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

[laughter]

Derek:  Can I just copy your…

[crosstalk]

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

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

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

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

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

Clayton:  It’s just what you do.

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

[crosstalk]

Jade:  That’s what it is!

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

Jade:  With a teaspoon.

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

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

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

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

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

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

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

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

Jade:  I’ve done that.

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

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

Roy:  Right, a little Yoda.

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

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

Jade:  Stop praising effort.

Roy:  Stop praising effort.

Derek:  Stop praising effort.

[laughter]

Clayton:  OK, but how do I do that?

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

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

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

Clayton:  Find a better way.

Roy:  Find a better way.

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

Clayton:  All right, thanks.

[background music]

Man 1:  If there’s something you’d like to hear in a future episode, head over to integrumtech.com/podcast where you can suggest a topic or a guest.

Man 2:  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.

[background music]

Sharon:  I’m Sharon.

Diana:  I’m Diana.

Sharon:  Leadership’s 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.

Man 3:  Partnerships and possibilities. Podcast on leadership. Find us on iTunes.

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

Clayton Lengel-Zigich, Roy van de Water, Derek Neighbors and Jade Meskill discuss why everything that can be automated, should be automated.

Transcript

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:  I’m Clayton Lengel‑Zigich.

Derek Neighbors:  And I’m Derek Neighbors.

[laughter]

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

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

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

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

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

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

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

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

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

[laughter]

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

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

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

Jade:  Yeah.

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

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

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

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

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

Clayton:  Yeah. Exactly.

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

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

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

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

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

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

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

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

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

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 $465 million.

Clayton:  Some trading company, right?

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

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

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

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

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

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

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

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

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

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

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

Roy:  Sure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Clayton:  If you’re a windows developer.

[laughter]

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

Roy van de Water, Clayton Lengel-Zigich, Derek Neighbors, and Jade Meskill discuss standardization and the effect it has on innovation.

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

Derek Neighbors: I’m Derek Neighbors.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jade: It’s technical Darwinism.

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

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

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

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

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

[laughter]

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

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

Derek: Right.

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

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

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

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

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

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

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

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

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

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

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

Derek: I only hired experts clay.

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

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

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

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

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

Jade: The policy blah, blah, blah.

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

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

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

Jade: They win the lottery.

Derek: Yeah, they win the lottery pool.

Jade: That’s the HR term.

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

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

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

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

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

Clayton: Usually always left.

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

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

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

Jade: That’s true.

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

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

Jade: It’s the hardest place to stay.

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

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

Clayton: Stick with what you know.

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

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

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

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

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

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

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

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

Derek: Thanks.