Episode Transcript
So, in this episode, I want to talk about “the real world.”
Like, the old MTV reality show?
*laughs* No, though I have to admit I did watch that when it first came out. Not sure if my parents knew. Anyway…
Back when Agile approaches were first spreading beyond the early adopters, say, 2006 or 2007, when I was training or coaching a team to get started, somebody would always have an objection that started, “that sounds great, but in the real world…”
It was such a pattern that I ended up dedicating the final half-day of my Agile for Teams workshop to collecting, prioritizing, and working on the top tier of reasons why that group was going to struggle to apply an Agile approach in their context.
That “but in the real world” objection kind of went away in the mid-teens. And then, in the past quarter, I had two different workshops with two different clients where it reared its head again.
So, I thought it would be interesting for the two of us to have a conversation about the “but in the real world” objection—where it comes from, what it means, and how to handle it whether you’re a coach hearing it from a client, whether you’re hearing it from one of your colleagues on your team, or whether you hear yourself thinking or saying it.
Sounds good. Before we get into it, though, a reminder to our listeners that…
This show is a free resource sponsored by the Humanizing Work company, where we help organizations get better at leadership, product management, and collaboration. Visit the contact page on our website, [humanizingwork.com](http://humanizingwork.com/), and schedule a conversation with us if your organization wants to see stronger results in those areas.
If you want to support the show, the best thing you can do if you’re watching on YouTube is subscribe, like the episode, and click the bell icon to get notified of new episodes. Drop us a comment with your thoughts on today’s topic. If you’re listening to the podcast, a five star review makes a big difference in whether other people find it or not.
So, Richard, what kind of things were you talking about when you bumped into “but in the real world” in your recent workshops?
Well, you might expect it to be some of the wild stuff our most mature clients experiment with: doing away with user story estimates, pushing towards really high levels of empowerment and self-organization, releasing software every day, or using Agile approaches way outside of software. But, no. I was getting the “real world” objection to some pretty basic Agile stuff:
- actual cross-functional teams that can deliver increments of value
- completing a valuable user story in less than a week—not necessarily enough value to go to market, btw, just completing a thin vertical slice of value
- or even having a conversation with a customer to hear about customer goals and needs first hand
Those things, apparently, couldn’t happen in the real world.
Now, I’m sure you were telling stories about real teams doing those things.
Of course. I have little interest in teaching theory that hasn’t actually been tested.
Right, so that suggests that the “real world” claim isn’t meant literally.
I think that’s true. It’s possible, but unlikely, that the person is claiming all the stories we tell are made up.
So, how do you interpret it? What do you think is going on there?
I think there are a couple different things it can mean.
One is a claim that whatever we’re talking about wouldn’t be worth the effort. It’s unrealistic and impractical. And, I think there’s an implicit claim in the snarkiness of the objection that serious people don’t waste time on this stuff. If you’re realistic and down-to-earth, you don’t bother with these touchy-feely human-centric things.
Another possibility is that whatever we’re talking about is so far from this person’s current reality that they can’t imagine getting there. Whatever dysfunctional situation they’re in feels like “just the way things are.” And that’s normal and probably doomed to stay that way.
I notice those are at really different places in the levels of resistance we talked about back in episode 130.
The first objection is probably level 1: disagreement about the nature or extent of the problem. This person seems to be claiming that things are fine as they are, and changing isn’t going to be worth the effort.
And you can test that, if you want to, by asking about the person’s satisfaction with the status quo. Is the current team structure or work breakdown or whatever working for them? You might find they do experience some pain in the status quo but they don’t see how whatever we’re talking about would address it. And you can go from there.
The second form of the “but in the real world” objection sounds like a level 4 or 5. They’d love to change but don’t see how it’s possible.
That second interpretation feels more charitable to me. And maybe more useful to work with. Because if someone's current situation feels normal and unchangeable to them, that's actually something we can work with.
Yeah, and I think there's something important about that word "normal." Because what often happens is people look around their organization and see the same dysfunction everywhere. So it must be normal, right?
And if it's everywhere in their experience, it's probably everywhere else too, especially since bad news travels fast and is more memorable, it’s easy to start to assume that everything’s broken everywhere.
I think this points to the importance of leadership. There are a lot of things that can’t be solved at the team level. Leaders need to create an environment where great things are possible. Or people just give up, disengage, and do the minimum within a broken system that feels permanent and unchangeable.
We’ve talked about this on the show a lot. So many people feel disengaged from their work, and the biggest determinant of workplace engagement is your direct manager.
Of course, the manager is often not in the room when I’m hearing the “but in the real world” objection. And the manager’s manager is even less likely to be there.
And that’s where things like team structure get shaped.
Right, so the advice we give people in the middle of broken systems is always, “If you can’t fix it, make it more visible.” Help the people who can fix it see what you see.
For a lot of these topics like cross-functional teams and small slices of value, the thing to make visible is cycle time. Dysfunctional org structures and work breakdowns reveal themselves in long cycle times. And cycle time has a direct impact on the financials of a business. So, making that move visible and showing how a change can reduce cycle time—often dramatically—can be a way to build support for a change.
I told a story about this in episode 131.
When I encounter that “but in the real world” objection and want to engage with it—whether that’s a client, a colleague, or in my own mind—I like to get curious about what’s actually behind it. And those levels of resistance from episode 130 are helpful.
I’ll ask follow up questions to discern whether it’s a level 1 objection—things are fine as they are, and we don’t need to change—or a level 4 or 5 objection—I’d love to change but it’s just not realistically possible.
It’s usually the latter, and we can dig into why it doesn’t seem possible and talk about examples of other people making incremental changes in similar circumstances.
And sometimes, we have to help people hear those other stories differently. Sometimes people are automatically looking for what’s different in the story from their context. “That doesn’t apply here because they were doing a web app.” Or “but they were all in the same time zone.” Or whatever. So, I’ll point out that this context is different and invite people to look for ideas and inspiration rather than a perfect fit recipe.
I'm curious about something though. You mentioned this “but in the real world” objection was common in the early days of Agile adoption, then it went away, and now it's back. Any theories about why?
I've been thinking about that. I suspect in those early days, the objection came from a place of skepticism about new ideas. But now, I think it might be coming from a place of resignation or even despair about the state of work.
Say more about that.
Well, in 2007, Agile was still new and different. The "real world" objection was about whether these new practices would work. Many people had never seen them even attempted before. Now, we know they can work. But people are stuck in systems that feel impossible to change. And they’ve heard people use Agile terms without experiencing the reality.
I hear people saying: “We came to Agile for the collaboration, continuous improvement, and smooth flow of value. We got 2000-word Jira tickets, big planning meetings, retros that don’t actually change anything.”
The resignation isn't about whether better ways of working exist—it's about whether they're achievable from here.
That's an important distinction. Because if something is new and different and you’re just skeptical about the new thing, you can be convinced by evidence. But if you believe something is impossible to achieve from where you are, evidence that it works somewhere else might actually be discouraging.
Yeah, and “but in the real world” can be a way to avoid having to reckon with the hard truth that things could be better somewhere else but that I don’t have the power or energy or whatever to make that happen here.
It was a breakthrough for me years ago when I encountered research showing that ability and motivation are tangled up in our brains. If something doesn’t feel possible, we’ll convince ourselves it’s not worth trying anyway.
I think we have the biggest impact in our work when we can revive people’s imagination for what’s possible—for how good work can be—and then can give them the skills and tools to move towards that vision incrementally.
"Dream big, act small.”
Yes! And you need both. In a complex setting like a human work system, lasting change happens by nudging the system towards a better state. So, you need to know where you want to go, and you need to run small experiments to get there. It doesn’t work to just have a big vision if you can’t see how to get there. And it doesn’t work to just make changes if they’re not oriented towards better outcomes.
That gap between the current reality and a better way of working can feel overwhelming. But then we need to help people understand that no one wins when we settle for less.
Companies aren't better off with inefficient processes and poorly shaped org structures. Teams aren't better off doing busywork. The most human-friendly approaches to work turn out to also be the most effective.
Right. Let yourself imagine a genuinely better way of working. Don't dismiss it just because it feels far away. But then think about the smallest step you could take in that direction.
Can you give an example of what that might look like?
Sure. Let's take that first "real world" objection I mentioned - about cross-functional teams. Maybe you can't reorganize the whole company tomorrow. But could you get three people with different skills to collaborate on one small piece of work? Could you try that for two weeks or a month?
That’s kind of what our Team Launch Sequence does. Let’s take two weeks to run 10 small, back-to-back experiments with cross-functional collaboration and see what happens.
Exactly. And by day 4, that person who said “this’ll never work here” is saying things like, “oh, this is what real collaboration feels like. What if we *could* do this all the time?”
And once people see that working, even at a small scale, it starts to change their sense of what's possible.
When our team adopted Scrum, we got some training, and then talked about whether we wanted to adopt it. The general sense was that it was worth a try. But, like with any team, not everyone had the same level of enthusiasm. I remember one back end developer, Eric Sanders, who was vocally grumpy about it, for like, most of the time he was on our team. When we adopted it, he had that response we’ve been talking about. “In the real world of backend dev, it takes months to get the architecture and components mapped out, coded, and working well. It’s not like a UI widget that you can knock out in a week, test, and go live with.” He didn’t try to sabotage it or anything, but at every retrospective, he was the voice of skepticism. Eric left our team after that first cycle, and I always assumed he left thinking Scrum was only effective in a narrow part of software development.
Then, a few years later, I was asked to train a newly formed team that would package up the media playback capabilities across Adobe’s applications into a shared component. We scheduled the training, and the night before, I reviewed the invite list. There was Eric’s name. “Oh boy,” I thought, “now I’m going to have to do the training with a skeptic that will challenge all of the success stories I share in my training! “
The next day, I got through my intro, where I shared what the Audition team had accomplished and why I was excited to help other teams get the same benefits, when Eric raised his hand. “Ok, here we go!” I thought. Then Eric stood up and gave a three minute speech about how useful Scrum had been for the Audition team, how excited he was that this new team was going to adopt it, and to rely on him as an experienced Scrum supporter if they had questions. My jaw hit the floor. I tried to play it off, like “yeah, I planted Eric on this team just to be my cheerleader,” but I was shocked that someone as vocally skeptical at the beginning, had seen it work and become an advocate.
It sounds like at some point when you weren’t looking, Eric actually experienced how Scrum could fit with his work.
Yeah, that reminds me of an experience I haven’t thought about in a long time. About a year into adoption, I came back from lunch, walked into our team’s area, and passed Eric’s office on my left. As I walked by, I saw that one of our testers, Charles, was also in Eric’s office, sitting at another desk with his laptop, kind of back to back. This was pretty unusual, since Eric liked to be solo for his focused work, so I paused and started eavesdropping. I was very snoopy as a Scrum Master.
I heard Eric say something like “Ok, I’ve checked that into the build, check it out.” Then Charles said “stand by…” and a few minutes passed. Then Charles said “Oh, you’ve made it so I have to pick the sample rate first, but our users will want to pick the source first, then the sample rate.” Eric replied, ah, gotcha. Hang on…” A few minutes pass, then Eric says “Ok I’ve changed that order, check it out.” At this point I was worried someone was going to catch me so I headed to my office. But at the daily Scrum the next day, Charles reported that he and Eric had paired up on a new input source type and that it was tested and ready to go.
That’s probably not what Eric had in mind when he started with Scrum, but as he experienced those faster cycles improving his code, "the real world" started to look different.
Sometimes, you can’t discuss or reason your way into it. You just have to do small, safe experiments to discover what’s possible.
This feels like a good place to wrap up. Any final thoughts for people who might be feeling stuck in their "real world"?
Yeah. What feels like an unchangeable reality today is just your current starting point. Don't mistake what's familiar for what's necessary or inevitable. There are organizations right now doing the things you think are impossible. The question isn't whether better ways of working exist—they do. The question is what small step you could take today to start moving in that direction.
And if you'd like help figuring out those steps or building momentum for change in your organization, we'd love to help. Visit humanizingwork.com to learn more about our workshops and consulting services. Thanks for tuning in!
