Techniques Thoughtworks Technology Radar 1. Four key metrics Adopt To measure software delivery performance, more and more organizations are defaulting to the four key metrics as defined by the DORA research program: change lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage. This research and its statistical analysis have shown a clear link between high-delivery performance and these metrics; they provide a great leading indicator for how a delivery organization as a whole is doing. We’re still big proponents of these metrics, but we’ve also learned some lessons. We’re still observing misguided approaches with tools that help teams measure these metrics based purely on their continuous delivery (CD) pipelines. In particular when it comes to the stability metrics (MTTR and change fail percentage), CD pipeline data alone doesn’t provide enough information to determine what a deployment failure with real user impact is. Stability metrics only make sense if they include data about real incidents that degrade service for the users. We recommend always to keep in mind the ultimate intention behind a measurement and use it to reflect and learn. For example, before spending weeks building up sophisticated dashboard tooling, consider just regularly taking the DORA quick check in team retrospectives. This gives the team the opportunity to reflect on which capabilities they could work on to improve their metrics, which can be much more effective than overdetailed out-of-the-box tooling. Keep in mind that these four key metrics originated out of the organization-level research of high-performing teams, and the use of these metrics at a team level should be a way to reflect on their own behaviors, not just another set of metrics to add to the dashboard. 2. Single team remote wall Adopt A single team remote wall is a simple technique to reintroduce the team wall virtually. We recommend that distributed teams adopt this approach; one of the things we hear from teams who moved to remote working is that they miss having the physical team wall. This was a single place where all the various story cards, tasks, status and progress could be displayed, acting as an information radiator and hub for the team. The wall acted as an integration point with the actual data being stored in different systems. As teams have become remote, they’ve had to revert to looking into the individual source systems and getting an “at a glance” view of a project has become very difficult. While there might be some overhead in keeping this up-to-date, we feel the benefits to the team are worth it. For some teams, updating the physical wall formed part of the daily “ceremonies” the team did together, and the same can be done with a remote wall. 3. Data mesh Trial Data mesh is a decentralized organizational and technical approach in sharing, accessing and managing data for analytics and ML. Its objective is to create a sociotechnical approach that scales out getting value from data as the organization’s complexity grows and as the use cases for data proliferate and the sources of data diversify. Essentially, it creates a responsible data-sharing model that is in step with organizational growth and continuous change. In our experience, interest in the application of data mesh has grown tremendously. The approach has inspired many organizations to embrace its adoption and technology providers to repurpose their existing technologies for a mesh deployment. Despite the great interest and growing experience in data mesh, its implementations © Thoughtworks, Inc. All Rights Reserved. 12