Jeff Gothelf (of Lean UX fame), my colleague Sylvia Le Hong, and I joined a webinar to explore how Personal Growth, Cultivation, and Digital Transformation connect. The webinar (in English) was moderated by Sabrina Mach.

The recording is available on the Thoughtworks site.

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.

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

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

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

In Part 1, we identified the paradigm shifts of a 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).

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

Skin in the Game

Creating digital products requires a lot of attention from leaders in general and product managers in particular. How do we develop an inspiring, innovative product if we hand off the responsibility and let others do the work? As Nassim Nicholas Taleb argues in Skin in the Game [16], we need leaders who are fully invested.

Concretely, for digital product development and transformations this means:

• Client-side project staff cannot work on such a project with just a few hours per week; they need full attention — at least 80 percent of their working time focused on the project.
• Clients cannot transfer their risk to a supplier via a fixed-price contract.
• IT organizations and business departments must collaborate (see [6]).
• As users, we see products or services in their entirety. Teams should therefore have end-to-end accountability and organize collaboration across different organizational units.
• Due to the German Employee Leasing Act (Arbeitnehmerüberlassungsgesetz, see [37]), German companies operate under clear guidelines governing collaboration between commissioning parties and suppliers — including for the deployment of IT specialists. As a 2003 ruling shows, the issuing of instructions is a particularly decisive factor (see [38]). Since close collaboration between product teams and their assigned product owners is important for the success of digital products — and the relevant roles are often filled by employees from different companies — this creates a tension. The challenge is to establish agile ways of working that promote collaboration on one side and minimize legal risks for clients, suppliers, and employees on the other.
• In transformations especially, courageous leaders are needed — not ones who play it safe, but those with the courage to unlearn their own behaviors and drive the necessary changes in the organization with conviction (see [50] on the concept of Courageous Leadership).
  

In our OTR project, we were fortunate to find project managers who got involved and had the courage to take on the paradigm shifts. The following practices helped us establish a relationship of trust and align everyone around a shared vision:

• In a vision workshop, we worked with all project participants to create a clear vision for our digital product. It was a significant effort to engage all stakeholders for half a day on this task — but we now have everyone’s buy-in. That makes it easier to find common ground in daily discussions, for example around the right prioritization of user stories.
• From this vision, we created a Lean Value Tree, which derives hypotheses from global objectives and tests them through initiatives — either verifying or falsifying them. Even if one could speak of sub-goals rather than hypotheses, this framing makes an enormous difference. A hypothesis gives us — if only psychologically — the permission to be wrong. Better yet: the higher the probability that the hypothesis is false, the more information value it yields (see Reinertsen [1]).
• Especially from leadership positions, we try to create a working environment that gives team members a sense of safety, the opportunity to take calculated risks and even make mistakes, and that encourages dissenting, constructive discussion — knowing that better solutions often emerge from different perspectives.

Cross-Functional Product Teams

As with all our Thoughtworks projects, we work in cross-functional product teams at Daimler too. These typically consist of two to three developer pairs, one Business Analyst (BA), one Quality Analyst (QA), and one User Experience Designer (XD). One project manager is assigned per two to three product teams.

Cross-functional product teams should be self-organizing. After reading about agile development methods, this seems obvious (see e.g. [44], chapter What makes an agile team tick). The following example illustrates what self-organization can look like in practice: After a team grew to 15 people during the build-up phase, it became clear to everyone involved that splitting into two separate teams was necessary. After the standup, we set up two flipcharts and asked the team to divide itself into two groups. Team members’ names were written on stickies, and with a little facilitation support from the business analysts involved, the team reached an initial split within 15 minutes. A brief review showed the split wasn’t quite right yet, and after another 15 minutes we had a result that everyone had contributed to. Buy-in was correspondingly high. Interestingly, this also shifts the tasks of leaders and creates, among other things, more room for creative work. (In [35], F. Laloux describes powerfully how far-reaching the changes to leadership roles can be through self-organizing teams.)

Cross-functional product teams work autonomously on dedicated business functionality — vehicle configuration, for example. To coordinate the distribution of initiatives to product teams, the preparation of research activities, the collaboration between product teams, and the management of dependencies, we established a so-called product strategy team. We adjusted the size and composition of this team over time to the different phases and challenges. For five development teams, for example, we have one product strategy team — consisting of one full-time Program Business Analyst, one full-time User Experience Designer, and a flexibly deployed lead developer. The tasks of the product strategy teams included, for example:

• Defining the product vision in collaboration with product owners.
• Establishing and maintaining the Lean Value Tree (see [45] for a definition).
• Developing the product roadmap.
• Distributing initiatives to product teams.
• Preparing initiatives, including coordinating and conducting user research activities.
• Navigating the tension between feature parity and new functionality.

Diversity as a Driver of Innovation

A study from North Carolina State University shows that a causal relationship exists between workforce diversity (measured by gender, race, and sexual orientation) and the ability to develop new, innovative products and services (see [33]). We can trace this clearly through the OTR project. The following figures give an impression of how the teams were composed:

• 41 percent female or non-binary
• At least twelve different nationalities
• Openness toward employees from the LGBTIQ community
• Three dogs (see [35] on the positive effects when dogs become part of the work culture)

In our day-to-day work, we experience how the many different life experiences and personal backgrounds of our team members lead to rich, substantive discussions. Combined with a culture of openness that motivates everyone — regardless of background or title — to contribute ideas and challenge established practices, this creates a demanding discussion culture that consistently produces innovative solutions. Daimler recognized this: we received the Supplier Award in the Innovation category for our work on OTR China (see [34]).

D. Pink, in [53], offers a further insight into creating a working environment that fosters creativity, productivity, and collaboration. He describes the positive influences of fun at work, laughter, play, joy, and humor. The video introducing the Berlin Thoughtworks office gives a good impression of how these insights translate into practice (see [52]). The regular hackathons generate additional ideas, increase the fun of working together, and strengthen team cohesion.

Distributed Agile Development

To scale development capacity and manage costs, we decided early on to integrate development teams from India. We found it effective to first establish the onshore teams and practice fundamental workflows and collaboration patterns. After about five months, we tackled the additional challenges that distributed agile development brings — communication, language differences, time zone gaps.

We often encountered offshoring approaches organized along the “extended workbench” principle (see [11]): simple, standardized tasks assigned to offshore teams. We were convinced we needed a fundamentally different approach to make distributed agile software development truly effective. From the start, we made a point of treating our offshore teams and individual team members as equals and giving them the conditions they needed to work this way.

To ensure genuine collaboration at eye level, an investment in travel was essential. Especially at the outset of distributed work, we made a point of establishing personal relationships between the people involved in development — in particular product owners, technology leads, and user experience designers. We held regular face-to-face workshops in the inception format (see [10]).

The assignment of initiatives to product teams — particularly from the perspective of those working in the offshore delivery center — was handled by the product strategy team, following these criteria:

• Available capacity of product teams.
• Size of work packages. Larger work packages we tended to assign to offshore teams, since this allowed for longer, uninterrupted work on a topic and reduced the need for on-site inceptions (see Sunil Mundra [10]).
• Depth of domain knowledge. For topics requiring frequent exchange between development teams, product owners, and users, we tended to choose onshore teams for reasons of speed.
• Availability of product owners for particular topics and time periods.

We deliberately did not use the complexity of a topic as a criterion.

Cadence Matters: The Ceremonies

In [1], D. Reinertsen describes how shorter, regularly scheduled check-ins held at consistent intervals can reduce batch size, which in turn leads to shorter wait times (through smaller queues) and therefore faster throughput. We put this principle into practice by agreeing upfront on certain — we call them — ceremonies and holding them at the same time every time. This reduces the overhead of many shorter, ad hoc meetings.

Daily standup at the Kanban board

It also helps that in most cases we are all in the same location (face-to-face, co-located). If someone cannot be physically on the project floor, they dial in via video conference.

Tech huddle in the Berlin event space, with developers from the Indian delivery center dialed in

Name	Frequency	Participants	Goal
Standup	Daily, mornings	All team members, optionally the product owner and other interested parties	Synchronization, status update and progress sharing, identifying problems and dependencies, visualizing progress on the Kanban board
Signup	Daily, directly after standup	Developers on the team	Deciding who works on which user story for the day
Retrospective	Every 2 weeks	All team members	Identifying opportunities for improvement and assigning actions
Showcase	Every 2 weeks	All project members and guests	Presenting work progress through working software, presenting rotating topic deep-dives
Tech Huddle	Weekly	All developers in the project	Discussing technical details, refactoring opportunities, evaluating new tools
Project Mgmt. Catch Up	Weekly	Project managers from Daimler and Thoughtworks	Discussing commercial and project management topics
Thoughtworks Leadership	Weekly	Members of the client leadership team	Identifying risks and opportunities to improve team and client satisfaction
Daimler M&G	Daily, 15 minutes	Daimler project team	Current topics, decisions (previous day, today, and potentially ahead)
Guild meetings	Weekly or bi-weekly	Depending on the guild, e.g. Security Guild, QA Guild, BA Guild, Designer Guild	Developing technical capabilities, aligning across teams — for example, to establish a consistent design

The key ceremonies in the OTR project

Beyond these ceremonies, we apply agile and lightweight approaches in the PMO area as well — for example:

• Start small. Starting small has clear advantages: communication channels remain manageable. With an MVP (Minimum Viable Product or Minimum Viable Prototype), we can initially limit complexity.
• The project floor. We co-located the development teams, IT product owners, and business product owners on a single project floor — creating an environment that supports short communication paths and is ideally suited to agile principles (see [19]: “Business people and developers must work together daily throughout the project” and “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”).
• Working software is the best status report. Every two weeks we invite project members and all stakeholders affected by the project’s progress to a showcase, where we present the work of the past two weeks. This format has now become established and word has spread — we regularly welcome interested guests. This allowed us to reduce the project status report to two pages per month.
• Does it make us better or quicker? Continuously prioritizing initiatives, epics, and user stories in a complex environment is a challenge. Beyond our vision, the Lean Value Tree, and the roadmap, we also use the question of whether something makes us faster or better as an additional criterion for evaluating priorities.

Comprehensive Customer Centricity

Customer centricity, too, represents a paradigm shift. Many of the product owners we engaged for OTR had years of experience in the sales process. But some had not spoken with the future users of the product for quite some time — or listened to Mercedes-Benz customers about their expectations and experiences in the sales process. When customer centricity is taken seriously, customers and users of the digital products we build must be regularly included — or better yet, their usage behavior studied. To do this, domain experts and product owners first need to unlearn established practices and develop a new humility in the face of customer behavior. Product managers and product owners no longer dictate the design and behavior of the application on their own; they regularly use methods such as prototyping, qualitative interviews, or observation (fly-on-the-wall, see [22]) to study user behavior. This is especially important in a world where customer needs are changing faster and faster.

Interview with sales staff at a dealership

This generated a lot of discussion in our OTR project, especially in the early stages, and we were able to learn on both sides. A safe working environment with room to experiment — and to make mistakes — was key.

For example, we experimented with streaming observations of user behavior at dealerships via video conference into the development teams. To allow our colleagues from India to participate, we sometimes used simultaneous interpreters. We now actively communicate with our users through the Daimler Retail Portal, collecting improvement suggestions and providing feedback on application usage.

Real-time analysis of user behavior (shown here in the test environment). We set up monitors on the project floor displaying this and other real-time data.

Even before the actual rollout of the application, we were able to analyze user behavior using monitoring systems backed by real data. For example, we can see how frequently new features are used — such as the newly introduced ability to compare a freshly configured new vehicle with the customer’s last vehicle. This is an area we want to develop further as the application rolls out across Germany. Capturing business metrics and making them accessible to users and relevant business colleagues is important to us.

Building a Feedback Ecosystem

Alongside replacing the legacy system, one of our main goals is to make OTR as flexible as possible — to respond to new or changing user requirements or market developments. We also want to learn from user behavior, as described above. Through the consistent implementation of Continuous Integration and Continuous Delivery (CI/CD, see [32]), we are now always ready to deploy changes to the production environment automatically. We currently update OTR with an average of around 20 software changes per day. Here again, multiple capabilities work together: design thinking methods help generate innovative ideas and provide the foundation for testing multiple alternatives (see [22]). Agile software development explicitly supports late changes to requirements, and test automation and Continuous Delivery enable the rapid translation of those changes into value-delivering software (see [19]: “Welcome changing requirements, even late in the development. Agile processes harness change for the customer’s competitive advantage”).

Next Steps

Patterns in the adoption of agile methods and digital transformations are now becoming clear. A comparison with Agile Adoption Patterns (see [8]) shows that we are in the middle of this transformation in the OTR project. While we have already overcome many hurdles, further steps remain — such as the shift to a product-centric organization, the introduction of agile portfolio management methods (see Lean and Agile Portfolio Management [40]), the further integration of IT and business, and more. The progress we have already made, however, encourages us to continue on the path we have set.

References

1. Donald G. Reinertsen: “The Principles of Product Development Flow: Second Generation Lean Product Development”, Celeritas Publishing, Redondo Beach, 2009
2. Nicole Forsgren, Jez Humble and Gene Kim: “Accelerate”, IT Revolution, Portland, 2018 
3. Martin Fowler: “Microservices Prerequisites”, https://martinfowler.com/bliki/MicroservicePrerequisites.html, 2014
4. Eric Ries: “The Lean Startup: How today’s Entrepreneurs use Continuous Innovation”, Crown Business Publishing, New York, 2011
5. Sriram Narayan: “Agile IT Organisation Design – For Digital Transformation and Continuous Delivery”, Addison-Wesley, New York, 2015
6. Mark Schwartz: “A Seat at the Table: IT Leadership in the Age of Agility”, IT Revolution, Portland, 2017
7. Jonny Schneider: “Understanding Design Thinking, Lean, and Agile”, O’Reilly Media, 2017
8. Danny Smith: “Agile Adoption Patterns”, Medium,  https://medium.com/rootpath/agile-adoption-patterns-724fb921945f, 2016
9. Steve Denning: “Understanding Fake Agile”, Forbes Media, https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#35870f914bbe, 2019
10. Sunil Mundra: “Distributed Development Enablers Part 2: Process”, Thoughtworks Insights Article, https://www.thoughtworks.com/de/insights/blog/distributed-development-enablers-part-2-process, 2016
11. Wikipedia: “Verlängerte Werkbank” in “Fertigungsbetrieb”, https://de.wikipedia.org/wiki/Fertigungsbetrieb#Verl%C3%A4ngerte_Werkbank
12. McKinsey: “How to create an agile Organisation”, Survey, https://www.mckinsey.com/business-functions/organization/our-insights/how-to-create-an-agile-organization, 2017
13. – deleted –
14. 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
15. 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
16. Nassim Nicholas Taleb: “Skin in the Game, Hidden Asymmetries in Daily Life”, Random House, New York, 2018 
17. Martin Fowler: “The State of Agile Software in 2018”, https://martinfowler.com/articles/agile-aus-2018.html, 2018
18. Ron Jeffries: “Dark Scrum”, https://ronjeffries.com/articles/016-09ff/defense/, 2016
19. Agile Manifesto: “Principles behind the Agile Manifesto”, https://agilemanifesto.org/principles.html, 2001
20. Sam Newman: “Building Microservices”, O’Reilly Media, Sebastopol, CA., 2015
21. 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
22. Dark Horse Innovation: “Digital Innovation Playbook”, Murmann Publishers, Hamburg, 2017
23. 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
24. Thoughtworks: “Innovative software development for the sales experience of the future”, https://www.thoughtworks.com/clients/daimler, 2017
25. Wikipedia: “ITIL”, https://en.wikipedia.org/wiki/ITIL
26. Prof. Dr. Roland Eckert: “Warum Daimler auf die Schwarm Organisation setzt”, Springer Professional, https://www.springerprofessional.de/organisationsentwicklung/innovationsmanagement/warum-daimler-auf-die-schwarm-organisation-setzt/12000092, 2017
27. Daniel Kahnemann: “Thinking Fast and Slow”, Farrar, Strauss and Giroux, New York, 2011
28. Wikipedia: “Planning Fallacy”, https://en.wikipedia.org/wiki/Planning_fallacy
29. 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
30. Hermann Vocke: “The practical Test Pyramid”, MartinFowler.com, https://martinfowler.com/articles/practical-test-pyramid.html, 2018
31. Scrum alliance: “Certified Scrum Master”, https://www.scrumalliance.org/get-certified/scrum-master-track/certified-scrummaster?gclid=EAIaIQobChMIuOPj87fh4wIVS7TtCh0xCQV-EAAYBCAAEgJSD_D_BwE
32. Jez Humble and David Farley “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison Wesley, 2011
33. Richard Warr, Matt Shipmann, “Study finds Diversity boosts Innovation in US Companies”, https://news.ncsu.edu/2018/01/diversity-boosts-innovation-2018/, 2018
34. Thoughtworks, “Thoughtworks recognized with Daimler Supplier Award 2017”, https://www.thoughtworks.com/news/daimler-suppliers-award17, 2017
35. Frederic Laloux: “Reinventing Organizations, An Illustrated Invitation to Join the Conversations on Next-Stage Organizations”, Nelson Parker, 2016
36. 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
37. Wikipedia: “Arbeitnehmerüberlassungsgesetz”, https://de.wikipedia.org/wiki/Arbeitnehmer%C3%BCberlassungsgesetz
38. Werner Kurzlechner: “Die Lehren aus dem Daimler Urteil”, CIO.de, https://www.cio.de/a/die-lehren-aus-dem-daimler-urteil,2928650, 2013
39. Neil Ford, Rebecca Parsons, Patrick Kua: “Building Evolutionary Architectures: Support Constant Change”, O’Reilly, 2018
40. Dr. Martin Kramer: “Lean and Agile Portfolio Management”, dr-martin-kramer.com,  https://dr-martin-kramer.com/?p=163, 2016
41. Henrik Kniberg: “Spotify Engineering Culture, Part 1”, Crisp’s Blog,  https://blog.crisp.se/2014/03/27/henrikkniberg/spotify-engineering-culture-part-1, 2014
42. Kasandra Fcong “Transform Meetings with a Great Information Radiator”, Thoughtworks,  https://www.thoughtworks.com/de/insights/blog/transform-meetings-great-information-radiator, 2016
43. Jesse Russel Morgan: “Beginner’s Mind in UX Design”, https://uxdesign.cc/beginners-mind-in-ux-design-with-shunryu-suzuki-11a00787c8a9?gi=f923553c2102, 2018
44. Jonathan Rasmusson: “The Agile Samurai: How Agile Masters Deliver Great Software”, The Pragmatic Programmers, 2010
45. Jim Highsmith, Linda Luu, David Robinson: “EDGE Value-Driven Digital Transformation”, Addison-Wesley, 2019 
46. 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
47. Wouter Aghina, Aaron De Smet, Gerald Lackey, Michael Lurie, Monica Murarca, Christopher Handscomp: “The Five Trademarks of Agile Organisations”, McKinsey&Company, https://www.mckinsey.com/business-functions/organization/our-insights/the-five-trademarks-of-agile-organizations, 2018
48. Wikipedia: “Organisational Change Fatigue”, https://en.wikipedia.org/wiki/Organizational_change_fatigue
49. David J. Anderson: “Kanban, Successful Evolutionary Change for Your Technology Business”, Sequim, Washington, 2010
50. Susan Tardanico: “10 Traits of Courageous Leaders”, Forbes, https://www.forbes.com/sites/susantardanico/2013/01/15/10-traits-of-courageous-leaders/#4ed8c9574fc0, 2013
51. Pete Hodgson: “Feature Toggles (aka Feature Flags)”,  https://www.martinfowler.com/articles/feature-toggles.html, 2017
52. Thoughtworks: “This Is Our Berlin Office”, 2019 https://www.thoughtworks.com/de/locations/berlin
53. Daniel Pink: “A whole new mind: Why right-Brainers will rule the future”, Penguin, New York, 2005
54. Wikipedia: “Cargo Cult Science”, https://en.wikipedia.org/wiki/Cargo_cult_science

In today’s world, the ability to respond quickly to change and new opportunities is what counts. An agile mindset is a proven approach to do exactly that. But where do you start?

Nico Ackermann (Daimler), Sven Dittmer (Daimler), and I used a webinar to show — through the One Touch Retail project (OTR) as a case study — how Daimler is advancing its digital transformation and what paradigm shifts are required.

We recorded the webinar and made it available on the Thoughtworks website.

We had several hundred participants and received a great deal of positive feedback.

Here is the recording:

This is the recording of a webinar on the topic of “Versatility.” Sylvia Kern, Tanja Merz, and Linda Barron introduce themselves as scanner personalities. I moderated the discussion and took questions from the audience.

Digital and Agile Transformation requires an agile mindset, agile methods, know-how, and the ability to solve complex challenges. Complex answers, however, are only found in the diversity and versatility of people and their skills.

For too long, the focus has been narrowly on the specialist, with too little recognition of how important diverse know-how really is. In the future, scanners and multipotentialites will be indispensable in the business world. Disruption means breaking open business models, technologies, structures, and much more — startups, for example, are masters at this.

Routine tasks will increasingly be taken over by digitalization. What remains are the complex challenges that cross-functional teams solve. Those who want to forge new paths must look for unconventional possibilities. In times of digitalization and new work, what’s needed are people who can think differently, who embrace diversity and live it themselves — those who dare to think differently, who bring courage, intelligence, and leadership qualities, and who genuinely relish taking on new challenges.

Offshoring is often treated as little more than an extended workbench for IT projects. For us at Thoughtworks, it never was. We practice agile software development in globally distributed teams — what we call Distributed Delivery.

In this webinar, I discuss Distributed Software Delivery with David Toborek (Metro Digital), Daniel Loeffelholz (Thoughtworks), Sven Dittmer (Mercedes-Benz), and Lucy Chambers (Thoughtworks).

Here is the webinar recording: