How To Deal With Imperfect Situations And Get Better Results

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.