The Reality Check

Three years ago, I stood in front of our development team, looking at their skeptical faces and defensive postures. It was clear – some had bad experiences with agile before, while others simply stuck to their traditional waterfall approach. Their expressions said it all: ‘Not another process change that’s going to waste our time.’

What caught my attention wasn’t just their skepticism, but how differently everyone saw their future. Each developer was working on a different project, and everyone had their own idea of what needed to be done. One developer was pushing hard for automated deployments, while another kept emphasizing the need to clean up our technical debt. A third one was convinced that rebuilding our user interface would solve most of our problems. It reminded me of a group of people trying to reach the same destination but taking completely different roads.

But despite all the doubt in the room, I spotted something interesting. Some team members were actually engaged in the discussion, asking questions and sharing ideas. These small moments – someone suggesting an improvement or asking how something would work – showed me there was real interest in making things better, even if they weren’t sure how to get there.

This hint of motivation was all I needed. I’ve learned that you don’t need everyone excited about change from the start; you just need a few passionate people to get things moving. And right there, I knew I had found them.

The Initial Resistance: Understanding the Human Element

There was this one developer in the team who really stood out. He worked on hardware and made it clear he hated everything about agile. I knew him from before, and here’s what was interesting – even though he said he hated agile, he was actually the most agile person in the room without realizing it. He had a great way of getting things done efficiently and using common sense in his work. That’s really what agile is all about. His problem wasn’t with the principles; it was with all the unnecessary processes others had forced on him in the past while claiming ‘this is agile.’

Most of the other team members were quiet at first, which I’ve seen happen many times before in other teams. What I’ve found works best is getting everyone to share their thoughts – whether they support the change or not. And yes, most people will be against change at first – that’s just how we’re wired. Early in my career, I made the mistake of pushing my ideas onto teams and trying to make them talk about things they weren’t ready to discuss. That never worked out well.

These days, I take a different approach, which I used with this team too. Instead of telling them what to do, I ask questions about what they’ve just heard from their colleagues. When someone’s been quiet for a while, I’ll ask them what they think about what their teammate just said. This usually gets people talking to each other naturally, and I just guide the conversation. It gives me a chance to really understand what they need, what problems they’re facing, and what they want to achieve.

Once I understand their situation better, I can help them find solutions that actually make sense for them, rather than pushing something new that doesn’t fit their way of working. I’ve also found it really helpful to work with the team members who are already motivated to make things better. When ideas for change come from within the team rather than from me, people are much more likely to get on board.

The Strategic Approach: Beyond the Textbook

Over my years of coaching teams, I’ve noticed two main reasons why people dislike agile: they either had a bad experience with it before, or they misunderstand what it’s really about.

These days, when people think of agile, they usually think of Scrum. Most companies start their ‘agile journey’ by hiring Scrum Masters and following the Scrum guide. This leads people to think agile and Scrum are the same thing – but that’s not true at all. The reason Scrum is so popular is simple: it’s easy to sell certifications and easy to follow a set of rules. But does following these rules actually solve your problems or make your team more effective? Usually not. Scrum is just another set of fixed processes that people can follow without thinking too much. That’s why it’s popular, but it’s also why it often doesn’t help teams become truly agile.

Being agile really means being effective with what you have right now – your current team and your current project. And yes, what works best will probably change as your project moves forward.

Here’s how I like to start:

1. Set up time periods to try things out and watch what happens
2. Find the 2-3 biggest problems the team is facing and agree on ways to fix them
3. At the end of this period, talk about what worked and what didn’t, then pick new problems to solve

Now, you might be thinking these periods sound like Scrum sprints. They could be, but they don’t have to be. I see them as windows of time where you try something new and see if it helps. I actually use different lengths each time, depending on what the team wants to change. You need enough time to try the change and see if it’s actually helping.

Do you have to do it exactly this way? Not at all. Use your judgment and adjust based on what your team needs.

The main point is this: I don’t make changes by blindly adding meetings, boards, or processes just because some book or guide says we should. Instead, I focus on what the team actually needs right now – what’s really slowing them down, and what changes they’ll find helpful and be willing to try.”

Critical Success Factors: Cross Company Transformation

Working with teams, I’ve noticed something interesting: while the development team might be ready for change, the real challenge often lies in getting alignment across all management levels. As a leader who sits between the development teams and higher management, I’ve seen how hard it can be to balance both sides. We as managers often want detailed control over our teams’ work because we are accountable for results, but I’ve found that this can really limit what teams can achieve.

For agile to really work, I’ve learned that we need to change our approach at all levels – from how we work with customers to how we let our developers make decisions. This means adjusting how our whole company operates. Without this broader change, we often create processes that look agile on paper but don’t actually help us work better.

Being part of the management team, I know we need solid evidence before changing something that seems to work ‘well enough.’ That’s why I started focusing on small but meaningful improvements that could show quick results. I often shared these wins, which helped build confidence for bigger changes. You can’t transform a company overnight – what worked for me was showing other leaders specific benefits for their areas, helping them see how these changes could solve their current challenges. This approach of gradual, proven improvements helped us build trust at all management levels.

Common Pitfalls and How We Overcame Them

The biggest challenge I faced was pushing back on starting with scrum training. It was hard to convince people this wasn’t the right approach. To address this, I created a workshop where we documented our specific goals and needs. This revealed contradictory priorities that we then aligned. Importantly, it helped us define a prioritized backlog of transformation actions to synchronize across the organization. This ensured everyone was on the same page about the plan and their roles. Next to that this makes it also obvious that generic Scrum training doesn’t actually solve our problems or move us towards our aims.

In the past, I made the mistake of not creating this comprehensive roadmap upfront. Instead, I jumped into action without fully aligning our goals across the organization. Now, I always start with a goal-setting workshop first. 

Another common issue is the tendency to transform others without transforming ourselves. Developers want management to change, while management wants developers to change – a classic chicken-and-egg. I found that cross-functional workshops to clarify goals and steps helped resolve this. My argument is that true agility benefits the entire organization in delivering better products, so everyone has a vested interest.

The Unexpected Benefits

Remember those skeptical faces in our first meeting? The developer focused on technical debt, another pushing for automated deployments, and our hardware developer who “hated” agile? Their initial resistance actually helped us uncover several surprising positive side effects of our transformation approach.

While better products and satisfied customers were expected outcomes of our agile transformation, I observed several surprising positive side effects. Though it’s important to note that agile isn’t always the best choice – its effectiveness depends on the specific situation.

Having worked with my team for years, I noticed a significant shift in their internal motivation and job satisfaction. As a former developer myself, I understand how rational developers typically are. When we created a work environment that made sense to them – where they felt heard and their work had clear purpose – their whole perspective on work changed.

One often unspoken benefit was how it helped management properly delegate tasks that had been overwhelming us before. By reducing micromanagement, teams finally had space to focus on what they were actually supposed to be doing. This shift didn’t just help the teams – it freed up management to think more strategically.

It’s crucial to understand that these benefits don’t appear overnight. In larger companies especially, it can take months to see real results. But the journey is worth it. Over time, we saw:

• Higher employee satisfaction
• More suggestions for company improvements
• Increased creativity, which opened up new market opportunities
• Better delegation and more strategic thinking at management level

The key lesson was that when you give teams the right environment and autonomy, the benefits extend far beyond just improved processes.

Key Takeaways and Future Outlook 

Personal Lessons Learned

Looking back at that room of skeptical faces three years ago, my biggest lesson wasn’t about agile frameworks or processes – it was about people. What I’ve learned is that true transformation starts by listening rather than pushing solutions. When that hardware developer showed me how he was naturally agile without using any formal “agile” terminology, it crystallized something important: effective change comes from understanding and building upon what already works well in your teams.

Another crucial lesson came from my early mistake of trying to force ideas onto teams before they were ready to discuss them. These days, I know better. Starting with those small, meaningful improvements and letting teams see the benefits for themselves creates genuine buy-in that no amount of formal training could achieve.

Starting Fresh Tomorrow

If I were to start a new transformation tomorrow, my first step wouldn’t be scheduling Scrum training or setting up boards. Instead, I would begin with what worked best in our journey: organizing those goal-setting workshops where we document specific needs and align contradictory priorities. This approach helped us create a clear transformation roadmap that actually addressed our real challenges rather than following generic frameworks.

Most importantly, I would focus even earlier on getting alignment across all management levels. As I learned, while development teams might be ready for change, the real challenge often lies in synchronizing the entire organization. Without this broader alignment, we risk creating processes that look agile on paper but don’t actually improve how we work.

Vision for Future Transformations

Looking ahead, I see agile transformations moving away from the current trend where companies automatically start with Scrum Masters and certifications. This approach, while popular because it’s easy to sell and follow, rarely addresses the actual needs of organizations.

Instead, I envision transformations that:

• Start with understanding each team’s unique way of working effectively, just as we discovered with our hardware developer
• Focus on solving real problems rather than implementing theoretical frameworks
• Allow for different approaches across different teams, recognizing that what works in one context might not work in another
• Give teams the space to develop their own effective ways of working, guided by principles rather than rigid rules

The future of agile isn’t about following a specific methodology – it’s about creating environments where teams can work efficiently their own way. As I’ve seen in our journey, when you focus on practical needs and let teams find their path, true agility naturally emerges.

What matters isn’t whether you’re following every rule in the Scrum guide, but whether your teams are delivering better products, feeling satisfied with their work, and continuously improving. Sometimes, as we learned, the most agile person in the room might be the one who claims to hate agile – simply because they’ve found their own effective way of working.

Real transformation takes time, especially in larger organizations. But by focusing on actual needs rather than theoretical processes, and by involving all levels of the organization in the journey, we can create lasting change that goes beyond just adopting new terminology or following new procedures.