Organizational Honesty in Agile Teams

Peter : Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode. Dave : I was going to say, maybe we need to be honest, we don't know if it'll be an exciting episode until we get to the end of it. But I'm sure we'll have a good conversation regardless.

We'll see where it goes. Dave : That was part of what I wanted to talk about today: this concept of organizational honesty. We're seeing more and more how difficult it is to say what needs to be said, in whatever form, within an organization. Peter : Yeah, it's an interesting concept.

You mentioned before we started that it's not about accusing everyone of lying. It's about whether there's the psychological safety for people to speak the truth. How much is that actually happening? Is the organization being transparent about how it's operating, or do things just get swept under the carpet?

Dave : Let's use an example. Say somebody comes to you and says, "We have a delivery deadline, we're expecting to push a release out on the 31st of July. How are things progressing toward that?" That opens up a lot of different responses, depending on how comfortable people are with what they know.

First, maybe we genuinely don't know what's going on, so there's a transparency and information piece. But there's also this thing where we stay quiet, or we mumble a response like "yeah, that should happen," even when we know there are things that need to be addressed. Somehow it doesn't feel like the right forum, the right people in the room, or we just don't feel comfortable bringing it up. Peter : Especially if it's someone more senior coming to say, "Hey, we've got this exciting new client, and we need all of this ready by the end of September."

Dave : I think of myself as an eternal optimist, so of course my natural response is "yeah, I think we can do that." But there's a whole lot of detail we actually need to explore. Why do you think we'll hit that deadline? That's where things get interesting.

Peter : Right, and what does "hitting the deadline" even mean? If we're not aligned on that, we're setting ourselves up for disappointment. We can both say "yes, of course," get there, and then realize, "that's not what I wanted." Dave : If I start breaking down what that actually requires: number one, we need information.

Peter : Yes. Dave : If I don't know what's going on, if I don't know what the teams are up to, where the packages of work stand, whether they've even been discussed with the team, what the team's capacity looks like, what they've delivered before and what's coming up... there's a lot of information that needs to be at our fingertips to answer that question honestly. Peter : And one piece of that information is how different this task is from everything we've done before.

Is this a rinse-and-repeat situation where we know exactly how long it takes to stand up a new client? Or is this something we've never done before, with no real idea how long it'll take? Dave : We talk a lot about risk and managing risk, but a lot of it comes down to familiarity. There's data we can rely on because the team has a track record of delivering these things consistently, so we have confidence in certain numbers.

Then there's data we're just not sure about or don't fully trust, maybe the team is coming together for the first time, the technology is shifting, or there's some uncertainty or complexity we can't pin down. And then there's the sense-making side of things. We're right in the middle of World Cup season. If your team makes it to the next round, and the next one after that, how does that affect delivery?

That's not pure data, it's more like noticing that vacations are coming up, or the team's had some change we're only seeing from the outside. We can't see it in the numbers. Peter : Right. One of the most common issues we see is a breakdown in communication across different parts of the organization, Peter : where different specialties or areas have different expectations.

They communicate in a way they think is clear and transparent, and they assume everyone understands, but the message doesn't actually carry through the organization. That especially happens when teams are operating largely independently, only coming together occasionally, without thinking about the system more holistically. Dave : And this is where organizational honesty comes in. If I bring together teams that don't normally work with one another, how well can they actually communicate?

Is there an environment where they can say what's really going on without it becoming a point of contention, where it's treated as an observation of fact rather than an admission of failure, incompetence, or poor planning? Peter : It's interesting, because certain things, especially on the technology side, are genuinely hard to articulate. That's why you need people close to the technology who actually understand it. The same goes for other areas too, people closer to the problem understand its complexity, understand the requirements and the needs.

But from the outside looking in, it can seem like "that's all easy, they can just get it done." Dave : Right, so what's the environment like? Can I come in and say, "Actually, we're not going to hit this deadline. This happened, that happened, there are new priorities, and the effort we planned to put toward your work isn't going to happen"?

If I feel comfortable being transparent about what's really happening on the ground, we can have a constructive conversation. Is this the right decision for the organization? Do we need to escalate and reprioritize? Can we reset expectations with stakeholders?

What are the consequences of bringing that information to the table? That's where we really start hitting real problems, because in some organizations, being that honest is career-limiting, or it just generates more work to validate what you're bringing forward. In those situations, we're going to change what we say. Peter : Right, we protect ourselves.

That's the common approach. So why don't we switch gears a little? We've spent a lot of time on "oh, the world is terrible and nobody communicates well." There's a lot more we could explore there, but let's shift into what actually works to help resolve some of this.

Dave : Let's go back to that first point: information, and having something to actually have a conversation around. That means visible progress of some kind. There are a lot of ways to do that, but both sides of the conversation need some kind of shared visual on... and we talk about output versus outcomes here.

We need a little bit of activity data, but honestly, that's not the useful part. The useful information is the outcomes, the things we're actually delivering. Am I able to hand a complete piece of work over to your team, not just "how busy has the team been"? So the first thing is really about visual management and sharing the right information.

Peter : Along with that, you need the right forums to look at that information, compare notes, and make decisions from it. That's often where trust comes in. Is everyone comfortable saying, "here's what's really happening, here's what we need to do now"? Dave : It's interesting, there's a big difference between "let me prepare a report on what's been going on" and actually looking at the live systems.

Dave : There are work management systems where you can see, in real time, what's happening. An organization where people are trusted to pull up those systems and be accountable for what they see, that's a really good sign. Whenever I look at visual management systems, my goal is that they're cheap to produce. I don't mean manually manipulating the data or adding context, I mean just pulling the information straight from a relevant, near real-time work management system.

And second, that we're comfortable sharing it without layering in explanations or managing the narrative, so we can actually see what's going on rather than someone's interpretation of it. Peter : Having good structures to enable that communication matters a lot too. How we communicate, how we present information, how the conversation itself is structured, that all helps make sure things happen the way they should. Dave : This is where I typically look at burn-down charts, burn-up charts, real-time release boards, things like that, because we want to see the actual packages of work moving, the dependencies, what's being worked on and what isn't.

Not a spreadsheet full of numbers that feels disconnected from what's really happening. Peter : I think another key part is understanding what the end-to-end system actually looks like. What's involved, how long does it typically take to move through each piece? That's how you start to see where the bottlenecks are, where the constraints are, where you need to focus to make things go better.

That's a critical part of understanding. There's a lot more we could get into there, but I'd also add the incremental piece. Peter : If you spend a year building something before you ever put it in front of a customer, well, your mileage may vary. You might get it right.

Dave : Right, and that whole feedback-loop piece matters too. I also wanted to make sure we talk about safety, being able to come to a meeting and be transparent about what's really going on. I think this is the hardest part to actually get moving. If I'm coming from a different organization, or I've worked across multiple organizations, I'm going to walk into these status or progress conversations cautiously.

I'll be watching: if someone brings bad news to the table, what happens? Is it met with support, or treated as a failure? The classic pattern is "if you bring a problem, you need to bring two possible solutions," which immediately means if I have a problem I can't solve, I'm not going to bring it up. Or if I bring a problem and immediately have to go re-estimate everything, revisit it, and produce more data just to justify why it's a problem instead of us actually working on it together, why would I ever bring that to the table?

So the first thing that happens in these forums is people watching how bad news gets received. Peter : Yeah, and this is just human behavior. Everyone walks into those meetings with their own view, their own agenda, their own backlog of problems. Having a structure for those conversations becomes critical, because otherwise you end up exactly where you just described.

It's the classic "don't shoot the messenger," except the messenger usually gets shot anyway. Dave : Exactly. It's natural, if I hear bad news, I get pushed into a defensive posture. That's why I like what you said about structure.

It's why structure in these conversations matters, it lets us mentally realign and go, "okay, I need to adjust what I was expecting," instead of reacting. Structure lets information land, get absorbed and understood, and then get responded to, rather than triggering an immediate defensive reaction. Peter : Agreed. I think we're about at the point where we should start wrapping up.

If we want our listeners to walk away with three points about organizational honesty, what would you suggest, Dave? Dave : My first point would be information: making sure there's real transparency into the information people are relying on in these conversations. Peter : Right, and that information needs to be radiated and transparent, easy to understand, in a form people can actually draw on. It's easy to generate a lot of information.

What's hard, and critical, is making sure it's the relevant information, and that people know what it actually means. Dave : I'd add safety as the second point. I liked what you said about structure. We didn't dig too deeply into it, but having a forum where people can share bad news and trust it'll be handled constructively matters a lot.

There's a whole conversation to be had about how to build that kind of environment, but the key thing to recognize is that people are always watching. The moment we see behavior that makes it painful or costly to raise a difficult topic, that becomes a barrier to ever bringing it up again. So the real question is: how do we make it easy to bring these things to the table? Peter : For a third point, I'd say: remember to look at the whole system and its interdependencies.

You touched on this too, where are the dependencies, where are the constraints, where is work piling up? You can start to see some of that in the data, but the data only means something if you understand how it relates to the system as a whole. Understanding how work actually flows is critical. If it's basically ad hoc, everything's an email, and whoever yells loudest gets their work done, then it's worth thinking about how to do this better, and what practices might help work flow more smoothly.

With that, I'd like to thank you, Dave, and we'll wrap up there for today. Don't forget to hit subscribe, we always love new listeners. You can send any feedback to feedback@definitelymaybeagile.com.

Thanks again, until next time. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.