Mastering Digital Transformation: A Case Study (Part 2)

In the first part of this two parts article series, 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 (fake agile or cargo cult agile). 

Now we want to 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 continued progression of the digital transformation.     

Skin in the Game

Creating digital products requires a great deal of attention from managers in general and product managers in particular. After all, how can we develop an inspiring, innovative product if we hand over responsibility for it and let others do the work? As Nassim Nicholas Taleb describes in Skin in the Game [1], we need leaders who dedicate their body and soul to the matter.

Specifically, when it comes to the development of digital products and transformations, this means:

• The commissioning party’s project employees need to dedicate their entire attention to it, using at least 80% of their working hours for focused work on the project. 
• Commissioning parties cannot outsource their risk to a supplier via a fixed-price contract. 
• The IT organization and specialist departments must work together (see [2]). 
• As users, we see products or services in their entirety. Teams should therefore be given end-to-end responsibility and organize collaboration between various organizational units.
• As a result of the law on personnel leasing (see [3]), in Germany, clear guidelines on the collaboration between commissioning parties and suppliers are required. This also applies to the employment of IT experts. As a ruling from 2003 shows, giving instructions in particular is decisive here (see [4]). Since close cooperation between product teams and the assigned product owners is key for the success of digital products and the corresponding roles are often filled by employees from different companies, an area of conflict arises here. It is therefore important to establish agile forms of working that promote collaboration while also minimizing the legal risks for commissioning parties, suppliers, and employees.           
• In transformations, in particular, courageous managers are needed who do not simply play it safe but dare to relearn their behavioral patterns and resolutely help to promote the implementation of changes in the company (see [5]) among other sources for the term courageous leadership). 

In our OTR project, we were lucky enough to find project managers who got involved and dared to tackle the paradigm shifts. In this connection, the following practices have helped us to establish a trusting collaboration and to commit to a vision: 

• In a visioning workshop, we created a clear vision of our digital product together with all those involved in the project. It took half a day of focused effort to assign all the stakeholders with this task. However, through this, we now have the buy-in of all the involved parties. This means that in daily discussions it is now easier to, for example, find a mutual position regarding the correct prioritization of user stories. 
• Based on this vision we created a lean value tree which takes global goals and defines hypotheses that can be verified or disproved with the help of initiatives. We might speak of subgoals instead of hypotheses – yet this makes a huge difference. With the aid of a hypothesis, we are able to be wrong – even if only from a psychological perspective. Even better, the greater the probability that the hypothesis is wrong, the more information can be gained from it (see Reinertsen [6]).
• Particularly from management positions, we aim to establish a working environment that gives team members the security to take calculated risks and make mistakes in the process, encouraging a dissenting, constructive discussion in the knowledge that improved solutions often arise from differing opinions.

Cross-functional Product Teams

As with all of our projects at Thoughtworks, we work with cross-functional product teams at Mercedes-Benz. They generally consist of two to three developer pairs (developers), a business analyst (BA), a quality analyst (QA), and a user experience designer (XD). One project manager is assigned for every two to three product teams.

Cross-functional product teams should be self-organizing. After reading about agile development methods, this might be obvious (see, for instance, [7], chapter What makes an Agile Team Tick). Yet, here is an example to show in more tangible terms what self-organization could look like: After a team on the OTR project had grown to 15 people during the development phase, it quickly became clear that it was necessary to divide it into two separate teams. Following the stand-up, we set up two flip charts and asked the team members to split up. Their names were written on stickies and with a little support by the involved business analysts, an initial division into the two future teams had been achieved after 15 minutes. A brief review showed that the division was not yet perfect, and after another 15 minutes, we had a satisfying result that everyone had worked together to achieve. The buy-in was correspondingly high. An interesting feature is that this also shifts tasks of the managers and creates more freedom for creative working, among other things (in [8] F. Laloux gives a remarkable description of how extensively management roles can change as a result of self-organizing teams). 

The cross-functional product teams work self-sufficiently on dedicated business functionalities such as vehicle configuration. We set up a product strategy team to coordinate the initiatives of the product teams, the preparation of research activities, and the collaboration of the product teams, as well as the management of dependencies. Over time we adapted the size and staffing of this team to the various phases and challenges. For example, we have one product strategy team for five development teams. It consists of a full-time program business analyst, a full-time user experience designer, and a chief developer who can be involved on a flexible basis. Some of the product strategy team’s tasks include: 

• Defining the product vision together with product owners.
• Setting up and maintaining the lean value tree (see [9] for a definition).
• Developing the product roadmap.
• Distributing the initiatives across the product teams.
• Preparing the initiatives, including coordinating and performing user research activities.
• Navigating the field of tension between feature parity and new functionalities.

Diversity as a Driver of Innovation

A study by North Carolina State University shows that a causal relationship exists between the diversity of the workforce (as measured by gender, race, and sexual orientation) and the ability to develop new, innovative products and services (see [10]). We can easily see this in the OTR project. The following data provides an impression of the composition of the team: 

• 41 percent non-male
• At least twelve different nationalities
• Openness towards members of the LGBTIQ community
• Three dogs (see [8] on the positive effects when dogs become part of the work culture)

In our day-to-day work, we experience how numerous different life experiences and personal backgrounds lead our team members to discussions with a range of interesting content. This, combined with a culture of openness that encourages everyone regardless of their background or title to contribute their ideas and question known procedures, results in a discussion culture that is certainly challenging, but also leads to innovative solutions. For instance, Mercedes-Benz presented us with the Supplier Award in the Innovation category for our work on OTR China (see [11]).

In [12], D. Pink provides a further note on creating a work environment that encourages creativity, productivity, and collaboration. He describes the positive influence of fun at work: laughter, play, joy, and humor. The video introducing the Berlin Thoughtworks office gives a good insight into how we have implemented these findings (see [13]). The regular hackathons provide further ideas, make work more fun, and reinforce team spirit.    

Distributed Agile Development

To allow us to scale development capacities better and to keep costs down, we decided at an early stage to integrate development teams from India. Here, we found it most effective to first establish the onshore teams and to practice the basic workflows and forms of collaboration. After around five months, we tackled the additional challenges that come with distributed agile development methods such as communication, language, and different time zones. 

Often, we discovered offshoring approaches that are organized in accordance with the principle of the extended workbench (see [14]) where simple, standardized tasks are assigned to the offshore teams. We were convinced that we needed a fundamentally different approach if we were to implement distributed software development in a truly effective way, i.e. from the very beginning, we made sure that we viewed our offshore teams and the individual project members as equals. 

To truly be able to work as equals, it is necessary to invest in travel. Particularly at the beginning of the distributed work, we made sure that we established personal relationships between the individuals involved in development, especially the product owner, technology lead, and user experience designer. Regular face-to-face workshops in an inception format (see [15]) were of great help here.

The product strategy team assigned initiatives to product teams, particularly from the perspective of the teams working in the Offshore Delivery Center based on the following criteria: 

• Available capacity of product teams.
• Size of work packages. We preferred to assign larger work packages to the offshore teams, as this allowed longer periods of uninterrupted work on a topic and thus reduced the need for on-site inceptions (see Sunil Mundra [15]).
• Depth of functional understanding. For topics that required frequent exchange between the development teams and the product owners and users, we generally chose onshore teams for reasons of speed. 
• Availability of product owners for certain topics and time periods. 

We specifically did not use the complexity of technical topics as a criterion. 

Cadence is Key: The Ceremonies

In [6], D. Reinertsen describes how shorter, regularly planned agreements that take place at the same intervals reduce the batch sizes, which in turn results in shorter waiting times due to smaller queues and thus in faster lead times. We implemented this principle by agreeing on certain “ceremonies” at the very beginning and ensuring that they always take place at the same times. This reduced the overhead of multiple shorter meetings. 

Daily stand-up at the Kanban board

We were also helped by the fact that, in most cases, everyone is in the same place (face-to-face, co-located). If somebody cannot physically be at the project space, that person dials in via video conference.

Tech huddle in the Berlin event space; developers from the Indian delivery center are dialed in

Name	How often	Participants	Objective
Stand-up	Daily, in the morning	All team members, optionally the product owner and other interested parties	Synchronization, information regarding the work status and progress, identification of problems and dependencies, visualization of progress on the Kanban board
Sign-up	Daily, immediately after the stand-up	Team developers	To determine who will work on which user story on that day
Retrospective	Every two weeks	All team members	To identify possible improvements and assign actions
Showcase	Every two weeks	All project members and guests	Presentation of the work progress based on running software and presentation of different specialist topics
Tech huddle	Weekly	All developers in the project	Discussion of technical details, possibility for refactoring, discussion regarding the deployment of new tools
Project management Catch-up	Weekly	Project managers from Mercedes-Benz and Thoughtworks	Discussion of commercial and project management topics
Thoughtworks leadership	Weekly	Members of the Client Leadership Team	Identification of risks and possibilities to improve team and customer satisfaction
Mercedes-Benz M&G	Daily, 15 minutes	Mercedes-Benz project team	Current topics, decisions (previous day, today, possibly future)
Guild meetings	Weekly or every two weeks	Depending on the guild, e.g. security guild, QA guild, BA guild, designer guild	Further development of technical capabilities, alignment via teams, e.g. to establish a uniform design

The most important ceremonies in the OTR project

As well as the above ceremonies, we also use agile and lightweight methodologies in other areas, including the Project Management Office (PMO), for example:

• Start small. Starting small means that communication channels are manageable. We can initially limit the complexity through an MVP (Minimal Viable Product or Minimal Viable Prototype). 
• The project space. We have co-located the development teams and the IT and business product owners in a single project space and thus created an environment that allows short distances and ideally supports the implementation of agile principles (see [16] for the principles “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”). 
• Running software is the best status report. Every two weeks, we invite the project members and all those affected by the progress of the project to a showcase where we present the work that has been done over the past two weeks. This format has now become established and word has got out, so we now also welcome interested guests each time. As a result, we have been able to reduce the project status report to two pages each month.
• Does it make us better or quicker? Constantly prioritizing initiatives, epics, and user stories in a complex environment is a challenge. In addition to our vision, the lean value tree, and the roadmap, we also ask ourselves whether we can be faster or better as a further criterion for assessing priorities. 

Comprehensive Customer Focus

We are also dealing with a paradigm shift in the area of customer focus. Many of the product owners we were able to recruit for OTR have many years of experience in the sales process. However, for many of them, it has been a long time since they last spoke to the future users of the product or heard about the customers’ expectations and experiences in the sales process. If we truly want to take the customer focus seriously, we need to regularly involve the customers and users of the products we create and ideally analyze their usage behavior. However, for this to happen, technical experts and product owners must first unlearn the practices they have learned and develop a new humility towards customer behavior. Product managers and product owners no longer single-handedly specify the design and behavior of the application but make regular use of methods such as prototypes, qualitative interviews, or observations (e.g. fly-on-the-wall, see [17]) to study user behavior. This is particularly important in today’s world of rapidly changing customer requirements.

Interview with salespersons at a branch

This approach resulted in numerous discussions, especially at the beginning of the OTR project, and both sides were able to learn a great deal. A safe working environment with the freedom to experiment and make mistakes was of tremendous help. 

For example, we experimented with streaming observations of user behavior in the dealerships to the developer teams via video conference. To allow our colleagues from India to participate, we also worked with simultaneous interpreters in some cases. We currently communicate actively with our users via the Mercedes-Benz Retail Portal, take suggestions for improvement from there, or provide feedback on using the application. 

Real-time analysis of user behavior (an example from the test environment). In the project space, we have set up monitors with this and other real-time data. 

Even at this stage, before the actual rollout of the application, we have been able to analyze user behavior based on data with the aid of the monitoring systems. For example, we can see how frequently new features (e.g. the option to compare a freshly configured new car with the customer’s last vehicle) are used. This is an area that we want to expand further when the application is rolled out across Germany. It is important for us to also record business metrics and make them available to the users and affected business colleagues.    

Setting Up a Feedback Ecosystem

As well as replacing the legacy system, one of our main objectives is to design OTR as flexible as possible to allow us to respond to new or changing requirements of the users or the market. We would also like to learn from user behavior as described above. Thanks to the consistent implementation of continuous integration and continuous delivery (CI/CD, see [18]), we are now always prepared to automatically migrate any changes into the production environment. As a result, we update OTR with an average of around 20 software modifications per day. Again, multiple abilities interact to make this possible: design thinking methods help generate innovative ideas and form the basis for running through several alternatives (see [17]). Agile software development specifically supports changes to requirements late in the process and test automation and continuous delivery allow for rapid implementation in value-generating software (see [16] for the principle “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage)”). 

Further Steps

Patterns are now beginning to emerge in the introduction of agile methods and digital transformations. A comparison with Agile Adoption Patterns (see [19]) shows that, in the OTR project, we are in the middle of this transformation. Although we have already overcome many obstacles, there are still many steps ahead of us, including the shift to a product-centered organization, the introduction of agile portfolio management methods (see Lean and Agile Portfolio Management [20]), further integration of IT and business, and more. However, the successes we have already achieved give us the courage to continue on the path we have started.

References

[1] Nassim Nicholas Taleb: “Skin in the Game, Hidden Asymmetries in Daily Life”, Random House, New York, 2018 
[2] Mark Schwartz: “A Seat at the Table: IT Leadership in the Age of Agility”, IT Revolution, Portland, 2017
[3] Wikipedia (German only): “Arbeitnehmerüberlassungsgesetz”, https://de.wikipedia.org/wiki/Arbeitnehmer%C3%BCberlassungsgesetz
[4] Werner Kurzlechner: “Die Lehren aus dem Daimler Urteil” (German only), CIO.de, https://www.cio.de/a/die-lehren-aus-dem-daimler-urteil,2928650, 2013
[5] Susan Tardanico: “10 Traits of Courageous Leaders”, Forbes, https://www.forbes.com/sites/susantardanico/2013/01/15/10-traits-of-courageous-leaders/#4ed8c9574fc0, 2013
[6] Donald G. Reinertsen: “The Principles of Product Development Flow: Second Generation Lean Product Development”, Celeritas Publishing, Redondo Beach, 2009
[7] Jonathan Rasmusson: “The Agile Samurai: How Agile Masters Deliver Great Software”, The Pragmatic Programmers, 2010
[8] Frederic Laloux: “Reinventing Organizations, An Illustrated Invitation to Join the Conversations on Next-Stage Organizations”, Nelson Parker, 2016
[9] Jim Highsmith, Linda Luu, David Robinson: “EDGE Value-Driven Digital Transformation”, Addison-Wesley, 2019
[10] Richard Warr, Matt Shipmann, “Study Finds Diversity boosts Innovation in US Companies”, https://news.ncsu.edu/2018/01/diversity-boosts-innovation-2018/, 2018
[11] Thoughtworks: “Thoughtworks recognized with Daimler Supplier Award 2017”, https://www.thoughtworks.com/news/daimler-suppliers-award17, 2017
[12] Daniel Pink: “A whole new mind: Why right-Brainers will rule the future”, Penguin, New York, 2005
[13] Thoughtworks: “This is our office in Berlin”, 2019 https://www.thoughtworks.com/locations/berlin
[14] Wikipedia (German only): “Verlängerte Werkbank” in “Fertigungsbetrieb”, https://de.wikipedia.org/wiki/Fertigungsbetrieb#Verl%C3%A4ngerte_Werkbank
[15] 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
[16] Agile Manifesto: “Principles behind the Agile Manifesto”, https://agilemanifesto.org/principles.html, 2001
[17] Dark Horse Innovation: “Digital Innovation Playbook”, Murmann Publishers, Hamburg, 2017
[18] Jez Humble and David Farley “Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation”, Addison Wesley, 2011
[19] Danny Smith: “Agile Adoption Patterns”, Medium,  https://medium.com/rootpath/agile-adoption-patterns-724fb921945f, 2016
[20] Dr. Martin Kramer: “Lean and Agile Portfolio Management”, dr-martin-kramer.com,  http://dr-martin-kramer.com/?p=163, 2016