How To Deal With Imperfect Situations And Get Better Results

Explicit content warning

05/08/13 • 14 min

Agile Weekly Podcast

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

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

Hacking Your Way To Proximity

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.

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

Testing In Legacy Code

Previous Episode

Will Agile Make Us Faster or Better?

Roy vandeWater: Hello, welcome to Agile Weekly Podcast. I’m Roy vandeWater.

Alan Dayley: I’m Alan Dayley.

Derek Neighbors: I’m Derek Neighbors.

Jade Meskill: I’m Jade Meskill.

Why Is Agile Faster

Roy: Today we’re going to be talking about “Why is Agile Faster”? Alan brought this to our attention. Do you want to give a quick intro?

Alan: This is something you see all the time online and that I encounter with clients and so on. People say, “We want to do Agile because we want to be faster, because faster is better and Agile will be so much faster.”

I recently did a blog post about this and thought it would be fun to bring up here to talk about the perception of Agile being faster ‐‐ is it really faster or not? Why would it seem to be if it is or isn’t ‐‐ all those kinds of issues.

I proposed in my blog post that Agile isn’t necessarily faster. Just because you’re doing Agile or you’ve done it for three sprints or iterations, that doesn’t mean people are coding faster or the testers are testing faster.

Delivering Value Sooner

Roy: Does it mean you’re delivering value faster?

Alan: Well, I’d rather you use the term sooner than faster in that case.

Biased Towards Action

Jade: I think a lot of it is biased towards action. If you look at the core of what the Agile principles and values get you doing as a team, you’re looking at moving towards some goal sooner.

Alan: That can be one of the factors right there.

Uncovering Better Ways

Derek: I guess, for me, when I look at the Agile manifesto and corresponding artifacts, I don’t know if I’ve ever seen anything talk about faster, sooner. I’ve seen “better.”

“Better” could include faster or sooner. I don’t want to call them illusions, because I think ultimately, over time Agile teams do tend to perform better. I’m not discounting that that’s the case, but I think some of it is the illusion of speed ‐‐ how quick you get feedback.

I like metaphors, so maybe I can explain with a metaphor. If you are in a car and you are going 70 miles an hour and you look out the front window, it very often does not feel like you’re going 70 miles an hour.

If you’re in the same car going 70 miles an hour and you hang your head out the window and you look at the little striped lines and you see how fast they’re going by, it feels a lot faster than when you’re looking out the window.

You’re going the same speed. The difference is you’ve got some indicator that is giving you perception that you have movement.

I think one of the things that Agile methodologies tend to do is make things visible. They make movement visible where you didn’t see movement before. Even if you’re in a long iteration, if you’ve got burn‐down charts, if you’ve got card walls and other things that are showing movement it feels like “Man, we’re really getting a lot done,” or “We’re really going fast” because we’re seeing lots of movement.

Where before it’s “Hey let’s go do this stuff and we’ll come back in X number of weeks when the project manager comes by and says “Are we on track for this”? And nobody on the team is really seeing any movement except maybe the person doing the individual silo‐ed work.

Focus On Improvement

Alan: One of the interesting things that I point out many times in these discussions is the retrospective and the focus on improvement. Most teams traditionally are not spending any time trying to improve. The reality is that you are going to end up spending less time coding because you are going to spend time trying to improve.

The payoff is in the long term ‐‐ some iterations down, some months down ‐‐ the team will actually have more efficient processes and better ways of communicating, et cetera, because they have taken the time in the early iterations to build some of that. I think that really does help improve actual higher production, or more output.

Roy: So they will eventually be faster? That’s what I’m buying if I’m converting my company over to Agile?

Derek: I don’t think you will necessarily be faster. You’ve made an investment in being able to respond better and you’re hopefully focusing on doing the right things. If we’re doing the wrong things really fast, we haven’t actually made any progress.

Alan: Yeah, that’s kind of the input side which we can address here in a little bit.

Iterating To No Where

Derek: Iterating to nowhere. I think it was Carlos Segura or some fairly famous designer I thought put it really well. Y...

Next Episode

Using The Decider Protocol and Presence To Limit Revisiting Decisions

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

Roy vandeWater: And I am Roy vandeWater.

What Does It Mean To Revisit A Decision

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

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

Roy: Yeah.

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

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

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

When There Is New Information

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

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

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

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

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

The Cost Of Re-Work

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

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

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

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

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