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.
Micro frontends are an architectural style that take the idea of microservices and apply them on the frontend part of (web) applications. I am talking with Ward Coessens, MengMeng Yan, and Eka Rudianto about their experience with using micro frontends.
We cover the following topics:
Why do you need micro frontends?
The Browser as a development platform
How did we start with micro frontends in 2017?
As a developer, what are your experiences with micro frontends?
Are micro frontends visible to the user?
How do different parts of the frontend communicate?
What’s the relationship between micro frontends and microservices
How does this relate to autonomous, cross-functional teams?
How does it really work?
Should you build you own framework?
Should you now use micro frontends for all your web applications?
How can you ensure a consistent design experience?
How does an interactive component library look like?
In agile environments, we don’t need steering committees. Steering committees are a dying species. They are part of an outdated governance structure which is not suitable any more for today’s fast paced product-oriented environments.
In this video I tell the story about my relationship with steering committees and how I needed to unlearn using them as a governance tool.
Clojure. That’s a modern functional programming language. Not only the people who just read the book the Unicorn project in which functional programming is discussed wonder about this language. Why is it that functional programming is becoming more and more interesting in the business world now. I wondered what was behind this hype and therefore got together with my colleagues Ward and Naveen who helped me better understand Clojure.
In this episode of Thoughtworks tech talk we take a close look at Clojure. In our discussion we talked about the functional paradigm, look at immutability, why Clojure is thus well suited for parallel processing.
We also take a look into actual Clojure code starting with a Hello World and closing with how map-reduce looks like in Clojure How difficult is it to learn Clojure and what can help you to get started?
This learning breakthrough video is about how I found out what is really important about project risk management. After a short intro to risk management according to the project management institute (PMI), I tell the story how I managed risks on a large HR payroll outsourcing project. This led me to recognise that it is paramount to actually create and commit to actions derived from the risk log. Moreover, making conscious decisions, communicating these decisions and actions and involving your teams and stakeholders is important, as well.
Let’s say you have a difficult challenge and need some great, innovative ideas to get through this. Wouldn’t it be nice if you could just snip with your fingers and there you have it, these great new ideas?
This video is about taking creativity from some mysterious magic to a (somehow) predictable process. I will introduce you to the work of Edward de Bono on Lateral Thinking. This helps us to understand better how our brain works and understand why we can become trapped in our own successful thinking.
With the help of a metaphor I will explain different methods on how break out of these thinking prisons. In the end I take these concepts and apply them to brainstorming and provide concrete tips and tricks how to conduct much better brainstorming sessions which will give you more and better ideas.
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.
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.
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
Donald G. Reinertsen: “The Principles of Product Development Flow: Second Generation Lean Product Development”, Celeritas Publishing, Redondo Beach, 2009
Nicole Forsgren, Jez Humble and Gene Kim: “Accelerate”, IT Revolution, Portland, 2018
Dark Horse Innovation: “Digital Innovation Playbook”, Murmann Publishers, Hamburg, 2017
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
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:
From waterfall methodology to agile software development
From project to product
From development and operations to DevOps
From requirements analysis to design thinking
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:
Radical process simplification reduces complexity and duplication of activities, enabling simpler processes to be more strongly automated.
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.
Use speed as a strategic advantage — for example, through Continuous Delivery to incorporate customer needs into your products in a timely way.
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
