Roy van de Water and Clayton Lengel-Zigich discuss:

• Why teams revisit situations
• Disclosing what you know
• Decider Protocol

Transcript

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

Roy van de Water:  And I am Roy van de Water.

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.

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.

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?

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

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

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

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

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

Roy:  Right. Exactly. Right.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Then, giving those people the choice to use it.

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

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

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

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

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

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

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

Clayton:  Right.

Roy:  …with each other.

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

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

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

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

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

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

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

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

Clayton:  Right.

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

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

Roy:  Thank you.