Digital Experience Factories

 1. Introduction

I have left AXA a month ago to join Michelin. This is always a great moment to reflect on some of the ambitions of the previous past years. Today I will write about Digital Experience Factories. As AXA Group Head of Digital,  I have worked on setting up a Digital Experience Factory, a software development organization geared to produce digital artefacts and experience, following my previous work on lean software factories at Bouygues Telecom. The introduction of “experience” in the name is a way to emphasize the importance of customer experience in the digital world, but this has always been a key ambition of lean software factories as is shown on the illustration in the next section. The goal of this post is to re-formulate the key ideas and principles of a Digital Experience Factory, now that I have added a few more years of experience. It should be said that the concept of software factory is now well established and that most of what looked new in 2012 is mainstream in 2017.

I have had a long history of experience and interest with software factories, agile organizations and lean software, but I really started to put the pieces together in 2012. I defined the “Lean Software Factory” as the target for our Bouygues Telecom Internet product software division (Internet gateways and set-top boxes)  by merging principles from Agile (mostly SCRUM), Extreme programming and Lean, as explained in this previous post. The theory and the background references were rich, but we actually focused on four practices only:

• Team Problem Solving
•  Using visual management in a project room
•  Reducing WIP through Kanban
• Love your code (5S for the code, coding discipline, code review, gardening, etc.)

This vision has been presented at the Lean IT Summit in 2013 and you may find the slides here with both the general principles and the four practices.  Four the French readers, a simplified presentation was made at the 4th Lean IT Summit in Lyon (2014), with the attached slides.

I will start this post with an illustration that was produced in 2012, because I have reused it extensively at AXA in a digital factory context. Although the picture was produced to illustrate our ambition with set-top boxes, it is sufficiently user-centric and generic to be widely applicable. I was happily surprised to find it so relevant five years later in a different context. I will propose a short summary in the next section.

Section 3 will focus on the critical dependency between the innovation and the software factory. I have used the major part of the past three years at setting up lean startup innovation processes. I have already touched in a previous blogpost at the importance of the relationship between the innovation and software delivery processes, but I would like to emphasize the co-dependance of these two processes which I have labelled “from customer to code” (lean startup) and “from code to customer” (devops). In the digital world (more generally in the modern complex world), “the strategy is the execution” (i.e., you are what you do).

The last section will talk about the role of digital experience factories in the world of exponential information systems.  Since “software is eating the world”, it creeps precisely everywhere in companies’ businesses, inside the company (each piece of equipment in a factory or human collaboration is becoming “smart or augmented”) and outside (customers’ digital lives or business partners). Software factories have a role to play in a larger software ecosystem, with a multiplicity of roles and stakeholders.

2. Digital Experience Factory Blueprint

The following picture is an illustration of a Digital Experience Factory – as well as a lean software factory. Although it is pretty old (in the digital time), I have found that it is still a good blue print for setting up a software factory in the digital world.

This picture is pretty much self-explanatory but I would like to point out a few things, i.e., explain the choice of a few keywords. To keep things short, let’s define the seven foundations of the Digital Experience Factory:

1. The input for the factory is made of “pain points” & “user stories”. No one should be surprised to see user stories for an agile software shop, but I have found that they should not be separated from the “original paint points” which they are derived from. Our practice at AXA has been to build “UVP trees”, which a graphical representation that links the pain points, the UVP (unique value proposition) and the user stories. Sharing UVP with everyone in the software shop improves considerably the quality of the code (from a customer experience point of view). More generally, a key principle of a lean organization is to make sure that “the customer is represented on the production floor” and that customer testimonies – including pain points – are available (visually) to all actors of the process (not just the designers or product marketers).
2. The output of any software development is end-user experience and is measured with user satisfaction. Customer satisfaction is the “true north” of any lean (in the Toyota Way sense) organization. Because customer satisfaction is complex (in a systemic sense), it requires an incremental approach and a feedback loop.
3. CICD (Continuous Integration and Continuous Delivery) is the crown jewel of modern software organization. This is where the huge productivity gap resides, but this also requires significant efforts to setup. I refer you to the great Octo book, the Web Giants, which I have used extensively to evangelize and promote change in the past 5 years. CICD starts with Continuous Build and Integration and continued with Continuous Delivery using DevOps practices. This is probably the part of the picture that has evolved the most in the past 5 years since DevOps is now a mainstream critical recommendation.
4. Test-driven development is also a critical aspect of a digital experience factory because it fuels the CICD ambition (automated tests and automated delivery go hand in hand), but also because it helps to produce higher quality code with less stress, hence more pleasure. I urge you to read Rich Sheridan wonderful book “Joy, Inc” to understand the importance of culture and pride in software development. This obviously goes back to the three tenets of self-motivation according to Daniel Pink: autonomy, mastery and purpose.
5. Visual Management & Kanban are the most visible parts that are borrowed from the lean management principles in a Digital Experience Factory. There are two plagues in most software organizations:   rework (and its cousin, dead code) and waiting (people waiting for one another). Any software development audit that I have had to undergo in my past 15 years of professional experience has found these two issues. Visual Management, in general, and Kanban, in particular, is the best way to tackle these two problems.
6.  “Source code is king” in a digital software factory. The new world of software is characterized by the increased rate of change and innovation. This creates two new requirements : (a) one must love one’s source code because it will be required to be looked at and changed constantly  (b) one must reuse as much existing code as possible, hence the importance of leveraging open source as a code feed (cf. the illustration).
7. Synchronized team work : the digital experience factory is organized into squads, autonomous cross-functional teams. There are at least three important ideas here. First, Squads are cross-functional teams where all necessary skills are working together. Second, synchronized work means working together at the same time on the same problem. This creates an environment where everyone “understands a little bit of everything” which reduces informational friction considerably. Last, the squad is autonomous, both for speed and motivation.

3. Innovation Factories and Learning Loop

The following picture is borrowed from a presentation that I made at XEBICON 2015. It is the best illustration that I have of the interdependence of the innovation process and the software delivery process, and it illustrates what I have been attempting to build at AXA during the past few years.

The key point of this picture is that, although there are two processes, there is only one team and one product that is being built. Other said, these are the same people who participate to the two processes. The capability that the first process it aiming to build is to produce digital artefacts (mobile or web apps, connected object, cloud service, etc. – i.e., code) from listening to, and observing, the customer. The capability of the second process is being able to deliver to customers – at scale – a product/ service from the original code that is produced by the developer in a continuous, high frequency and high-quality manner. What I have learned over the years is that these two processes are very dependent on each other, which is, once more, a lesson from the Web Giants ! It is very difficult to run a lean software factory without the true customer centricity of a lean startup approach (cf. the importance of customer pain points, satisfaction, user stories and testimonies in the previous section). It is equally difficult to implement a lean startup approach without the performance of a great Devops software factory : the iterative process requires the high frequency of delivery, customer satisfaction demands high quality software with high performance and as few defects as possible.

As stated earlier, strategy and execution are merged in the digital world : a strategy only becomes real when it has been executed  and adapted to the “real-time” environment, and execution requires to grow and adapt the strategy continuously. Success becomes a function of the “digital situation potential”, which is a combination of skills, low technical debt and a flexible open architecture. The following illustration is borrowed from the same blog post. It shows the importance of separating different time scales:

• T0: The immediate time scale of customer satisfaction: delivering what is requested. This is the takt time of the factory process.

• T1: The “mid-term” time of continuous improvement. This is the kaizen time, which is more uncertain since some problems take longer to solve

• T2: The “long-term” time of learning. In a complex word, most learning is performed “by doing”. Training happens “on the gemba”, through practice.

This picture is also a great illustration of how the double benefits of the digital experience factory agile and lean roots. Lean and Agile reinforce each other. Agile software development practices are mostly T0 (and some T1 with reflection practices) while lean emphasizes T1 (kaizen) and T2 (kaizen again ! plus dojo practices). Agile and SCRUM are born as “project development methods” whereas lean software programming is geared towards product development. I have covered this topic with more detail in my post about Lean and Architecture.  Long-term sustainable development requires architecture and it is somehow not easy to see where architecture fits in the agile framework, while architecture is a cornerstone for lean sustainable development. I also refer you to the book :  “Lean Architecture – for Agile Software Development”  from James O. Coplien & Gertrud Bjørnvig.

A key piece of the Digital Experience Factory illustration is the feedback loop from customer experience (i.e., the satisfaction or the absence of satisfaction / the usage or the absence of usage). I have formalized the “Customer Feedback learning Loop” (CFLL) over the years, and our experience at AXA has helped a lot to setup best practices that may be easily reproduced.

• CFLL is practiced with three “channels”: implicit, explicit and social.  Implicit listening means using the power of imbedded analytics to track the effective usage of customers. Explicit is “active listening” of users to hear about their usage and satisfaction. Explicit means that we look for verbatim (e.g., in the stores), testimonies from users (through interviews). Active means that this is a conversation, we may ask questions or answer to customers. Social listening requires setting communities/digital tools so that users may act as a group. Experience over the past 15 years has shown that the dynamics of feedback is very different with a group, which feels more empowered, than with individuals
•  CFLL is managed as any quality improvement loops, using a “Toyota-style A3” which supports a PDCA (Plan-Do-Check-Act) approach. Looking for root causes using the “5 whys”, setting up kaizens with the whole team, and careful formulation of assumptions is critical, since digital troubleshooting is hard and full of counter-intuitive surprises.
•  CFLL is part of the Growth Hacking toolbox and also leverages “source code as a marketing tool”, that is making the digital product a marketing and sales channel for itself.
• Because social tools are useless without a community, a key task of the CFLL approach is to grow and nurture a community of engaged users. This is very well explained by Guy Kawasaki in his book “The Art of the Start” :  Success comes from fast iterations applied to a rich feedback ; there is no better way to get this rich feedback than building an “ambassador communities”.

4. Software is eating the world

I will conclude this post by stepping back and discussing about the role of the software factory in the larger software ecosystem that companies need to be part of, since “software is eating the world”. A first logical consequence of Marc Andreessen observation is that software is everywhere in the companies, with a much larger footprint than our “traditional information systems”. I use the world “software” because “digital” is ambiguous. It its broad sense, everything that using bits, digital information, is part of the “digital world”, hence software is part of it. In a narrower sense, which is used many companies, “digital” is what matters to customer, the impact of software, computers, bits … in their daily lives. Many company separate digital and IT because they use a narrower definition of digital (with the broader sense, smart factories, IOT, computer-mediated communication, information systems, web, mobile and cloud services, etc. are all part of the digital scope). To avoid that confusion, I use the word “software” as the common root for customer digital, information systems, Internet of Things, smart control of machines, and digital communication. This helps to understand that no software factory (in the digital, IS or other organizations) is an island.  It is part of multiple ecosystems, internally within the company and externally with other partners and stakeholders. In a world which is dominated by platforms,  a software factory is not only a process that produces code, it is also a host of a software environment (usually centered around a platform) and an ecosystem player through API (Application Programming Interfaces).  This also means that software factories are de facto partners with the company information systems, while at the same time it is clear that the footprint of software in companies is growing faster than their information systems. To reuse an old term from the 2000s, “shadow IT” will grow and not shrink in the future. 

There is indeed a common software ecosystem – of data models, API, architecture patterns – for each company that requires careful thinking and management, which comes from a global viewpoint. Platform engineering demands a common data exchange model (not necessarily a unique data model) as well as common engineering practices (know-how & culture) for API. In other words, “software is eating the world” but it will eat better and faster the world of your own business if you care to manage this emergent process. This is a great opportunity for information systems (IS) organization to play a “backbone role” for the various software ecosystems. Many of these software ecosystem issues are technical (software hosting and security constraints) and architectural issues (event-driven architecture, distributed data architecture) which require skills and experience that are part of information systems DNA. On the other hand, the loose coupling of platforms that are produced by autonomous teams may be a “new art” for the more traditional IS organizations. In the digital world, the platform is the team and the team is the platform: the platform is a live object that evolves continuously to adapt to its environment. A software platform is not something that you buy, not even something that you build, but something that you grow.

  

 I will conclude with a simple but powerful idea: Digital Experience Factories are technology accelerators, i.e. open ports for a companies to leverage the continuous flow of exponential innovation. What I mean is that Digital factories are part of exponential information systems, they make the edge (the border) of the information systems that is in contact with consumers, business partners, and innovative players. In a fast-evolving world, most companies are looking for ways to become “future-proof”. The architecture of exponential information systems draws from biology with a core that evolves slower while the frontier (membrane) evolves at a faster rate from the contact with the outside environment. Digital Factories are part of this “Fast IT” with a clear opportunity to leverage the flow of new technologies such as Artificial Intelligence, Machine Learning or Natural Language Processing. As I explained in a previous post, there are four requirements to harness these new software techniques:

• Access to data (intelligent software drinks huge amounts of multi-sourced data)
• Use of modern software stacks (i.e., leverage latest open sources libraries & APIs
• Autonomous cross-functional teams
• Lab culture (fact-based decision and iterations and failure are welcome)

One can recognize in this list the foundations of the Digital Experience Factory as explained in the second section :)