Michael Palzer

Hello everybody. Hello from Hamburg.

Welcome to our session, Escaping the Feature Factory: Our Journey into Thinking Continuous Delivery End to End.

My name is Michael, and I'm responsible for the business part of our digital product.

Stephan Stapel

And my name is Stephan. I'm representing the tech side of digital product.

Michael Palzer

Together, we share the same vision on how we want to work, and the same spirit to move our company forward. We would like to inspire you for your way and spotlight some of our key factors.

Let's have a look on the next 30 minutes. We will start with some facts to understand our starting position, then our view of idea to impact. After that, we look at the new needed mindset in the organization and finally, our learnings.

The Hermes Group is the largest post-independent parcel company in Europe, focused on the large countries like UK, France, and Germany. Hermes Germany is located in Hamburg, and we deliver more than 400 million parcels per year.

Where we come from: our company is no startup. Founded in '72 in Hamburg, almost 50 years ago, we have, maybe I should say had, a traditional understanding of organizations. And as a logistic company, we are focused on process optimization. And of course, it's necessary for a company like ours, especially if you want to deliver up to 2 million parcels a day.

But with logistics coming first, customer definitely came second in our industry, and for Hermes as well for a long time. We are on the right way, but still have a way to go.

Before going into details about our journey, a small side note. We learn a lot from books and conferences, like probably all of you too. Here you see some of the books and authors that inspired us. This is true, for example, for MVPs, Project to Product, push to pull, or lean management. We use most of these approaches in our organization, but will not cover them in detail today.

Instead, we want to give you a general introduction to our transformation, highlighting the fundamental ideas behind it. We want to share with you our experience digging our way through a large, mature organization.

Stephan Stapel

One important aspect of this implementation is how we optimize our value stream to make our customers happy. But before stepping into our current activities, let's do a time warp back to 2011, for what we call the dark age of IT.

Like many companies, Hermes tried to optimize the IT function for cost and planning reliability. So it was decided to organize IT as a shared service provider within the company. That resulted in odd ideas like company-internal billing for IT projects.

In the end, cost optimization might have succeeded. However, the drawbacks were far bigger. First of all, we as IT were clearly separated from the business. There was no alignment between, and even worse, IT had no idea about the customer.

Fortunately, the idea of being a service provider died in 2015. Since then, we are re-engineering tech and the corporation, optimizing for what we call idea to impact.

Our organization looked like a walled garden in that dark age. Each step in the process siloed into a dedicated department. Usually, every department had its own agenda.

As a fun fact, agile was introduced already 10 years ago at Hermes, right in the middle of the dark age. They introduced the Scrum framework in the development teams, but everything else was left untouched.

This is what the value stream looks like as a process. Each step is siloed. Clearly, the good thing is that each step can get optimized. Unfortunately, all optimization is local only. Nobody takes the entire process into account. In the end, we have no enhancements in terms of innovation, speed, or quality.

So what is the best testing in the world worth if you don't ship the right product, or if you don't ship things fast enough?

We had what is called activity-based working. But even worse, with the new agile approach in place in the development, we had no common understanding on the ways of working, so conflicts arose between development and the other areas in our value stream.

And when the shared service provider idea died, we took our chances. We moved from local optimization to value-stream optimization and gradually got better and better.

Since Scrum was then already well-established in the development teams, we used the development as the epicenter and gradually expanded the agile principles into the other steps of our value stream. It was important for us to do this very carefully, step by step, to secure the success during progressing.

By creating an understanding for each other, we closely aligned each step of the value stream. And all of a sudden, for the first time in our organization, we had flow. That was a great feeling and it encouraged us to go further.

So while agile taught us a lot about culture, and it gave us a new understanding about work and collaboration, and it allowed us to cope with new levels of complexity, the DevOps principles, on the other hand, helped us a lot to align the different disciplines with each other.

Let's take a closer look. DevOps is, for us, an important complementary concept to agile, and it teaches us a lot about outcomes of our value-stream optimization.

We very much stick to Gene's definition of the Three Ways. The first way, to optimize for the whole system, was the largest leap for us. Blending the steps of the value stream, which I showed you in the previous slide, led to a consistent flow.

Let's consider infrastructure as code as an example for this. By applying development approaches to infrastructure, we revolutionized the way we do ops. We not only streamlined infrastructure provisioning, but we also made it impossible to distinguish dev and ops in the end.

Mastering the first way led us from slow activity-based working, dating back from the dark age, to delivering outputs fast and repeatable. The understanding of the whole system allows us to constantly change and optimize it, which makes the second way.

And concerning the third way, with now five years since the dark age, it was even possible for us to establish a tech culture in our company. This, in turn, allows us to do frequent experiments and learn from them. The most difficult part of the third way, however, is to interpret failure as a gift. We are not there yet, but we are constantly progressing towards it.

Michael Palzer

Getting rid of the walled garden helped a lot, but our view was still limited, focusing on delivering only. We did not want to stick with output; we aim for the outcome. Also, therefore, we added ideation, bringing business and tech people closer together.

This allowed us not only to take technological limits when thinking about new products and services, but also to leverage technological possibilities to make our products and services better.

We started the joint approach by not taking a look at what a dev team delivers. We focus on what is live and available for the customers, measure the usage, get feedback from the customer, and iterate the product to reach the outcomes.

From this point, we have the flow for new products to generate benefits for our customers: the first flow ever between business and tech. And to aim the entire value chain was one of the boosts for our transformation. We did this transformation simultaneously to the DevOps transformation, which was tough. However, it turned out that each approach only made sense with the other.

And with entire, we really mean entire. In the current step right now, we expanded our idea to the strategy to have a consistent flow between the top corporate management and the initiatives of our product teams. Here we use a variant of the three-stage flight levels from Klaus Leopold. We are in the sixth iteration and still learn and improve our processes.

And we have the next step in mind. We did some basics already, like methods, mindsets, and language, and are looking forward to introducing a comprehensive sales board and another second-level coordination board.

Yesterday, we had silos. Today, hopefully not again. But focusing teams on a particular product comes with a price. The stronger the focus is on a particular product, the more difficult collaboration gets across product-team boundaries.

And how to prioritize: EBIT or customer satisfaction, sender or receiver, business or private customer? And you really have to take care that you need actively to recreate a culture of collaboration, and also establish new formats for coordination for the teams and collaboration across the teams.

The improvements we achieved helped everyone to focus to deliver more suitable products for our customers faster and better than ever before.

Stephan Stapel

So we revolutionized our ways of working. This was a huge step, and it resulted in delivering more and better than ever before. This was only possible because of our people. We are so lucky to have such great teams. They are a big part of the success we have together.

So optimizing processes clearly isn't everything. Together, we had to redevelop ourselves a lot. We had to let loose of old habits and find new ones. This is especially true for our understanding of roles and ways of collaboration.

So in traditional companies like ours, Taylor's organizational principles are still very well alive. They are the foundations of role definitions and collaboration within the company. Taylor's idea was to divide work in distinct units to make it more controllable. That probably worked great in environments with simple work, where it was necessary to optimize the working steps, which were repeated and repeated all over.

Unfortunately, these principles survived this era and are still present in today's knowledge-worker environment. This is also true for our company. So we had large lists of roles and responsibilities. Unfortunately, this type of definition tends to clearly define segregation between the roles, but leave out collaboration almost completely.

So when developing our organization, we really had to focus on the collaboration between the different roles. And it was even important to blend the roles with each other.

We started with the most common roles like developer and tester. There was still a big challenge since people were well trained for the respective roles and its boundaries. But in the end, we succeeded.

People with different roles started to understand each other. This allowed us to start overcoming the walled-garden principle, and letting people with different expertise work together on the same topic yields surprising results.

Let's take testing as an example. Testing was a bottleneck in our value stream for a long time, like it is in probably most of the companies. And bringing together developers and testers allowed us to innovate quickly on how we test. One improvement was fostering test automation, but also a more efficient interpretation of the test pyramid helped us a lot.

Implementing these and other measures, the bottleneck just vanished. And even more, testing became an attractive discipline.

Michael Palzer

And when we're looking at a general aspect, one of the key factors is to bring tech and business together. Closing the chasm, which had grown over the last years, is one of the most important steps, and balance them to yield the outcome of your agile setup.

The basis is the general understanding of each other, the outcome, complexity, possibilities, and dependencies. And in specific, you have to have a general understanding of processes, method, mindset, and have the same language. And together, the key is the relevance, the synergies, the trust, and the need for a future-orientated agile setup.

So we installed a duo, which was responsible for the entire digital product: one more business-orientated, aligned with the customer, and understands the technologies; and the other, more technically orientated, aligned with the tech, and understands the customer.

Both have to make a step towards each other and find a common way for processes, for methods, for the same mindset, and for a common language to work together. And both have to learn from each other to have the same understanding of tech and the customer.

Here, you have to take care to promote the cross-pollination to reach a higher level. It's a way, but we will see the benefits quickly on all levels. But the environment is still complex, and we will still need both roles.

If you're looking at the development of the entire organization, yesterday, which you can see on the left side, tech and business were divided by the chasm, and the higher management were part of the product development and dropped ideas and features and decided in the steering committees about the product that will be shipped.

In the current setup, which we can see in the middle, we connect tech and business. We rebuild by reconnecting roles together. And to enable the agile team, it's important that management let loose of the product details and focus on strategy and outcome.

And today, the agile team has full responsibility and are able to iterate the digital product for our customers. For tomorrow, we expect a further evolution of the roles and mindsets across all levels.

One part which is really important is when you build up a part of the organization which will agile construct and generate first outcomes, one issue you have to care about is to protect the flow against the old ways of thinking. Sometimes it's really hard and lasts for a while, maybe for years, but it's worth it.

And you have to think: you have to manage two sides of the same coin. First, you enable the agile team to generate outcome in the agile framework. They are responsible, focused on the customer, outcome in mind, and aligned with the strategy. And on the other hand, the other side of the coin, you have to manage your management, which is still in the old framework with an old mindset.

You have to play this old game. But that generates the time you need to learn, improve, and generate success stories which are seen by the management. And then reach the point, maybe it's a tipping point for the transformation, to explain the agile framework to other parts of the organization, expanded horizontal and vertical.

Stephan Stapel

So we dug deep into our transformation of processes and roles. Also, we introduced you about how we handle the transformation in our organization. Let us conclude with some general learnings we had on our journey.

Some of these learnings are about a new understanding of organizations we found, while others highlight some aspects of change that are important for us leading the transformation.

First of all, we learned a lot about organizations. Organizations try to resist change. There's a rationale behind each organization and why it was established, and so it tries to preserve its current state and ways of working.

Changing things does not only lead to resistance. We even observed envy and reluctance in other parts of the company. Don't let that stop you.

And even though we are convinced about our approach, we learned how to protect our success and not try to convince everyone in the company to follow on the same ideas and ideals. But what we found to be important is to facilitate between our approach and other approaches in our company. In short: live and let live.

On the other hand, applying agility or DevOps by the book is impossible. Also, even if you adopted these approaches to your organization, the implementation path may change. No, it will change, and it will change constantly. It's good to have a vision. It's good to have a plan. Make sure to remain flexible enough to change it, to adapt it.

And last but not least, the change itself takes a lot of energy. Not only is it hard to imagine new ways of working, it's even harder to convince our people to follow and upper management to support us. Unfortunately, it also takes a long breath until the benefits become clear. With impatience being a natural part of every organization, we need to frequently explain and even ring-fence our work.

That's the reason why it's important for us to do the change together. With a collective vision, joining forces gave us the necessary power.

With these words, we would like to conclude. We hope you liked our presentation. We hope that we encouraged you to drive change further in your own organizations. The effort is definitely worth it. Good luck, and goodbye.

Michael Palzer

Goodbye.