Leadership and Agile Core Values Over Frameworks

Before I start, you know when you leave a good meetup, you should always feel like you've grown a little. Yesterday, I wanted to thank you all for the great speeches and insightful conversations. This might seem like basic knowledge, but I hope my presentation will show that it’s not always the case. When it comes to leadership and agile core values, they are often not practiced, or at least not consistently.

I could introduce myself, but I guess that’s not of much value. So, I’ll just say—trust me, I’m certified. Instead, I think it’s more valuable to introduce the company I work for.

About the Company

I work for the Association of Private Health Insurance Companies in Germany. Yesterday, someone in the audience said it sounds more like an explanation than a company name—and in a way, they’re right. We represent all 41 private health insurance companies in Germany, covering about 10% of the overall market (as the rest falls under governmental health insurance).

What do we do? We help these companies generate knowledge, advance their business, and yes, there is some lobbying involved. But more importantly, we run central IT services for them. Whenever it makes sense to implement something centrally rather than having each company do it independently, we take on that responsibility—such as statistical data transfer and other shared services.

Founded in 1947, we’ve been around for a long time, which means we’ve accumulated a lot of hierarchy and command-and-control structures. Keep that in mind as I continue.

My Journey in IT

I’d like to take you on a small journey through some insights I’ve gathered in my years in IT. I ran my own company for 10 years before switching to the insurance sector, where I held various management positions—head of software development, head of project management, and head of IT. Over the years, I’ve seen and experienced quite a lot.

Time Warp to 1998

In 1998, I founded my first company during the era of blinking web pages—if you’re old enough to remember. I thought, “Surely, we can do this better.” That was the start. Over time, customers wanted network infrastructures, so we did that. Then they needed software, so we did that too. It was traditional, linear software development.

At one point, we realized there must be a better way. That was in 2005, when we decided to transition to Scrum. It was a once-in-a-lifetime opportunity to do everything wrong for the first time. We were crazy enough to try this transformation with our biggest customer and our biggest project. We thought, “Let’s show them how good and innovative we are.”

At that time, we had no real understanding of agile values, little knowledge about agile leadership, and only basic knowledge of frameworks. We had read the Agile Manifesto, but we weren’t truly practicing Scrum—we had ScrumButs, but we were doing anything but Scrum.

Lessons from Failure

We quickly learned that failing fast is valuable. But because we attempted this with our biggest customer and our biggest project, we failed hard. This is highly optional—I wouldn’t recommend it!

After that experience, I continued working in different environments and learning from different projects. Then, in 2011, I transitioned into the insurance sector, where we attempted another transformation.

Time Warp to 2011

By 2011, I was in the insurance industry, and we tried to transform development teams using Scrum. With several years of experience, we thought it would be easier this time.

We did all the “right” things:

• Ran training for the team.
• Integrated experienced Scrum Masters.
• Provided constant coaching with an agile coach.
• Involved the customer early.

What could go wrong?

Despite all of this, we still had limited knowledge about agile values. Our agile coach wasn’t focused on coaching values, and while we had some understanding of agile leadership, we weren’t actively fostering it. We thought we were doing everything right.

The result? Low velocity, constant impediments, and a textbook Scrum process with no real improvement. After two years of pain and struggle, we finally reached a point where the team truly worked in an agile way—but it showed us that without the right foundations, adopting frameworks leads to trouble.

Time Warp to 2016

In 2016, we prepared for an agile transformation at the Association of Private Health Insurance. This time, we wanted to get things right.

Key Learnings for Transformation

1. Start with Leadership

We chose a top-down approach. The first layer of management had to be the first to transform. The general management was involved from the start, which was critical.

2. Develop Employees First

Many assume that IT teams naturally have strong conceptual abilities and organizational skills—but that’s not always the case. If you throw people into an agile transition without preparing them, they enter an unknown world with fewer skills than they need.

We created structured, interdisciplinary teams that weren’t agile yet but were designed for an easy transition. We selected socially intelligent leaders to guide them, ensuring that when they eventually transitioned, they were already in a self-organized structure.

3. Transparency Builds Trust

We were operating within a traditional hierarchical system, but instead of treating it as a problem, we used it as an opportunity. Many employees were fed up with the old system and welcomed change—but trust had to be earned.

To ensure transparency, we made management meeting notes publicly available in real-time using OneNote. Employees could see discussions as they happened. This created the first container of trust, showing employees they weren’t being left behind.

The Importance of Agile Values

If you don’t understand agile values, you don’t understand agile leadership. And if you don’t understand agile leadership, you won’t successfully implement agile frameworks.

People must be able to reflect on themselves, adapt, and leave their comfort zones. But they must leave it comfortably—you can’t force people into change and expect them to thrive.

We certified our leadership team with the Scrum Alliance’s Certified Agile Leadership program, which included a two-day deep dive into leadership topics followed by months of guided leadership challenges. This wasn’t a business-oriented certification—it was focused on emotions and values, fostering true transformation.

Agile Frameworks Come Last

After ensuring that employees and leadership were ready, we moved to agile frameworks.

In IT, our network and server teams now work in weekly iterations, using standard planning and review rituals. Next, we aim to synchronize iterative approaches across the entire unit, integrating customers early.

Beyond IT, we extended the agile transformation to HR, finance, and central purchasing. While we haven’t yet tackled financial planning, we’ve introduced Kanban boards across multiple departments, fostering transparency and collaboration.

Measuring Success

We measure success through biannual customer satisfaction surveys and regular one-on-one feedback meetings with employees. Our survey results show clear improvement, reflecting the benefits of integrating agile values and processes.

Final Thoughts

The key lessons from our journey:

• Train employees before starting the transition.
• Develop a deep understanding of agile values.
• Foster agile leadership before implementing frameworks.

By following these steps, we believe we can achieve healthy, sustainable growth in our transformation.

Thank you for listening. This has been my agile journey with key milestones along the way—and the journey continues!

“The only way to make sense out of change is to plunge into it, move with it, and join the dance.” – Alan Watts