Agile you hate, Agile you need. An interview with Radosław Orszewski, Agility Practitioner
“Agile You Hate, Agile You Need” launches our “Around the Product Development” series, where Matt Hallmann talks with Radosław Orszewski, an exeprienced agility practitioner. Dive into Matt’s exploration of Agile from a client’s viewpoint, discussing its role in today’s digital product scene. What criticisms are raised against Agile? Are there credible alternatives? And what’s the key to successful Agile implementation? Read on or watch to uncover Radosław’s insights into these pivotal questions.
Table of contents
Matt: Thank you for joining Radek and me today, and thanks to the audience for participating in our event on the topic “Agile: You Hate It, Agile: You Need It.” Today’s guest is Radek Orszewski. Radek, you are an Agile Ninja, if I can say it like that. You have extensive experience with Agile and Lean as a coach for several years. Can you tell us a little bit about you?
Radek: Thank you for having me here. Indeed, I chose the term “ninja” because I believe in making a professional impact without seeking the spotlight. My aim is to facilitate change within organizations. In my professional capacity, I provide coaching, mentoring, and training to support various organizations in becoming more adaptive and agile.
Matt: As someone with some knowledge of agile but not an expert, could you explain what agile is in simpler terms? What should I understand about it?
Radek: Okay, so you’re right. By now, probably everyone in the industry has heard about it. People have different experiences, biases, or opinions. So instead of telling you or answering all of our viewers here what agile is, I will address what agile should be.
Imagine that we’re all dealing with complexity and uncertainty. We’re trying to build different products, find solutions for many problems in the market, and we can approach it in various ways.
Some of these approaches can be very costly. Some can be time-consuming, even risky. We might accumulate risks or assumptions about what customers want or need and what will benefit us.
Economically, we know from everyday life that despite great names, brands, or money behind them, some products are awful failures.
The entire agile movement aims to prevent such failures and to break out of the bubble of our imaginations or assumptions. It’s about building products, going to market, reaching customers, and finding solutions tailored to their needs—sometimes quicker, cheaper, or more customized.
Of course, this is a philosophical definition at a high level. In practice, it involves many different things, various practices for organizations of different sizes.
Matt: So, we understand Agile’s objectives, but there are often criticisms that it fails to deliver on its promises. Does this suggest that it’s frequently misimplemented? Why do some people have negative feelings towards Agile?
Radek: Provocative statement. Because I believe that in times of, you know, not cheap money, when we consider costs, headcount, and various other factors, it’s very easy to scapegoat something that’s become a buzzword. And I think it’s no secret that this is probably why we’ve titled today’s conversation this way. Because many people will say, “Oh, agile, we’ve been doing that. We tried that. It was costly, it was a hassle, and it didn’t bring any benefit.”
The issue is that many overly simplistic approaches are misleadingly labeled as agile. And naturally, they won’t deliver the benefits that I described as essential to true agile practices. Therefore, I believe perhaps this period of market correction or crisis—some might even call it an opportunity—to validate what is truly bringing value to us. It’s a moment to discern what practices we should prioritize and what was merely a superficial adoption of a trendy label over the last couple of years.
Matt: So, my understanding is that Agile was initially designed for small teams. But with companies growing larger and teams expanding over the past two decades, has Agile adapted to accommodate these changes? Does it still function effectively in larger organizations and for bigger product developments?
Radek: Good point. Well, yes, you’re right. Initially, we were hearing and attempting to implement agile in a team-focused approach. However, we understand that large organizations, encompassing various areas beyond product development—such as marketing, HR, or legal—make it much more challenging to achieve everything within one team. And now, we have a whole spectrum of solutions that we can view as agile.
Certainly, if you’re still striving to deliver products within a small team or organization and can effectively accomplish most tasks, that’s excellent. However, in larger organizations, there’s a risk that the team delivering value may become insulated from the market or customers, which is inherently risky.
We observe some large organizations grappling with this issue, creating layers of insulation between the market and the teams, which is quite perilous.
So, I don’t believe that working in a big organization automatically precludes access to the market or direct feedback.
So we say we need to be aware that the organization, which is bigger but would like to be agile, should think about healthy interactions between the teams. I have my biased look at it because professionally I’m a master in biotechnology. So I like to look at organizations as, you know, biochemical or natural beings.
Matt: How do you facilitate this interaction? That seems to be the question. Could you provide a brief overview of how this is achieved?
Radek: So, if you consider again what is and what should be agile, it’s important to understand that different functions can be delivered within organizations in various ways.
Just like our organisms—you or me—are made of cells, which form organs and tissues, we can see a similar structure within organizations, right? Some frameworks claim to scale agile but take a very mechanistic view of organizations.
Rather than resembling living beings, they resemble big machinery. And I find that dangerous because it’s based on many assumptions: that we can predict timelines, reduce uncertainty, but unfortunately, also reduce innovation.
Natural evolution in living beings occurs through trial and error to a certain degree. So, if we were to recommend anything, I believe we should design our organizations for flexible and evolving interactions. The type of interactions I find highly beneficial is called team topologies.
This approach considers what kinds of teams we have currently, what types of teams we’ll need in the future, and how existing interactions should evolve over time.
Matt: Let’s delve into the issue of reducing uncertainty. Could this be why Agile is facing increased scrutiny? Is it due to companies’ desire for control? How do you perceive this?
Radek: So, I’ll start perhaps from this perspective: there’s a saying, and I believe many of us have encountered it in our everyday lives, especially in uncertain and dangerous times. We often revert to our old habits, to what Daniel Kahneman, the late Nobel Prize laureate, termed as system one thinking. We have system one, which encompasses our habits and instincts, and then there’s system two, which demands significant energy to contemplate our actions.
One reason we might view agile as a scapegoat is that if it doesn’t align with our ingrained behaviors, we tend to reject it and revert to old ways of working. Conversely, if we deviate from the agile approach, we essentially enter a realm of false certainty or invisible assumptions, where we believe we know what’s best for the customer or what’s beneficial for our business. However, there are numerous things lurking in our blind spots, and that’s highly perilous.
Matt: I understand. If we consider the customer’s perspective, are there viable alternatives to Agile? What options are available? Do you believe there are other Agile methodologies worth considering?
Radek: That’s interesting because, as you mentioned waterfall at the beginning of our conversation, it’s evident that this approach still exists in the market.
If you ask people, is it truly feasible to complete all types of design first, followed by all types of development, and then all types of testing, etc.? I mean, this is a very simplistic approach that I haven’t witnessed in action, even in organizations that claim to adhere to traditional cascade or waterfall methodologies.
So, even if an organization believes it operates in this manner, I mean, what is the organization really thinking? But okay, that’s a different topic. What truly occurs is that people circumvent rigid processes and strive to work smarter anyway. The issue arises when we perceive that we work in one way, yet some of our people are working differently, creating a gap, a delta.
Therefore, I’d say it’s crucial for organizations to embrace the reality that change is inevitable, that adaptability is essential. We can’t plan for months or years in isolation, expecting to come up with the perfect solution the first time we enter the market.
Matt: Because when people don’t have a framework and they find their own ways of working, they have to figure it out again and again. It’s like reinventing the wheel, over and over. And it’s not that people aren’t smart enough; it’s just very difficult to invent something that works really well.
Radek: There’s also an interesting aspect here, the halo effect.
So, when I explain what I do—how I help organizations—I try to do it in a straightforward way. Sometimes, professionals like us encounter people completely outside of our bubble, and we have to explain what we do, maybe at a grill, during a barbecue evening, for example.
And there’s often this moment of surprise when we explain to people that I help professionals in organizations manage and organize their work. And then people respond, “How come they don’t know how to work?”
It’s amusing because we hire highly skilled developers, designers, or whoever else is in our profession. And we have this assumption that if they’re skilled in their specific area, they must also be proficient in managing their own work and the work of their team or within the larger organizational structure. But that assumption is often false.
Matt: Okay, so as someone interested in agile for my team, is it expensive to implement? How do I start? Do I need to hire a lot of people or an agency? Is it beneficial to get support from a coach?
Radek: We often see additional costs associated with agile ways of working. It’s not just about hiring an agile coach or grandmaster; it’s also about the cost of reaching out to customers, conducting interviews, and creating multiple prototypes or wireframes to decide on a design.
This can be tricky because these are immediate costs, and the benefits usually come in the long term. However, many organizations, including ourselves, tend to focus on short-term solutions that promise to reduce uncertainty immediately.
Explaining the benefits of agile may require coaching, mentoring, or referencing successful cases from similar initiatives where initial uncertainty and expenses paid off in the long run.
In defense of agile, as customers, we often notice when a product wasn’t developed using agile methods. For example, when a bank’s application doesn’t meet our needs because it wasn’t designed with user interaction in mind.
Matt: But I can still imagine that some companies might face this restriction from their bosses, managers, or other departments, insisting on immediate results without waiting.
So, how do we tackle that effectively? Is there a way to quickly demonstrate results with agile, or how does that work?
Radek: Well, in organizations like this, especially internally, we often have past examples of rushing for a solution that wasn’t ideal. So, it might be beneficial to reference such cases if you have internal context.
However, this brings us to a more cultural aspect: what behaviors are rewarded in the organization? Many focus solely on output—how many features are produced—while agility emphasizes outcome. It’s about enabling new experiences and opportunities for both customers and the business, making a real impact.
This requires what many call an agile mindset. It’s essential, but we need a balance of mindset, education, and tools and processes to support it, as not everyone knows how to do it.
Matt: We’re nearing the end of our conversation, and I want to circle back to the title of our talk: “Agile You Hate, Agile You Need” Interestingly, in my preparation for this interview, I came across some articles with titles like “The End of Agile” or “The Death of Agile”.
However, I think the conclusion is that there’s really no other viable option, if I’m not mistaken. Would you agree?
Radek: Absolutely. In today’s rapidly changing world, even the wealthiest companies with ample cash flow can’t afford to ignore markets and uncertainty. Embracing agility is essential for survival, especially in the long run.
Want to see this interview in a video version? Check out Matt Hallmann and Radoslaw Orszewski’s interview on YouTube
Share this article: