The following article was co-authored with Martin Milcke (CIO of Mercedes-Benz Sales Germany) and originally published on the Thoughtworks Insights Blog.

The debate over software development methods is settled. The agile organization is on the verge of establishing itself as the dominant organizational form. The current literature on agile software development makes this clear — both empirically and theoretically. (In [1], Forsgren, Humble, and Kim provide rigorous evidence for the link between agile/DevOps methods and business success. In [2], D. Reinertsen presents the underlying principles.) And yet this knowledge alone is not enough when it comes to actually transforming organizations to become agile or digital.

In our two-part series, we show how we use agile methods and ways of working in a real client project — “One Touch Retail” (OTR) — to drive the digital transformation of the automaker Daimler. We want to encourage others to tackle the challenges of digital transformation, because the results are worth it. Alongside the difficulties and obstacles, new capabilities are developed and value is created through the transformation. And once you have truly worked in an agile way, you really can’t go back.

Overview

In this multi-year transformation project at Daimler, we learned that we had to tackle multiple paradigm shifts simultaneously — agile software development, DevOps, design thinking. This required strong management support. We structured our project setup differently in many areas and used modern infrastructure and governance tools — cloud and lean PMO, for example. Ultimately, we built a feedback-centric environment that allows us to respond to new requirements extremely quickly while developing a product our users will love.

Our key insights from the transformation project:

• Unlearning what you know and fundamentally changing your daily way of working takes real courage — from everyone involved.
• Start small. We started fast and very small, then scaled.
• In digital transformation, applying agile principles takes center stage — not rigidly following a specific methodology.
• Using commodity infrastructure makes us faster.
• Self-organizing, cross-functional product teams are central.
• We achieve greater effectiveness through offshore teams treated as equals.

Paradigm Shifts

Digitalization is not just a technical transformation. It demands sweeping, multiple paradigm shifts — a rethinking across many areas. Moreover, this is not a one-time activity or learning experience, but an ongoing change in deep-rooted thinking patterns and daily behaviors. We see five distinct paradigm shifts:

1. From waterfall methodology to agile software development
2. From project to product
3. From development and operations to DevOps
4. From requirements analysis to design thinking
5. From IT service management to focus on business value

It makes sense to tackle these paradigm shifts simultaneously — even if this may seem paradoxical from a change management perspective: it is well established that too many simultaneous changes in an organization can lead to Organizational Change Fatigue (see [3]). The reason is that many of the practices and architectures on the right-hand side complement and support each other. At a fundamental level, these paradigm shifts require a culture of openness, trust, sharing (of responsibility, for example), humility (not needing to know everything as a subject-matter expert, for instance), and inclusion.

“One Touch Retail”

The OTR project is a multi-year digital transformation within the framework of the Daimler Best Customer Experience Initiative (see [4]). Daimler commissioned us to co-develop an innovative, intuitively usable digital assistant for salespeople, with the goal of replacing the legacy system. The intention is to make the sales process more attractive, while enabling Daimler’s salespeople to focus even more on their customers. The new platform, OTR, is also designed to be flexible enough to respond to the changing demands of the automotive market.

A global team, distributed across Germany, India, and China, is working on the new sales assistant. The German team is developing the system for the German market, working closely with colleagues in the Indian development centers. At the same time, the Chinese team is developing a similar assistant tailored specifically to the Chinese market (see [5]).

Changing the Status Quo

With OTR, we are implementing Daimler’s IT strategy across many areas. We increased the frequency of software releases from one deployment per month to multiple deployments per day into the production environment — a continuous process (Continuous Delivery). The IT architecture was migrated from an n-tier approach to a microservice architecture; the infrastructure shifted from on-premises installation to cloud-based components. Previously manual tests were replaced by fully automated tests, which ultimately made a continuous deployment process possible. This meant a complete turnaround from waterfall methodology to agile software development with DevOps methods. We now use free and open source software (FOSS) instead of proprietary solutions. Rather than a clear separation of business and IT functions, we rely on the closest possible integration through cross-functional product teams.

Daimler in Transition

One of the most important — and most difficult — aspects of digital transformation is establishing a new work culture. Daimler is currently transforming from an automaker into a provider of mobility services. This has direct implications for our work on the OTR project. Calls for higher speed, faster learning, and agility — under the banner of “#TwiceAsFast” ([6] and [7]) — are moving to center stage. Behind this is the recognition that in the automotive industry, customer value — particularly in the area of Mobility as a Service (MaaS) — can be decisively improved through digital products. Product quality, however, is determined by the capability and speed to adapt to new customer needs and learn from customer behavior.

We see modern software technology as a driver of innovation. Accelerating the development process and shortening and evaluating feedback cycles is our primary focus. This capability is precisely the foundation for micro-innovation (in [8], D. Newman shows the advantages of micro-innovations over macro-innovations).

Here too, we see a paradigm shift: while at the start of the OTR project we often encountered the attitude “We know exactly what our users need — we’ve been doing this for 20 years,” we increasingly adopted design thinking methods. We began conducting regular user and customer research, and developed a new openness and the recognition that we simply cannot know all needs in advance (see [9] on the concept of Shoshin, or Beginner’s Mind, used in design thinking).

The 4 Catalysts of the Daimler ITS Strategy

This design thinking paradigm shift is supported by four identified catalysts:

1. Radical process simplification reduces complexity and duplication of activities, enabling simpler processes to be more strongly automated.
2. The focus shifts from the project to the actual product. The goal is to use data to reduce costs, increase revenue, and build proprietary intellectual property and a user base.
3. Use speed as a strategic advantage — for example, through Continuous Delivery to incorporate customer needs into your products in a timely way.
4. The organization should fearlessly question existing rules and processes, and actively learn from mistakes and feedback.

With the shift in emphasis from project to digital product, the IT organization’s self-understanding also changes — away from a service provider in the IT Service Management sense (see ITIL [10]), toward true collaboration at eye level (see [11]). In the OTR project, we experience this daily in cross-functional teams: business product owners and IT product owners work together on initiatives, contributing their perspectives and capabilities as equals.

We are also implementing further elements of the Daimler strategy consistently in the OTR project:

• Use of free and open source software
• Cloud-based operations enabling DevOps
• Implementation of microservices accessible via API
• Working in dynamic swarms
• Use of Daimler standard security providers

All of these project components contribute directly to the Daimler IT strategy.

In the OTR project, we are implementing the Daimler IT strategy consistently.

Ways of Working

From the beginning, our goal was to create a working environment for all team members that allows everyone to make mistakes in a controlled way and learn from them (see [12] for a solid explanation of the Kaizen culture). This openness to failure works on two levels: first, it promotes learning and innovation. Second, it makes it easier to introduce new practices — for example, agile ones — by experimenting: formulating hypotheses, running experiments, measuring success or failure, and then potentially pivoting. Here too, we apply the principle of small batch size — we make many small changes to our way of working regularly, rather than designing a new approach in exhaustive detail, aligning it, and rolling it out through change management activities. The principles of agile ways of working can thus also be applied to executing the paradigm shifts themselves.

Questioning fundamental values and ways of working, and unlearning established practices, demands enormous effort. The following circumstances helped us tackle the transformation:

• The automotive industry is undergoing fundamental change (see e.g. [13]). The underlying social, technological, and economic upheavals are now so present in public discourse that the need to act is obvious. While this change poses a challenge — or even a threat — on one side, it also makes it possible to mobilize energy for change initiatives on the other.
• At the start of the OTR project, we found a great openness toward agile methods and the paradigm shifts described above. Even during the initial two-week inception phase, we repeatedly heard the motto “Trust the Process.” This reflects the good faith that Daimler project staff — most of whom had little prior experience with agile methods — extended to us.

Openness, transparency, regular retrospectives, and the ability to put difficult topics on the table help us maintain and build on this trust, while keeping the momentum of change alive.

Retrospective

Team Setup and Capabilities

Developing digital products draws on a whole range of capabilities that teams and organizational units need to master. Simply introducing Scrum is nowhere near sufficient to successfully implement agile methods in software development. Beyond the established agile development practices, you need test automation, Continuous Delivery, microservices, infrastructure as code, and more. Add to this design thinking and DevOps. To get a picture of these capabilities within the team, we structured them into the categories: organizational design, product design, technology, strategy, and culture (in [14], D. Frese suggests TOPS — technology, organizational design, product design, strategy, and culture; in [1] we find a classification into Continuous Delivery, architecture, product and process, lean management and monitoring, and culture). The diagram below shows a selection of the most important capabilities. Many of them support each other — or amplify the positive effect of the others. (In [15], Martin Fowler notes: “all of this stuff flows together. The most important thing about Extreme Programming is that the individual practices of Extreme Programming reinforce each other”.)

A few propositions to illustrate these relationships:

• For teams to work autonomously, the required capabilities — and therefore the people — must be present within the team. This inevitably leads to cross-functional teams.
• Scaling agile product teams requires reducing dependencies between teams. Microservices can help strengthen team autonomy.
• Running and operating a microservice architecture presupposes command of capabilities such as automated deployment pipelines (CI/CD), infrastructure automation, monitoring, and so on (see M. Fowler [16]).
• Hypothesis-driven development depends on the ability to be wrong. A safe working environment is necessary for this.
• Design thinking requires creativity, which in turn can benefit from diversity.
• Implementing agile principles requires test automation — frequent deployments are not achievable with manual testing. This is supported by implementing a test pyramid (details in Hermann Vocke [17]).

Overview of mutually reinforcing capabilities

In the OTR project, we use this interplay of capabilities and have implemented nearly all of those shown in the diagram above.

Agile software development is therefore only a small part of the capability spectrum employed by today’s leading software-focused organizations. Organizations at the beginning of their digital transformation therefore need outside support. For us, a training course or coaching program is not the primary answer. Our experience has shown that paradigm shifts can be implemented faster and more effectively through real project work. The key is to involve project staff who already live these principles and capabilities.

Living Agility

According to a McKinsey survey [18], agile software development has now become standard practice. Martin Fowler [15], Thoughtworks Chief Scientist, supports this view and simultaneously reports on a phenomenon he calls Faux Agile. Others call it Fake Agile (see [19]) or Cargo Cult Agile (see [20]). The authors often encounter situations where teams proudly claim to be working according to agile methods — but in reality, what they are describing is often far from what Ron Jeffries describes as Dark Scrum (see [21]), in the positive sense. We therefore want to be clear: assigning Scrum roles, maintaining a backlog, organizing daily standups, and working with stickies is only the beginning. We believe it is more important to focus on the agile principles (see [22]) than to rigidly follow methods such as Scrum, Kanban, or — even worse — SAFe. By that we mean principles focused on value creation for customers, and self-organizing, cross-functional, autonomous teams that deliver working software regularly and in short cycles.

A fundamental principle is giving individual teams the freedom to decide for themselves on specific ways of working, tools, or even programming environments within certain guardrails. This is facilitated in particular by the microservice architecture (see [23]). In our OTR project, some teams use Clojure, for example, while others use Kotlin as a backend programming language. Some teams work in two-week sprints; others follow Continuous Delivery principles or Kanban. Some teams estimate user story size using story points; others take a NoEstimates approach.

We are convinced that development speed can be increased with this kind of freedom. Daimler’s approach of using free and open source software (FOSS) more extensively also has a positive impact here (see [24]).

Another principle is the continuous adaptation and development of ways of working. We can see this in the following observation: we regularly demonstrate our way of working to interested colleagues from Daimler. Week over week, we see changes on our office walls — the structure of the Kanban board has changed, the roadmap has replaced the Lean Value Tree, the skills matrix wasn’t there last week, and so on. (Note: We use our office walls as so-called Information Radiators — large surfaces to display information visually and interactively; see [25].)

One outcome of this fundamentally changed approach is, for example, the go-live — or as we call it, the handover. Many of us know this as a nerve-wracking event that regularly takes place over weekends or overnight, in order to schedule the required downtime during periods of low application usage.

In our OTR project, we handled the application handover as a non-event. We simply enabled users in the application and notified them by email. This is possible because the application is practically always available in the production environment through the Continuous Delivery approach (see [26]). The handover of additional functionality follows the same logic: we enable new components using so-called feature toggles (see [27]) and then inform users accordingly.

Summary and Outlook

In Part 1, we identified the paradigm shifts of digital transformation, explained the case study — our One Touch Retail (OTR) project — showed how Daimler is approaching the change, discussed agile ways of working using the case study, and examined how we can avoid Faux Agile (Fake Agile or Cargo Cult Agile).

In Part 2 we want to go deeper: clarify the role of management, present examples of work in cross-functional teams, discuss ceremonies, explore the contribution of diversity in finding creative solutions, introduce another paradigm shift in the area of customer centricity, and provide an outlook on the further course of digital transformation. Part 2 will appear in mid-March.

References

[1] Nicole Forsgren, Jez Humble and Gene Kim: “Accelerate”, IT Revolution, Portland, 2018
[2] Donald G. Reinertsen: “The Principles of Product Development Flow: Second Generation Lean Product Development”, Celeritas Publishing, Redondo Beach, 2009
[3] Wikipedia: “Organizational Change Fatigue”, https://en.wikipedia.org/wiki/Organizational_change_fatigue
[4] Daimler: “Best Customer Experience 4.0” – Press Presentation in The Hague: Kick-Off for the luxury experience 4.0: Mercedes-Benz presents the next chapter of the global sales strategy “Best Customer Experience”, https://media.daimler.com/marsMediaSite/ko/en/43937825, 2019
[5] Thoughtworks: “Innovative software development for the sales experience of the future”, https://www.thoughtworks.com/clients/daimler, 2017
[6] Jan Brecht: “My top three IT priorities at Mercedes-Benz to focus on in 2018”, LinkedIn, https://www.linkedin.com/pulse/my-top-three-priorities-mercedes-benz-focus-2018-jan-brecht/, 2018
[7] Jan Brecht: “#TwiceAsFast: How to build a learning based culture”, LinkedIn, https://www.linkedin.com/pulse/twiceasfast-how-implement-learning-based-culture-jan-brecht/, 2019
[8] Daniel Newman: “Why Micro-Innovation should be at the Core of your Digital Transformation”, Forbes, https://www.forbes.com/sites/danielnewman/2016/02/02/why-micro-innovation-should-be-at-the-core-of-your-digital-transformation/#5405b0837684, 2016
[9] Jesse Russel Morgan: “Beginner’s Mind in UX Design”, https://uxdesign.cc/beginners-mind-in-ux-design-with-shunryu-suzuki-11a00787c8a9?gi=f923553c2102, 2018
[10] Wikipedia: “ITIL”, https://en.wikipedia.org/wiki/ITIL
[11] Mark Schwartz: “A Seat at the Table: IT Leadership in the Age of Agility”, IT Revolution, Portland, 2017
[12] David J. Anderson: “Kanban, Successful Evolutionary Change for Your Technology Business”, Sequim, Washington, 2010
[13] McKinsey: “Automotive Revolution – Perspective towards 2030”, https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/disruptive-trends-that-will-transform-the-auto-industry/de-de, 2016
[14] Dino Frese: “How modern IT is like Tetris and how TOPS makes sense of everything”, Thoughtworks, https://www.thoughtworks.com/insights/blog/how-modern-it-tetris-how-tops-makes-sense-everything, 2018
[15] Martin Fowler: “The State of Agile Software in 2018”, https://martinfowler.com/articles/agile-aus-2018.html, 2018
[16] Martin Fowler: “Microservices Prerequisites”, https://martinfowler.com/bliki/MicroservicePrerequisites.html, 2014
[17] Hermann Vocke: “The Practical Test Pyramid”, MartinFowler.com, https://martinfowler.com/articles/practical-test-pyramid.html, 2018
[18] McKinsey: “How to create an agile organization”, Survey, https://www.mckinsey.com/business-functions/organization/our-insights/how-to-create-an-agile-organization, 2017
[19] Steve Denning: “Understanding Fake Agile”, Forbes Media, https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#35870f914bbe, 2019
[20] Wikipedia: “Cargo Cult Science”, https://en.wikipedia.org/wiki/Cargo_cult_science
[21] Ron Jeffries: “Dark Scrum”, https://ronjeffries.com/articles/016-09ff/defense/, 2016
[22] Agile Manifesto: “Principles behind the Agile Manifesto”, https://agilemanifesto.org/principles.html, 2001
[23] Sam Newman: “Building Microservices”, O’Reilly Media, Sebastopol, CA., 2015
[24] Torben Stephan, Ludger Schmitz “Interview with Vlado Koljibabic, Head of CASE IT at Daimler”, Data Center Insider, https://www.datacenter-insider.de/wir-kennen-die-vorteile-von-open-source-a-708188/, 2018
[25] Kasandra Fcong “Transform Meetings with a Great Information Radiator”, Thoughtworks,  https://www.thoughtworks.com/de/insights/blog/transform-meetings-great-information-radiator, 2016
[26] Jez Humble and David Farley “Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation”, Addison Wesley, 2011
[27] Pete Hodgson: “Feature Toggles (aka Feature Flags)”,  https://www.martinfowler.com/articles/feature-toggles.html, 2017go

After childhood, I stopped drawing. A few years later, I got interested in presentation technique — how to move away from the same old, boring, overloaded PowerPoint slides. Along the way, I kept reading about visualization and sketching, and thought: “This can’t be that hard — I should be able to learn this too.” I read a lot of books on visualization and eventually came across UZMO. A brilliant name. Try Googling it. Or check out this video by the author Martin Haussmann.

I started visualizing using the UZMO method, and with some practice at the flipchart and daily sketchnotes, I fairly quickly became the one-eyed man among the blind. I scanned many of my results and built up a collection over time — useful for quick insertion into PowerPoint, for example. I don’t always have a flipchart available. When working remotely especially, I like to draw on the collected sketches. I’m happy to share part of that collection here for download and your own use. Enjoy!

A Few Examples

A few examples from the collection:

• why this can be worth doing,
• when an internal podcast makes sense, and
• how to create one.

Content

• Intro
• What are the advantages of an internal corporate podcast?
• How do I prepare a podcast?
• What technical equipment do I need?
• How do I conduct the interview?
• What software do I need for post-production?
• Which filters and compressors do I need, and in what order?
• How do I publish the internal podcast?

Notes and Links

My doctoral dissertation was on the topic of “Integrated Simulation.” Together with Dr. Ingo Meents, I co-authored the first joint dissertation at TU Clausthal.

The dissertation was awarded the Förderpreis of the Freunde der TU Clausthal. The laudation was delivered by Ekkehard Schulz (at the time CEO of ThyssenKrupp AG).

Below you will find further information about EPOS and the dissertation:

• Dissertation “Integrated Simulation – Optimization Strategies and Logistical Control for Production Planning Based on Calloboratively Maintained Queueing Models“
• www.integrierte-simulation.de (links to the Stochastics pages of TU Clausthal)
• EPOS (Enterprise Production and Optimization System)
• Report on the award of the TU Clausthal Förderpreis

 

Summary / Abstract

Analyzing queuing models to answer questions of tactical production planning for large and complex manufacturing systems is not possible without supporting IT systems. The established mathematical models provide approximations of performance metrics such as utilization, inventory levels, and throughput times. Creating and maintaining the required queuing models for hundreds of workstations and thousands of operation sequences — connected through complex process flows — presents a significant challenge. The Integrated Simulation model is the theoretical foundation for building software systems that enable the efficient creation and maintenance of large models through distributed responsibilities. Integrated Simulation describes the import of data from line control systems and the automatic generation of queuing models from databases containing all data relevant to planning. The automation of data acquisition, the analysis of queuing models, and automated reporting enable continuous support of planning processes — even in constantly changing production environments.

Simulation and analytical performance evaluation allow the investigation of a priori defined scenarios. To find improved or even optimal parameter sets, optimization methods that can use automatically generated models are presented. Three distinct problems and their corresponding solution approaches are examined. First, the optimal product mix problem is extended to include the requirements of Integrated Simulation. A quadratic program for determining the optimal routing probabilities — which are not fixed during model generation — is then formally derived. Finally, evolutionary algorithms that use the performance metrics of queuing models as constraints or objective functions are developed.

When simulation is used as an ongoing process in production planning, integration with existing line control systems allows for the creation of operational plans, problem detection systems, and systematic validation of the simulation models used. Applications arise from comparing measured performance metrics with the production targets derived from simulation. Statistical tests, visualized through quality control charts, must be applied. Challenges arise from the autocorrelation in the logistical processes under consideration and from the number of possible charts. As a further application of integration with line control systems, a forward propagation of current inventory based on approximated remaining throughput times is presented.

To investigate the practical applicability of the proposed architecture and algorithms, a system was developed that is now used for the simulation of five production lines of IBM Deutschland Speichersysteme GmbH at three international locations. It has been shown that only the proposed holistic approach — that is, the integration of all required processes — enables the successful application of analytical performance evaluation to real-world problems.