Mastering Digital Transformation: A Case Study (Part 1)

The dispute about software development methods is over. The agile organization is set to establish itself as the dominant organizational form. Current literature, specifically that relating to agile software development, impressively demonstrates this, both in empirical research and in theory. (In Accelerate [1], Forsgren, Humble, and Kim present strong empirical evidence of the link between agile/DevOps methods and business success. In [2] D. Reinertsen presents the underlying principles.) And yet, merely knowing the facts is entirely insufficient when it comes to transforming an organisation to become agile or digital. 

In this two-part series, we take a specific customer project (‘One Touch Retail’ - OTR) and demonstrate how we are using agile methods to advance the digital transformation of the automobile manufacturer Mercedes-Benz. We want to encourage you to face the challenges of a digital transformation – because the results are worth it. While there are challenges and obstacles, your organisation will develop desirable new skills and create value. Once you have experienced the new agile way of working, there is no way back.

Overview

Throughout the multi-year transformation at Mercedes-Benz in collaboration with Thoughtworks, we have learned that we need to address several paradigm shifts simultaneously (keywords: agile software development, DevOps, design thinking). For this, support from Mercedes-Benz’s management has been paramount. We have redesigned our project structure in many areas and used modern infrastructure and control tools (keywords: cloud, lean PMO). Ultimately, we used this to develop a feedback-focused environment that enables us to respond extremely quickly to new requirements and, in the process, develop a product that users will love. 

Our key insights from this transformation project are: 

• Unlearning what we have learned so far and fundamentally changing our daily ways of working required a considerable amount of courage from everyone involved. 
• Start small. We started with small steps and then scaled up quickly. 
• Don’t play it, mean it! And be it! For the digital transformation, the focus is on applying the agile principles instead of stubbornly following a specific method.
• Using commodity infrastructures makes us faster.
• Focus on self-organizing, cross-functional product teams.
• We achieve greater effectiveness by treating offshore teams as equals.

Paradigm Shift

Digitalization is not simply a technical transformation. It calls for far-reaching paradigm shifts and new ways of thinking in many areas. Moreover, it is not a one-off activity or simply a learning experience, but an ongoing adjustment of deeply rooted thought patterns and day-to-day behavior. We believe that five different paradigm shifts are involved: 

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 a focus on business value 

In our opinion, it makes sense to address these individual paradigm shifts simultaneously (even if that seems paradoxical from a change management perspective since it is well known that making too many changes simultaneously in a company can result in a state of “organization change fatigue”, see [3].) After all, many of the paradigms on the right-hand side use practices, tools, and architectures that complement and support one another. The foundation of these paradigm shifts is a culture of openness, trust, and sharing (e.g. of responsibility), humility (e.g. a subject matter expert cannot and does not have to know everything), and inclusion.

“One Touch Retail”

The OTR project is a multi-year digital transformation which is part of the Mercedes-Benz Best Customer Experience Initiative, see [4]. We have set the goal to develop an innovative and intuitive digital assistant for salespersons to replace the current legacy system. The aim is to make the sales process more effective. At the same time, it will allow salespersons at Mercedes-Benz to focus even more closely on their customers. The new OTR platform will also be flexible to allow it to adapt to the changing requirements of the automobile market.

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

Changes from the Status Quo

We (the authors together with the joint project team consisting of Mercedes-Benz and Thoughtworks employees) used OTR to implement Mercedes-Benz’s IT strategy in many areas. For instance, we increased the frequency of software releases from one deployment per month to several deployments a day in the production environment, thus realizing a continuous delivery process. The IT architecture was converted from an n-tier approach to a microservice architecture, while the infrastructure changed from local installations to one using cloud-based components. The former manual tests have been replaced with fully automated tests, which ultimately enabled a continuous deployment process. Thus, we executed a complete turnaround from a waterfall methodology to agile software development using DevOps methods. Moreover, we now use free and open-source software (FOSS) in place of proprietary solutions. Instead of a clear separation of business and IT functions, we rely on the greatest possible integration in cross-functional product teams.

Revolution at Mercedes-Benz

One of the most important and at the same time most difficult aspects of a digital transformation is establishing a new working culture. Mercedes-Benz is currently undergoing a transformation from an automobile manufacturer to a provider of mobility services. Naturally, this also has concrete effects on our work in the OTR project. Demands for greater speed, faster learning, and agility – keyword “#TwiceAsFast” ([6] and [7]) – are moving into the spotlight. This is also based on the recognition that the customer benefit in the automobile industry, particularly in the area of Mobility as a Service (MaaS), can be improved decisively through digital products. However, the quality of the products is determined by their ability to adapt to new customer requirements and to learn from customer behavior as well as their speed in doing so.

In this respect, we view modern software technology as a driver of innovation, placing a focus on technology that accelerates the development process and shortens feedback cycles. It is precisely this capability that forms the foundation for micro innovation (see [8] on the benefits of micro-innovations versus macro-innovations).

Here, too, we are seeing a paradigm shift. At the start of the OTR project, we frequently came up against the attitude of “We know our users’ needs intimately – we’ve been doing this for 20 years!”, but we have since increasingly been taking on design thinking methods. We started conducting regular user and customer surveys (research), have developed a new openness (see [9] for the terms Shoshin or beginner’s mind that are frequently used in design thinking), and come to the realization that we simply cannot know every requirement.

The four catalysts of the Mercedes-Benz ITS strategy

This paradigm shift towards design thinking is supported by the application of four catalysts:

1. A radical process simplification reduces the complexity and duplication of tasks, which allows greater automation of simpler processes.
2. A shift of focus away from the project and towards the product itself. The goal is to use data to reduce costs, increase revenue, and develop your intellectual property and user base.
3. Using speed as a strategic advantage, e.g. to implement customer requirements promptly in your products through continuous delivery.
4. The willingness to fearlessly question existing rules and processes and to learn from mistakes and feedback.

Shifting the emphasis from the project to digital products also changes the self-image of the IT department as they move away from being a service provider in the sense of IT Service Management (ITSM) (also refer to ITIL [10]) and towards collaboration as equals (see [11]). In the OTR project, we experience this in the day-to-day work of our cross-functional teams. For example, business product owners work on initiatives together with IT product owners, with both of them incorporating their perspectives and skills on an equal footing.

We also consistently implement other elements of the Mercedes-Benz strategy in the OTR project:

• Use of free and open-source software
• Cloud-based operation that enables DevOps
• Implementation of microservices that can be reached via APIs
• Working in dynamic swarms
• Use of Mercedes-Benz standard security providers

All of these project components contribute directly to the Mercedes-Benz IT strategy.

We consistently implement the Mercedes-Benz IT strategy in the OTR project. 

Ways of Working

From the very beginning, our goal was to create a safe working environment for every member of the team: one that would allow anyone to make and learn from mistakes in a controlled environment (see [12] on an in-depth discussion of the Kaizen culture). This openness to mistakes works on two levels. First of all, we promote knowledge acquisition and innovation. Secondly, it is easier to introduce new (e.g. agile) practices by experimenting; i.e. coming up with hypotheses, performing experiments to test them, and measuring their success or failure to potentially change direction. Here, too, we apply the principle of small batch sizes, meaning we regularly make small changes to the way of working instead of first designing a new way of working in detail, agreeing on this design, and then implementing it through change management activities. In this way, we can also apply the principles of the agile working method when implementing a paradigm shift. 

Questioning fundamental values and ways of working and unlearning practices takes a great deal of effort. The following circumstances helped us approach the transformation: 

• The automobile industry is currently undergoing a fundamental transformation (refer to [13], for example). The societal, technical, and economic upheavals behind this are now so prevalent in public discourse that the need for action is clear. While the transformation represents a challenge or even a threat on the one hand, on the other it also enables change projects of this kind.
• At the start of the OTR project, we were met with great openness regarding agile methods and the aforementioned paradigm shifts. Even during the initial two-week inception phase we repeatedly heard the motto “trust the process.” This demonstrates the pledge of confidence that the project employees at Mercedes-Benz – who had previously only rarely come into contact with agile methods – made to us. 

Openness, transparency, regular retrospectives, and the opportunity to bring even difficult topics to the table help us to retain this trust, to nurture it, and to maintain the momentum of change. 

Retrospective

Team Setup and Abilities

Digital product development is based on a whole range of abilities that teams or organizational units must possess. To implement agile methods in a truly successful way in software development, simply introducing Scrum is far from sufficient. In addition to the familiar practices of agile development, other requirements include test automation, continuous delivery, microservices, and infrastructure as code. Approaches such as design thinking or DevOps are also necessary. To give us an overview of these abilities within the team, we structured them into six categories: organizational design, product design, technology, strategy, and culture (in [14] D. Frese suggests technology, organisational design, product design, and strategy (TOPS), in [1] Forsgren, Humble, and Kim propose a classification into continuous delivery, architecture, product and process, lean management and monitoring). The following figure shows a selection of the most important abilities, many of which are mutually supportive or enhance the positive impact 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”).

Here are several theories to demonstrate these relationships: 

• If teams are to work autonomously, the necessary abilities, and therefore individuals, must be available in the team. This inevitably leads to cross-functional teams. 
• The scaling up of agile product teams necessitates a reduction of dependencies between teams. Microservices can help strengthen this autonomy. 
• The introduction and operation of a microservice infrastructure requires capabilities such as the use of automated deployment pipelines (CI/CD), infrastructure automation, monitoring, etc. (see M. Fowler [16]). 
• Hypothesis-driven development is based on the possibility of making mistakes. A safe work environment is necessary for this. 
• Design thinking requires creativity, which in turn benefits from diversity.
• Implementing agile principles requires test automation because frequent deployments are impossible with manual tests. This is achieved by implementing a test pyramid (for details on this, see Hermann Vocke [17]). 

Overview of mutually supportive abilities

In the OTR project, we make use of the interactions between these abilities and have implemented almost all of the abilities presented in the image above. 

Still, agile software development is just a small part of the ability spectrum that leading software-focused companies currently use. Organizations that are at the start of their digital transformation therefore require external support. For us, the focus here is not on training or coaching. Our experience has shown that paradigm shifts can be implemented faster and more profitably through collaboration in actual projects. The important thing is to involve project employees who already actively live out these principles and abilities. 

Living Out Agility

According to a survey by McKinsey [18], agile software development is now state of the art. Martin Fowler [15], Thoughtworks’ Chief Scientist, supports this theory but also reports on a phenomenon he calls “faux agile” (other authors call this fake agile (see [19]) or cargo cult agile (see [20])). The authors frequently experience situations in which teams proudly claim that they work according to agile methods. Often this is still very far away – in a positive sense – from what Ron Jeffries describes as Dark Scrum (see [21]). We would therefore like to emphasize that assigning roles based on Scrum, maintaining a backlog, organizing daily stand-ups, and working with stickies is just the start. We believe that it is more important to concentrate on agile principles (see [22]) than to strictly follow methods such as Scrum, Kanban, or SAFe (Scaled Agile Framework). These principles focus on value creation for customers and self-organizing, cross-functional, autonomous teams that supply working software at short intervals. 

One fundamental principle is to allow the individual teams the freedom to determine the specific working methods, tools used, or even programming environments themselves within certain guidelines. This is facilitated by the microservice architecture (see [23]) in particular. For example, in the OTR project, some teams use Clojure while others use Kotlin as a programming language in the back end. Some teams work with two-week sprints, while others use continuous delivery principles or Kanban. Some teams estimate the size of user stories with story points, while other teams take a NoEstimates approach.

We are convinced that this freedom can ultimately increase development speed. Mercedes-Benz’s approach of making greater use of free and open-source software also had a positive impact here (see [24]).

Another principle is the continuous adjustment and further development of the way of working. We regularly demonstrate our way of working to interested colleagues from Mercedes-Benz. From week to week, we see changes on our office walls: for example, the structure of the Kanban board has changed, the roadmap has replaced the lean value tree, the skill matrix was not there last week, etc. (Note: (i.e we use our office walls as what is called an Information Radiator, meaning we use large surfaces to present information visually and interactively, see [25].)

One result of the fundamentally changed procedure is the go-live or, as we call it, the handover. Many of us are familiar with this process as a stressful event that regularly takes place at weekends or overnight to schedule the required downtime during times when the application is not used very much.

In the OTR project, we have implemented the application handover as a no-event. In this process, we release the application and inform the users about this via email. This is possible because the latest state of the application is almost always available in the production environment thanks to the continuous delivery approach (see [26]). The handover of other functions also takes place in the same way. We use feature toggles (see [27]) to activate new components and then inform the users about this. 

Summary and Outlook

In the first part of this article, we identified the paradigm shifts of a digital transformation, explained the case study – the One Touch Retail (OTR) project – presented the approach Mercedes-Benz is using to address the transformation, discussed agile ways of working based on the case study, and investigated how we can avoid faux agile. 

In the second part, we will go into more depth, including clarifying the role of management, presenting examples of work in cross-functional teams, taking a look at ceremonies, discussing the contribution of diversity in the search for creative solutions, getting to know another paradigm shift in the area of customer-centricity, and providing an outlook regarding the further progress of the digital transformation.

References

[1] Nicole Forsgren, Jez Humble und 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] Mercedes-Benz: “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, 2017