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