For many years I have been involved in distributed software delivery. At the beginning in a waterfall setup. Since 2017 also in agile distributed delivery. I have seen many engagement fail and also have been part of successful delivery setups. Here’s my personal top 20 list of mistakes in that area.
Nr 20: Involve offshore teams too late Nr. 19: Forget to plan enough travel cost Nr. 18: Forget to invest into communication infrastructure Nr. 17: Neglect the time zone differences or cultural norms when scheduling ceremonies Nr. 16: In communications, forget to level the playing field Nr. 15: Teat all offshore location as „Offshore” Nr. 14: Missing alignment on the delivery model Nr. 13: Trying to enforce the same working mode for all teams Nr. 12: Use the one-size-fits-all delivery model Nr. 11: Go distributed with the wrong engagement Nr. 10: Assign the wrong work to the offshore team Nr. 9: Forget to extend the role model setup Nr. 8: Deny the language differences Nr. 8: Not understanding political and cultural differences across the locations Nr. 6: Forget the relationship building Nr. 5: No direct access to users and customers Nr. 4: Forget the business view Nr. 3: Forget to create the big picture for offshore teams Nr. 2: Offshore teams not on eye-to eye level Nr. 1: Do it for the wrong reason, i.e. only look at the price
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
