Friday afternoon. Running in the local forest near the Alte Försterei, AirPods in. I’m talking to Ruby — the orchestrator of my new AI agent team — somewhere between km 7 and km 8.
Not a crisis. Not an urgent decision. I’d just been thinking about something we are currently working on, and the next thought arrived before I could stop it.
Which is fine. Except I was on the one trail I reserve for not thinking about work.
Here’s the thing: having an AI agent team that is genuinely always available — one that is starting to deliver real work every day this week — creates a pull I didn’t fully anticipate. It’s not really stress, at least not the bad kind. It’s something closer to momentum. When things are going well, switching off feels like friction, not rest.
I finished the run. Ruby was still there when I got home. I still don’t know if that’s a feature or a design flaw.
Both, probably.
Where do you draw the line — or have you stopped trying to draw one?
My business card has a photo of me playing jazz piano. People notice. They ask why.
I’m a bit of a jazz nerd, so that explains some of it. But there’s also a business reason.
It’s a quick shorthand I’ve found for how I think — for my mindset.
Jazz musicians listen before they play. Not as a courtesy — as a mindset. You find the space before you fill it. Miles Davis is often quoted on this: “Don’t play what’s there, play what’s not there.” And you’re not just listening for your own next note — you’re listening for what everyone around you needs.
Underneath that listening is something called groove. Not tempo — a metronome keeps tempo. Not harmony — that’s the chords. Groove is the shared pulse the whole group locks into together. In a client room, it’s the difference between work that feels transactional and work that actually moves.
That’s the part most meeting cultures train out of people. We show up with our answer ready. A jazz musician shows up open.
But listening alone isn’t enough — because you’re not playing alone. The other musicians are shaping what you do next. That’s harmony: not everyone playing the same thing, but everyone playing things that work together. What you do depends on what the person next to you is doing. The result is something none of you could have made on your own.
And when something unexpected happens — a wrong turn, a surprise from the room — you don’t stop. You play through it. That’s improvisation: rigorous preparation, played in response to what the room is actually giving you, not what you rehearsed for. It’s not winging it. The best client work I’ve been part of looked exactly like that.
Herbie Hancock told a story about a night playing with Davis when he hit what felt like a disastrously wrong chord mid-solo. Davis responded by playing notes that made it fit. Hancock later reflected: “Miles didn’t hear it as a mistake. He heard it as something that happened. As an event.” The band didn’t stop. They built on it.
That idea — the listening, the harmony, the groove, the shared thing you create together — has shaped how I think about client meetings, virtual or in person.
When a program scales to more teams, I am regularly involved designing the team setup — and regularly the wrong person to do it.
Not because I lack the experience. But because the knowledge that should drive that decision is not with me. It is in the domains.
Anyone scaling a large modernization program often has the same instinct: build more teams, divide the scope, assign the available people to the newly defined areas. Bring in a leadership group that has the overview and can decide who’s needed. That sounds like sensible program management.
It is structurally wrong — and the root cause is architectural, not organizational: as long as the domain boundaries are unresolved, resource allocation drives architecture. That is Conway’s Law. And we now know exactly what follows from it.
The assumption that holds the classical approach together
The classical approach works like this: a leadership group — program managers, architects, sometimes external consultants — designs the target organization. Teams are structured around capabilities, technical layers, or resource availability. Then the available people are fitted into that structure.
McKinsey puts the starting point plainly in their Agile transformation methodology: “Most transformations start with building the top team’s understanding and aspirations.” That sounds plausible. The problem is the assumption underneath it: that the knowledge of what good team structure looks like sits at the top.
It does not. And in a transformation of the complexity that decades-old legacy or even mainframe estates carry, that mistake is particularly consequential.
Why the knowledge sits in the domains — and what Conway has to do with it
The teams working daily with the systems and business processes understand the dependencies of the existing estate better than any leadership group does. They know which parts of the system are tightly coupled. They know where the real interface problems lie.
Melvin Conway formulated in 1968 what we now call Conway’s Law: organizations that build systems inevitably produce designs that mirror their own communication structure. This is not a metaphor. It is a causal statement. If I cut teams along technical layers or by availability, I get a system architecture that mirrors that division — not the one I wanted.
MacCormack, Rusnak, and Baldwin gave this empirical grounding in a 2008 Harvard Business School study. They examined how closely organizational structure correlates with product architecture — the so-called Mirroring Hypothesis. The finding: products from loosely coupled organizations are roughly eight times more modular than those from tightly coupled ones. Poor organizational design produces poor modular architecture — not as a side effect, but as a direct consequence.
For a large modernization program — the type I work with — this means: the decision about how to cut teams is not a resourcing question. It is an architectural decision. And it must be made before the resourcing begins.
The Inverse Conway Maneuver: architecture first
Anyone who wants to deliberately create the architecture they want must design the team structure accordingly — not the other way around. Instead of defining teams and hoping the architecture follows, we reverse the sequence. We start with the question: what architecture do we need? What domains does the system have, how strong are their internal dependencies, how loose their connections to the outside?
This reversal — known in the literature as the Inverse Conway Maneuver and listed on the Thoughtworks Technology Radar as an established technique — is the central lever when scaling delivery programs.
In practice, this works through domain analysis. We use Domain-Driven Design: Event Storming sessions with domain experts from the business, Bounded Context definitions, Context Maps. The goal is always the same: a domain map that shows which areas of the system are strongly correlated internally and have as few external dependencies as possible.
That map is the starting point for the team cut — not the free slots in people’s calendars.
Skelton and Pais develop a complementary idea in Team Topologies: every team has a cognitive load — a maximum mental overhead it can carry. Stream-aligned teams that follow a single value stream minimize handoffs and keep that load manageable. Top-down structures that distribute capabilities by availability routinely ignore that limit.
A layer-based cut forces handoffs across all teams for every business change. A domain-based cut eliminates that dependency entirely.
What this means concretely in a complex program
A large modernization program — with a legacy and sometimes mainframe estate where logic has grown into a practically inseparable unit over decades — brings exactly this challenge.
The modernization strategy we recommend in these programs is consistent: build domain by domain, following the Strangler Fig pattern, slice by slice. Start with a core that proves the architecture under real conditions — before the program scales to further domains. The core business domains provide the structure; their boundaries must be established before the team cut.
This is exactly where the Conway thesis applies directly: the domain cut must precede the resource cut. Team ownership follows from domain structure — not from capacity availability.
That is why the first phase of such a program begins with Event Storming and Domain-Driven Design. Not as a methodological ritual. But because that step lays the foundation for every subsequent decision: what Bounded Contexts emerge within the core domains? Where do the boundaries lie — and who takes ownership of them?
A concrete example from practice: core insurance processes — new business, and mid-term policy amendments — each span at least three business domains in complex systems. A quote request triggers pricing in one domain; an accepted application issues a policy in a second; and the binding event (cover going effective) drives downstream obligations — billing, correspondence, commissions — that live in still other contexts. These cross-domain handoffs are exactly what Event Storming makes explicit — and exactly the evidence a team needs to decide where Bounded Context boundaries should be drawn. Had the team made that cut before this analysis, it would have either ignored those handoffs or split across them arbitrarily.
A leadership group at the drawing board cannot answer these questions. They emerge through working with the domain experts from the business — in the workshops, across the event maps, through the collaborative refinement of Bounded Contexts. Only once that map exists does it decide how teams are formed and how accountability is distributed.
Self-Selection: letting the team decide
In some programs we go one step further — and this is the step that generates the most resistance when we first propose it.
Instead of centrally assigning available people to the newly defined domain teams, we let the team organize itself. The domain map is on the table. The available slots are transparent. The constraints are clear: skills, experience distribution, seniority. And then we ask people where they see themselves.
The evidence for this approach is consistent — even if it comes from case studies rather than controlled experiments. Sandy Mamoli and David Mole documented self-selection through their work at Trade Me and in their book Creating Great Teams: teams that formed without direct management assignment became high-performing teams over two years, with minimal subsequent adjustments. Martin Lohmann’s experience report on SimCorp’s Product Division — a SAFe rollout involving roughly 550 people forming 55+ teams across seven ARTs — shows the same pattern at larger scale. At New Relic, around 50 software teams were entirely reformed through self-organization under predefined constraints. The organizers described the outcome afterwards as “way more successful than anybody anticipated”. And I have seen it working myself.
An unexpected side effect: people chose colleagues they wanted to work with. That sounds simple — and it is. Those who get to choose take ownership. Those who are assigned wait and see.
The natural moment for a self-selection session is the close of the program’s first phase: once the Bounded Context map of the core domains is in place, the team slots and their areas of responsibility are transparent enough for people to make an informed choice.
Execution matters: self-selection requires active facilitation. Without it, the results are not good teams — the case studies show that as clearly as they show the successes.
The further a program moves from self-selection toward central assignment, the less ownership people feel — and the more adjustment the structure needs afterwards.
How this fits the broader conversation
The Spotify model appears in every discussion about team scaling. Joakim Sundén, one of the Agile Coaches who worked alongside the model during its formation, described it as “part ambition, part approximation” — never fully implemented, always an aspirational image. What companies copied was the structure: squads, tribes, chapters. What they ignored was the culture — genuine autonomy, psychological safety, the willingness to let mistakes happen. Structure without domain logic and without real decentralisation is just a label.
The difference does not lie in the org chart. It lies in who holds the knowledge that informs the cut.
What this means in practice
Scaling is not a resourcing problem. It is an architecture problem.
Adding new teams without first understanding the domain structure of the system builds an organizational form that — by Conway’s Law — produces a system architecture. And that architecture will not be the one you wanted. The HBS study shows this effect is real and measurable, not theoretical.
For a complex modernization program, this means concretely: the investment in Event Storming and Domain-Driven Design at the outset is not a methodological box-tick. It is the precondition for the teams that scale in later phases to work along the right boundaries. Domain ownership, Bounded Contexts, Context Maps — these artifacts are not just architecture documents. They are the foundation of the team organization.
Who decides where the domain boundaries should lie? Someone in the leadership group who knows the scope — or the people who work with the system daily and know where the real couplings are?
In the programs I work with, this question is regularly answered implicitly before it is ever asked. That is usually how the problem starts.
My friend Tillman has been building electric basses for years. I finally bought one. There’s just one small problem: I don’t play bass. Yet.
Tillman Anton is one of those rare people who has turned a deep love of his craft into a life’s work. He has been building electric basses for many years — and the Atlantic, a five-string he made, is a masterpiece. The wood, the weight, the detail in the neck. You hold it and you understand immediately that this came from someone who cares.
I am a musician. Not a bass player — but anyone who loves music gets drawn into the world of beautiful instruments. I could not keep admiring Tillman’s work from a distance any longer. So I bought one. And yes, the coming months will involve learning to play it. That is part of the joy.
If you love basses — or you know someone who does — take a look at what Tillman builds. He will find the right instrument for you too.
Years ago I bought a book called Automate the Boring Stuff with Python. I read most of it. I understood it. I never actually automated anything.
The book was fine. The problem was me.
I was a developer earlier in my career. I knew enough Python to follow every example — renaming and organizing thousands of files in one go, scraping a website instead of copy-pasting data by hand, bulk-processing Excel files or PDFs, filling forms automatically. The use cases were real. The payoff was obvious. And yet none of the scripts ever happened.
The honest reason: I had stepped away from daily coding. Getting fluent enough to actually build and debug a working script would have cost more time and mental energy than the task I was trying to automate. The ROI was negative. So the book sat on the shelf.
That changed when I started using ChatGPT and Gemini as coding co-pilots. I was still writing Python — but with help. The activation energy dropped enough to make some scripts worth finishing.
Then I started working with Claude Code. Now I don’t write the Python myself at all. I describe what I want. The AI builds it, iterates, fixes it when something breaks. The barrier is simply gone.
What I keep thinking about is this: the book’s promise was always correct. The bottleneck was never the tool, and it wasn’t willpower either. It was the cost of re-fluency for someone who had moved away from daily coding. AI removed that activation energy entirely.
Which means the constraint has shifted. The question is no longer “can you code well enough to automate this?” That question is gone. The question now is “do you have good enough judgment about what is actually worth automating?” That’s a thinking skill, not a technical one.
The tool was never the barrier. Knowing what to point it at — that’s the work that remains.
What boring task would you finally automate — now that coding fluency is off the table?
Offshoring is often treated as little more than an extended workbench for IT projects. For us at Thoughtworks, it never was. We practice agile software development in globally distributed teams — what we call Distributed Delivery.
In this webinar, I discuss Distributed Software Delivery with David Toborek (Metro Digital), Daniel Loeffelholz (Thoughtworks), Sven Dittmer (Mercedes-Benz), and Lucy Chambers (Thoughtworks).
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.
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
