What does “doing agile” mean ?

 

11. Introduction

Agile methods have clearly won the software development popularity contest and Agile ways of working have become a necessary component of ever modern company’s strategy; Everyone want to “do agile”. Agile is no longer an IT topic, it has become an organization method that applies to the whole enterprise. Most companies claim to “do agile” or to have started an “agile transformation”. This is actually not a surprise since Agile actually works and delivers value in a VUCA world. Each letter of the VUCA acronym (Volatile, Uncertainty, Complexity and Ambiguity) represents a challenge for the traditional (Taylor-influenced, planned, decide-then-execute, specialize activities, …) ways of working in general, and the waterfall software development process in particular. Agile methods are iterative, based on continuous feedback from the environment and the collaboration of multiple viewpoints (design, development, operations,  …) that brings solutions to the VUCA challenges. You may read the BCG article “Why Agile Works” by David Ritter and Linsay Chim to get some additional arguments. They explain that “agile organizations establish an unbroken chain of Why”, between purposes, outcome and work, that makes the outcome much more robust to the VUCA uncertainties: “one of the most powerful benefits of agile is the ability to quickly recognize when things are going off course and to adjust on the basis of learning”.

Agile in a VUCA world has many flavors because it may focus on different goals. First, it may mean to better innovate, to better satisfy the customer, in an ambiguous and uncertain world. What matters then is the iterative nature to co-develop with the customer. It may also mean to achieve a difficult outcome in a complex world (digital transformation is not always about innovation, it also means to do the things that your customer expect right). In that way, what matters is the short cycle time, the “fail fast” capability. Agile may also be about constant adaptation to your volatile environment (digital homeostasis). In that case, agility is not simply about mindset or ways of working, it is also a characteristic of your digital systems. As Arnaud Lemaire points out in his wonderful “Let’s reset Agile”  talk (in French), if adaptability is your goal, what matters is how much time it takes to change a component … which is definitely as much a property of your code (how elegant your code is, how modular your architecture, …) as a property of your process.

Today’s post is a review of “Doing Agile Right”, a book that explore what how companies should adopt the agile approach to innovate and deliver more value to their customers. Learning to “do agile right” takes time, hence this is a book about agile transformation. Agile transformation is a bigger challenge as soon a scale kicks in, when the legacy of existing systems and operations has to be factored in. Agile software development for a small independent team developing a new product has never been a challenge. The challenge starts when a company needs to increase the rate of change to its existing organization (people and systems). This is the topic of this book and, therefore, the topic of this blog post.

 

2.  Doing Agile Right

 

“ Doing Agile Right : Transformation Without Chaos” is a book written by three Bain partners, Darrell Rigby, Sarah Elk and Steve Berez. This is first and foremost a book about Agile transformation. It is based on two key ideas : Agile works and the transformation towards agile ways of working is long and difficult. A good part of the book provides with example that show that agile delivers value and more precisely, agile helps companies to deliver innovation in a VUCA word. For the authors, agile is a business mindset change, much broader than the software development aspect of innovation. Since the book is written by Bain partners with a lot of combined experience assisting large companies, this book focuses on such companies. Hence this book contributes to the testimony that agile can scale (even if it is difficult) and that “agile at scale” works for many companies. However, and this is what gives the title to the book, to deliver value at scale, one must understand “deeply” how agile works and, therefore, “do Agile right”. It is important to “do Agile right” because, according to the authors – and many other observers – many companies are “doing it wrong”, generating frustration and lack of significant and long-lasting results.

This book holds a great review of the history of agile, starting with a reference to the paper that is recognized as the seed in agile development methodology :  “ In 1986, Ikujiro Nonaka and coauthor Hirotaka Takeuchi published an article in Harvard Business Review called “The New New Product Development Game.” Studying manufacturers that were releasing successful innovations far faster than competitors, the authors identified a team-oriented method that had changed the design and development process”. I am grateful to the authors of “Doing Agile Right” to have prompted me to read this seminal article. Reading this 1986 paper in 2021 is fascinating, because so many of the key ideas about Agile are already in the paper, with deep insights about why this “new way of (software) product development” has become necessary in a VUCA world. Teams play a key role; they are described as autonomous, with cross-fertilization (cross-functional) and self-finality. Some of the major traits of the Agile-to-become method are the multi-learning, the overlapping of design and development, and the chaos-friendly “subtle” control (because the goal is to orchestrate a group of teams, not to manage a single one). Some of the key ideas about the role of the product generations as support for transfer learning that I learned in 2012 thanks to my experience with set-top box design are already there, beautifully articulated. Let me last mention a great quote – to fill you with the desire to read for yourself – about the role of products: “Third, management should assign a different mission to new product development. Most companies have treated it primarily as a generator of future revenue streams. But in some companies, new product development also acts as catalyst to bring about change in the organization.”

As usual, the following is not a proper book review, it is a curated selection of the eight topics/ideas that I found most relevant.  I encourage you to put your hands on your own copy of the book, it is an entertaining as well as educating read.

 

2.1  Agile is a method that has a proven track record to help companies to innovate

The first key message of the book should come as no surprise to the readers of this blog : Agile way of working is well suited to our VUCA world and delivers value.  The authors give multiple examples of companies that have switched to agile approaches to better innovate:  “The reasons for agile’s rapid spread are neither obscure nor surprising. Most big companies find it difficult to innovate. They are weighted down by the structures and procedures of bureaucracy”. As the readers of Accelerate know, this is not a matter of opinion, there today enough studies to demonstrate that claim : “These are grand claims, but the data support them. Study after study find conclusively that agile teams are far more successful at innovation than teams that work in traditional fashion”. Companies are adopting the agile way of building new products, services, and software systems and this helps them deliver more value in volatile and uncertain world. In a world that changes constantly, adapting your products, services and systems is a necessity, innovation becomes a rule : “Insufficient focus on innovation leads to a static enterprise that will fail to adapt to changing conditions. Insufficient emphasis on operations creates chaos—poor quality, high costs, and dangerous risks to customers and to the business.” Last, if Agile transformation has statistically proven track record of delivering customer value, it is a deep transformation that takes time : “Organizations embarking on a transformation to an agile enterprise are like triathletes in training. It’s an ambitious project. There is an optimal pace. It’s likely to take years to come to fruition. But successful companies will be able to do things that few others can even contemplate”.

Agile is foremost a mindset, a business attitude towards your context and your environment. To be agile means mostly to recognize that your environment changes constantly in a way that you cannot foresee, so you replace planning with a regular and deep pattern of observation, then you take a corrective action and you iterate. This has nothing to do with technology to start with : “Agile innovation works in situations beyond IT.  As we noted earlier, many people believe that agile began in IT and works only there. They are wrong on both counts”. The authors give multiple accounts of companies who have adopted agility as a business attitude, such as NPR: “It’s common to hear, for example, that agile is great but only for technology-based innovations and the IT departments that generate those innovations. This will come as news to National Public Radio, which used agile methods to create new programs”. Because the agile mindset is focus on adapting, hence observing the environment, the agile approach is “outside-in” and requires team autonomy and the reversal of the traditional top-down chain of command : “Agile teams work differently from chain-of-command bureaucracies. They are best suited to innovation—that is, the profitable application of creativity to improve customer solutions, business processes, and technology”.

 

2.2  Doing Agile Right, as opposed to “faux-agile”

In his famous article « The State of Agile Software », Martin Fowler describes what he calls “faux-agile”, the abuse of the form of agile over substance: “Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place”. Faux-agile is a plague because it fits the need for control that is still common in many organizations: it is based on procedures and tools, with an emphasis on structure and organization to the detriment of team’s autonomy. This creates a static (and heavy) framework – one size fits all – where software development methods should adapt and evolve continuously. Faux-agile downgrades technical skills which is critical to build agile systems (agility is also a property of the systems that are built) and the focus on processes tend to stick companies with a project mindset where most often a “shift from project to product” is required. “Doing Agile Right” proposes a description of “Agile without meaning” which is very similar to “faux agile”. The authors have tracked and observed the persistence of the Taylorist mindset (planning over observation, thinking over execution) that produces “faux agile”: “But his approach caught on, and indeed it has long outlived him—even today, many companies have plenty of managers and executives who are Taylorists at heart. And when Taylorists try to implement agile, bad things happen”. The thirst to be in control, what Frederic Laloux calls “the beautiful illusion of control”, means that every random incident that is the signature of a VUCA world will create the strong desire to return to “the safe ground of command and control” : “It’s a version of Gresham’s law: bad agile drives out good. If that happens too often, agile will be discredited—and the business world will be back where it started, with top-heavy bureaucratic corporations struggling hopelessly to keep up with brash upstarts and rapidly changing markets”.

I strongly recommend this part of the book since the authors propose their insights about what causes the “rise of faux agile” : managers being out of touch with the reality. This is why Lean is so insistent on “Genchi gembutsu” and “gemba walks”, if you do not walk out to see by yourself and if you manage according to PowerPoints, the VUCA nature of the world is guaranteed to escape you. The disconnect from reality can be surprisingly strong : “ At first we thought the executives must be lying, but we soon discovered they are merely out of touch. They are so distant from the agile work that they only know what subordinates tell them, and subordinates tell them only what they want to hear”. The next quote is so close to situations that I have seen in my previous professional lives that I applaud the audacity: “Instead of responding to change, program management offices build complex Gantt charts with bright red dots to flag people who deviate from plans”. I will conclude this section with another quote from Martin Fowler : “A team should not only choose its process, but continue to evolve it”.

 

2.3  Agile where it matters

This book sends a strong message that you need to understand how agile works to succeed with your agile transformation, but also to understand when and where it is needed. Agile is not a panacea that replaces “the errors of waterfall approach” : “Agile, Agile, Everywhere Some agile gurus pitch the approach as a panacea that must replace bureaucracy everywhere—in every company, in every business unit, in every function”. Traditional project management has an amazing track record of success for very large and complex projects of the past century. System engineering, detailed specifications, proven specifications, simulation for validation are still very relevant in this century and many situations ask for the same level of forecasting and analysis, especially when machines and protocols are involved with no human insides. When a domain is stable (as opposed to VUCA), hierarchical decomposition and specialization (the signature of bureaucracies - “A bureaucracy works when its organizational tasks—what to deliver and how to deliver it—are clear, stable, and predictable”), waterfall project management is still appropriate. “The challenge, in short, is not to replace bureaucracy with agile everywhere but to find the right balance between the two. Every company must run its businesses. It must be good at operations. Every company must also change the business, continuously introducing not just new products and services but new operating methods and procedures”… “More agile is not always better agile. There is an optimal range of agility for every business and for every activity within a business”.

 

2.4  Agile for VUCA

As told in section 2.1, Agile is an iterative method that constantly validates and invalidates hypotheses made previously from how the “real world” (the enterprise’s environment) react: “Agile is founded on empiricism and the scientific method. It stresses that hypotheses should be tested against real-world results rather than trusting alluring theories or intuitions”.  This is the heart of the “small steps” principle: “So agile favors small batches, produced in time-limited (less than a month) work cycles called sprints”. From an optimal control viewpoint, we look to reach digital homeostasis, that is adapting the internal rate of change of the enterprise to the environment’s rate of change: “Ideally, an agile business system would operate at the golden mean between change deficiency—leading to a static business system that adapts too slowly to survive—and change excess, creating a chaotic business system that constantly risks spinning out of control”.

This is not a static or stable problem; it requires a continuous and adaptive transformation. This is why “faux agile” is such a bad service to companies: “Agile practitioners also know that solutions, processes, and technology must continually adapt as customer needs change. They believe that agile teams are the tools best suited to develop innovative solutions when what to deliver, how to deliver it, or both, are vague and unpredictable—the typical situation when addressing customer needs”. Although this book focuses mostly on innovation, it is worth underlying the deep match between agile as a complex system optimal control process and the nature of the VUCA world:

• Agile matches Volatile: iteration and small steps are here to constantly adapt to volatile (frequent) changes. This is precisely the point made in the first paragraph about homeostasis.
• Agile matches Uncertainty: Not only changes are frequent but they are hard to forecast. The heart of agility is frequent observation of your environment. High frequency sampling replaces planning.
• Agile matches Complexity:  complexity produces “unforeseen consequences”. Small steps and frequent adjustments are a great tool to master the pains of complexity. The principle of continuous integration (to rebuild as frequently as possible, so that if you have made a mistake, you find out before you may cause too much damage) is a perfect illustration.
•  Agile matches Ambiguity: agile replaces the specification of the results (how to achieve the desired goal) by user-centric user stories that describe outcomes.

 

2.5  Agile can scale

“Doing Agile Right” is a book about the agile transformation for large companies. It addresses the issue of “agility at scale”,  that is, how does one adapt agile methods with a large number of teams that needs to collaborate on a common goal (product, service, etc.). My own experience matches what the authors report: agility at scale is necessary, it can be achieved – even though it is clearly a much more difficult task because collaboration and synchronization require communication – and many companies have found ways to make this work : “Large-scale agile teams of teams also improve results.  Despite concerns that agile was designed for individual teams and can’t scale effectively, research shows otherwise”. The book contains a discussion about scaling framework that is not so different from my own review (of SAFe, LeSS and Disciplined Agile): “ The latest entrants include the Spotify Model, Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS), Enterprise Scrum, Lean Management, Agile Portfolio Management (APM), Nexus, and Recipes for Agile Governance in the Enterprise (RAGE). … About 30 percent of companies scaling agile say they use the SAFe framework. It is by far the most detailed and prescriptive approach”.  If you understand that now framework will substitute from a deep understanding of how agile works, and even more importantly if you understand that any framework places your company at risk to converting to faux-agile, then either SAFe or Scrum@Scale (Scrum of Scrums) are interesting choices that bring value : “SAFe’s strengths include the depth and breadth of its prescriptions, its training programs, its big-picture view of performance beyond the team level, its appeal to control-oriented executives, and its ability to coordinate interdependencies among teams”; “ Scrum@Scale’s strengths include its ambition to improve the agility of the entire organization; the complete consistency of the framework with successful Scrum values, principles, and practices”.

2.6  Agile Teams … and Squads

Teams are the foundation unit of the agile approach. Teams must be autonomous, small, cross-functional and empowered: “To tackle an opportunity, the organization forms and empowers a small team, usually three to nine people, most of whom are assigned full time. The team is multidisciplinary”. Empowerment is critical, the book gives many examples about companies that have undergone this transformation and tells how to recognize when this is the case: “I want to walk into an auditorium and ask, ‘Who owns the member’s change-of-address experience?’ And I want a clear and confident response from a team that owns that experience, whether a member is calling us, logging into our website on a laptop, or using our mobile app”. Empowerment means that the role of manager changes, as is now abundantly clear: “In an agile environment, leaders take a different approach. They may tell a team what to focus on, but never how to do it. Figuring out the how is up to team members themselves”.  There is a dual synergy between agile teams and agile way of working, you need teams to deliver agile value, but agile ways of working also produces a better work environment for team: “Compared with traditional management approaches, agile offers a number of major benefits, all of which have been studied and documented. It increases team productivity and employee satisfaction. It minimizes the waste inherent in redundant meetings, repetitive planning, excessive documentation, quality defects, and low-value product features”.

The team is multi-disciplinary (cross-functional) with no boundary between “business” and “technology” (for digital products and services, the boundary is very blurry, anyhow): “Having the business and technology people work together as one team is essential to success.” The authors have collected a number of testimonies about the necessity of merging the business and technology viewpoints: “Having these groups work separately, even with the best efforts at alignment, would not have given us anything close to the speed and product quality we require”. Talent matters very much in agile teams. The following is one of the critical feedbacks from companies that have embarked on their agile transformation: “I wish our company had started work on talent earlier.” We can scarcely count the number of times we have heard that regret from executives whose companies are launching agile”.  “Doing Agile Right” is a very practical book: each chapter ends with a clear summary and a few questions that you should ask yourself as a maturity assessment of your own practices. For instance, here are two of the questions that you should ask your agile teams: “How can people collect more feedback from customers?” and “How can employees minimize work in process?”

The term “Squad” has been introduced by Spotify and I have regularly used it as a short-cut: a squad is a team that fits the agile ways of working: size, cross-function, autonomous and empowered. This book makes a few references to the “Spotify model”: “The Spotify model is intuitive and easy to understand; it works well in Spotify’s engineering department, though it is not a significant factor in areas such as strategic planning or finance”. I will conclude this section with a few personal remarks about this agile model. Like many people I liked the “Spotify model” when it came up 10 years ago because I found value in:

•  The use of “squad” as shorthand for cross-functional and autonomous.
•  The squads / tribe (teams of teams) model which was a good fit for my own challenges.
• The concept of chapters and guild to add a matrix dimension for skill capitalization.

Since then, there have been many warnings saying that taken literally, the “Spotify model” does not work. For instance, you may read the strong critics of Jeremiah Lee in “Failed Squad Goals: Spotify does not use the spotify model and neither should you”. I actually still appreciate the value that I found in the Spotify papers in 2011, and I have applied successfully some of its ideas. Furthermore, I dislike this kind of after-the-fact criticism (sure, we understand scaling agile better in 2020 than we did in 2010 and nobody is forced to take ideas illustrated in a position paper as rules), but I would definitely agree with the three following warnings from Jeremiah Lee:

• Team autonomy is good but there is such a thing as “too much autonomy”. Teams must collaborate to build “one system” and orchestration of squads is a tough (architecture, to start with) topic.
• Scaling requires more structure, management and tools than what was outlined in the first Spotify papers. Tools such as PI planning are probably SAFe most useful contribution.
• The “Tech lead” role is critical. Software products need a “chief” (in the Toyota sense) who embody the technology vision and mindset, as much as they need a product manager.

 You may think that this debate about taking a paper or a book literally is unsignificant, but it is not. In a VUCA world, for the very same reasons that make managing throw PowerPoint impossible (the map is not the territory), you should not take a document (this blog post, the book that I am commenting, the SAFe framework or the Spotify papers) as rigorous guidelines to be followed.

 

2.7  Customer focus

An agile approach should always start with the customer: “ So how should agile teams go about innovating processes? In some ways, process innovation is much like any other agile innovation. You start with the customer and work backward to solve their needs in an incremental, iterative way … As a philosophy, agile focuses intently on customers”. This why user stories a critical role in the agile approach. The book gives interesting examples, such as Dell, about how agile companies gather extensive customer input and let the customer be the best judge on what they want. This is not so easy, as is illustrated by a number of anecdotes such as this one: “He realized that simply putting together cross-functional teams and giving them a mission wasn’t enough. He had been hearing for some time about agile innovation from colleagues inside and outside the bank, and realized that a broader set of agile practices could make the teams more effective and better sustain their success. After learning more, he decided to embark on a customer-focused agile transformation, beginning with the home mortgage business”.  Once the customer voice is onboarded, the importance of design, from user experience design to interface design, becomes critical: ”Led by the designers, people on the team conducted customer research to gather feedback. Team members with operations and customer service backgrounds then designed new digital and people-based processes to create the experience that customers wanted, and the team’s software engineers wrote the code to enable these new processes, assisted by data engineers and data analysts who ensured the availability and maintenance of accurate data”.

 

2.8 Lean & Agile, Flows and Metrics

This book touches many times the topic of Lean & Agile relationships and the importance of flow, as Mik Kersten did in his great book “Project to Product”. Flow efficiency is a critical concept for large organization, especially in the context of a large transformation. Without flow efficiency, local progress may be totally hidden and the agile transformation may stop : “But the most difficult problem—and one that is likely to be counterintuitive—is this: even though agile teams may develop innovations better and faster than ever before, leaders are likely to find that the company’s overall innovation velocity is not improving. When they investigate that problem, they uncover the concept of flow efficiency”.

Another important part of the book discusses metrics, which is a hot topic for agile methods, and strikingly difficult when one starts an agile transformation in a controlled-obsessed company (which is both an oxymoron and a statistically significant occurrence). The authors propose an in-depth analysis based on five kinds of metrics: inputs, activities, outputs, outcomes and purposes. The two salient ideas are that, first, companies need to understand the difference between the five (as the Chinese proverb says: one does get a plant to grow faster by pulling the stem). Second, each team should be left responsible with the way it organizes input, activity and output metrics to be organized towards continuous improvement, whereas outcome and purposes metrics are meant to be shared: “Agile teams set clear goals for themselves. They try to understand what goes well and what doesn’t go well as they pursue those goals”. This is where reading the seminal paper “The New New Product Development Game”, referred to in the introduction, is enlightening. Some metrics should be used as KPI because of their capacity for alignment and because they define the share strategy. Some metrics should be used to better understand performance and efficiency and should be left to the teams since turning them into goals is counterproductive.

I would end with a word of caution about one of the best practices proposed by the authors: “ They Tie Funding to Outcomes”. Although there is a systemic elegance in the idea to replace budget funding with a adaptative flow that is linked to the outcome (give more money to agile products when they have achieved the desired outcome), it is very important to discuss the “timescale” for this piece of advice. On a long timescale, this is obvious: one should not keep funding a team who does not deliver. On a shorter timescale, it becomes much more subtle: digital companies do make bet and invest funding for a while before they see outcome.  The funding should definitely follow an agile iterative process of its own, but the frequency should be different from the system delivery cycles and the logic reflects the principle of “affordable loss”.

 

3.  Conclusion

The most important conclusion that one may draw from reading this book is that agility matters. Agility matters since it helps companies to deliver more value – better innovations – in a VUCA world. Agility is a tool for constant adaptation to the environment, when enterprises are seen as living organisms. Agility as an active pillar of digital homeostasis – constant adaptation to the fast rate of change of the digital world – is a key principle of my own book, “The Lean Approach to Digital Transformation”. “Doing Agile Right” is a great contribution to the better understanding of how agile works in large compagnies. There is now a broad consensus. I have started with a BCG paper in the introduction, I will refer to a McKinsey article in this conclusion, “The five trademarks of agile organizations”. A quick summary of these five traits should come as no surprise to you, at this point in your reading : (1) network of empowered teams, (2) autonomy but a shared “North star” goal – a common finality that is embedded and embodied (we are still humans) across the organization, (3) rapid decisions and learning cycles, (4) Passion and mindset – the focus of “Doing Agile Right”, (5) Next-gen enabling tech.  The last item is important, because in a digital world, technology matters.

“Doing Agile Right” is not a book about IT, nor is it a book about software or software architecture. IT is mentioned a couple of times, to point out that IT departments have to be a part of the solution rather than being part of the problem: “Sad to say, IT departments and the software they develop are notorious for creating such difficulties. A common issue for some companies is spending millions on customized software when standard off-the-shelf solutions would meet their needs”. A few pages talk about the importance of modularity and service-oriented architectures – with the expected reference to microservices: “Design Operations as Modular Capabilities Today’s software systems are typically built as microservices—small, modular units of functionality with clearly defined interfaces”; “A modular arrangement like this allows an agile team to improve the functioning of the capability without worrying about interfering with other parts of the organization”. Although there is nothing wrong with these two statements, they represented a simplified and somehow naïve view of information systems architecture. I refer you to the excellent “Designed for Digital” book – in addition to my own - to get deeper insights about this. If you are familiar with the Kano diagrams, you may easily understand the paradoxical importance of IT/software/technology in the success of digital transformation. Success, as defined by customer satisfaction and value creation, is much more a matter of mindset and culture than it is a matter of technology. However, if the technology capabilities are not there, failure is the most probable outcome. In terms of the Kano model, IT and software capabilities are a “basic need” of digital transformation.

 

 

 

Lean for Digital Transformation

 

1. Introduction

A few months ago, my last book “The lean approach to Digital Transformation” got published by Dunod. This book is built in response to paradoxes and situations of frustration and misunderstanding, which I often observe as a senior executive. Here are the three examples that I quote in the book introduction:

• Many large companies complain about the low return on investment from their digital service development programs. After a period of strong enthusiasm, when you look at the business numbers, you realize that usage remains low and that these projects have generated only a small part of additional revenue. In addition, quite often, recent and small players - startups - have interfered in this scope of digital services, to step into the digital relationship with the customer. “We have the means, the talents, the customers, the brand awareness… and we are being overtaken by startups”.
• The speeches on digital transformation, the creation of value through data, reinvention with artificial intelligence are so numerous and deafening that there is not a company that has not decided to adopt "exponential technologies" : cloud, machine learning and data science, artificial intelligence. Yet adoption of the data-driven ambition is slow, and value creation does not replicate what is found in leading digital companies, what Salim Ismail calls "Exponential Organizations." You can find POCs everywhere (proofs of concept) but the scaling up is long and laborious.
• Enthusiasm for digital transformation has coincided with a massive adoption of new IT project development “agile” approaches. Many companies have hoped that this change of method would bring them closer to the software performance of the "Web Giants", yet progress in terms of reliability, speed of deployment, and even more speed of adaptation to the market and to competitors ( what managers associate with "agile") are weak and disappointing. The creation of new digital platforms has not succeeded to erase the slowness and the frustrations that many managers express about their IT departments.

 

I am mostly writing this blog post because some of my readers do not read French. Half of the material of the book may probably be found in this blog, but the other half will have to wait for an English edition. I am working on it, but the outcome is not clear, while I have received many requests for a translation. This summary will not replace reading the book, but at least it should give you a fair idea what this book is about. In a nutshell, the book develops the three capabilities that are essential for a successful digital transformation:

1. To know how to co-create digital services with users, whether they are customers or future customers. This ability combines observation, dialogue, and iterative experimentation. The approach proposed in this book is based on the Lean Startup approach, according to an extended vision that combines Design Thinking and Growth Hacking. Companies must become truly "customer-centric", from observation, listening to co-development.
2. To develop an information system (IS) which is the backbone of the digital transformation – which I call  “exponential information system” in this book to designate an open IS (in particular on its borders), capable of interfacing and combining with external services, positioned as a player in software ecosystems and built for processing scalable and dynamic data flows.
3. To build software “micro-factories” that produce service platforms, which I call “Lean software factories”. This “software factory” concept covers the integration of agile methods, tooling and continuous integration and deployment practices, a customer-oriented product approach and a platform approach based on modularity, as well as API-based architecture and openness to external stakeholders.

 

The other reason for writing this blog post is to address the lean foundations that give the title to the book. Part of it is rather obvious: the book is organized, as its subtitle says, from customer to code and from code to customer. The first direction is covered by the Lean Startup approach – though my own filter of applying Lean Startup in a large company – while the second direction matches the Lean Software factory.  But the influence of lean thinking is much deeper and is better captured by the “love of customer” and the “love of code” that this book tries to advocate. Thus, this post organization is quite simple. Section 2 provides a summary of the book content. Section 3 is a short essay about the deep relevance of lean to succeed with your digital transformation.

 

2. Book Outline

This book is organized in three parts. The first part deals with digital transformation, that is, the transformation of the company in the face of the acceleration of the digital revolution. This part lays the foundations for the rest of the book, since it describes the objectives of this transformation: continuous adaptation, innovation, and better intimacy with customers. It deepens the analysis of Designed for Digital and extends it with a complete presentation of the Lean Startup approach to building digital services.

The second part deals with information systems and the central role they play with digital transformation. Software "is eating the world", in the words of Marc Andreesen, and digital transformation affects all activities and businesses of the company, beyond the more restricted perimeter of information systems. But the information system is the backbone on which new software activities are grafted. It must carry an ambition of openness, agility, and continuous modernization, necessary for the digital transformation.

The third part describes software factory and platform principles. It focuses on understanding how to use best practices in software development, from tooling to automation, agile methods to lean practices, to transform software development. The concept of the software factory also applies, but in a different way, to the heart of the information system and to its borders, to produce the "digital platforms" mentioned in Designed for digital.

2.1  Digital Transformation

The first chapter is entitled "Why a digital transformation?". Our starting point is the radical change in the relationship between the enterprise and its customers in the digital world. In a world of abundance, the company must build conversations with its customers and develop an intimacy that legitimizes the relevance of the solutions it offers. The digital world is made up of ecosystems and platforms that demand more openness and cooperation with partners, letting the customer become the architect of her experiences. The company is therefore approaching its digital transformation to better meet the expectations of its customers and to better produce the products and services that its customers expect. Digital transformation affects the entire value chain, from R&D and solution design, to the marketing and operation of these solutions, including the production of hardware or software components. The digital revolution - the ubiquity of connectivity, the abundance of data and the exponential power of processing - is driving itself into design and manufacturing, for example through artificial intelligence applications.

The second chapter, "Homeostasis: Continuous Adaptation to Change", deals with the profound change in the organization of the company which is necessary to adapt to the continuous and accelerated change that characterizes the digital world. The company must become an "exponential organization", a network of autonomous and reactive teams, organized around a common objective, capable of absorbing and benefiting from the continuous flow of technological innovations linked to the digital domain, from connected objects to machine learning. The digital transformation of the company consists in developing, over the long term, the potential of the situation - the digital capacities - which will allow it to act quickly and agile in the face of an opportunity. Today's digital world is complex and uncertain, the agility of responding to its opportunities requires "letting go" in action. The field of strategy shifts from forecasting actions to developing capacities. The first skill of a digital company is its ability to continuously learn from its environment, technology, and customers. The role of managers is changing, as the voice of the customer and that of technology take more space, and this change deserves to be supported.

The third chapter, "Lean-Startup: lean applied to digital innovation", is devoted to the first of the three capabilities, the co-construction of digital solutions with its users. The Lean Startup approach can be broken down into three phases. The first, which corresponds to the application of Design Thinking, consists of observing, then formulating and testing hypotheses about the needs, latent or not, of future users. This step, which is the most important, results in formulating a promise to the customer, that of responding to a real need. The second step iteratively selects the different elements of solutions that contribute to solving the problem, in the form of a minimal product. This minimal product, the MVP, is updated frequently and iteratively, based on explicit and implicit customer feedback. The MVP is instrumented to make it possible to discover the uses and validate, or invalidate, the elements of the solution. The third step, often referred to as "Growth Hacking", continues this iterative tuning to make the experience simpler, compelling, and viral. The digital product becomes a support element of its own marketing and commercialization. The development of virality is based on building a community of enthusiastic users who become ambassadors of this new experience.

2.2 Exponential Information Systems

Chapter 4 is entitled "The Information System as a Foundation for Digital Transformation". Its theme is the construction of an IS capable of frequently renewing itself and, therefore, of being able to use the continuous flow of software progress, such as artificial intelligence and machine learning which will be the subject of the following chapter. There is a clear parallel with "exponential organizations" and we find similar ideas in the architecture of the exponential information system: importance of interfaces, openness to the outside, modularity. The information system is the backbone of the management of the company and the development of digital platforms that serve as interfaces with the outside world, whether they are customers or partners. The digital information system must therefore be responsive and agile, while guaranteeing a flawless quality of service that is expected by customers in today's digital world. A constantly evolving information system that absorbs new functions must be designed, and above all maintained, to limit its complexity. This chapter deals with design techniques and management methods to limit technical debt, guarantee resilience, and optimize quality of service.

 

 

The next chapter, “Taking advantage of exponential technologies”, is devoted to artificial intelligence in the broad sense, a family of computational methods and techniques that give software significant capacities, from the processing of knowledge to the automation of data-driven complex tasks. The digital revolution - the abundance of data, the ubiquity of connectivity and the dramatic increase in computing power - has led to spectacular advances in artificial intelligence techniques. Chapter 5 deals with the implementation of these exponential technologies in the enterprise, and the conditions for success from the point of view of host technology systems, such as the information system. This implementation relies primarily on the architecture and data infrastructure of the enterprise. Developing solutions that take advantage of advances in artificial intelligence is a lifelong learning loop, which simultaneously improves data, algorithms, and usage. The role of human operators in the development of this virtuous cycle is fundamental, artificial intelligence is a skill to be developed, not a magic technology that should be acquired.

Chapter 6 focuses on the systemic conditions for building an exponential information system and is entitled "Governance, architecture and situational potential". The first section looks at the conditions, in terms of culture and organization, for lean and agile software development practices to develop harmoniously. The lean approach strengthens agile practices to better address the complexity and the size of information systems. The two keywords of the necessary governance are flexibility and responsiveness, especially in decision-making. This approach also applies to system architecture, to combine long-term durability, performance, and agility of systems. The role of architects evolves with the implementation of lean and agile approaches, but the importance of service-oriented architecture (SOA), modularity and reusability of APIs only intensifies in the context of digital transformation. Furthermore, a system that constantly evolves through incremental approaches runs the risk of continual increase in complexity. Governance must be established to master complexity in order to produce sustainable development of the company's digital capabilities

2.3 Software Platforms and Digital Services Factories

Chapter 7, “DevOps and Software Factories,” addresses the third capability that is essential for successful digital transformation: to organize software micro-factories using the DevOps approach. This chapter develops an integrated vision called “lean software factory” in successive stages. The first step is to automate the software product development process, to achieve continuous integration and deployment (CICD). The second step is to place this CICD process in a product loop organized around cross-functional teams that combine development and operation responsibilities, hence the name DevOps. The DevOps approach is both a collaborative approach (development improves the automation of operations, and continuous feedback from operations improves development), a technological approach (using tools that treat infrastructure as a scriptable resource in order to increase automation) and a “product” approach (unlike an IT project, there is not a beginning and an end, but a constant cycle of delivery and improvement). Adding lean practices to the agile approach takes on its full meaning through the product approach. The Lean Software Factory is a learning factory, which develops both the love of the customer and the love of code that we mentioned in the introduction.

The next chapter is entitled "Stable Platforms for Changing Services". It deepens the contribution of the platform concept to digital transformation, as highlighted in Designed for Digital. The platform is both an extraordinary value accelerator, thanks to the power of network effects, and an intermediation tool with an open ecosystem of partners. Knowing how to build digital platforms is therefore a necessity to achieve the ambitions of openness and of leveraging the capacities of digital ecosystems. The platform approach can also be developed more locally, as a "product platform", to accomplish some of the objectives described in Chapter 4: to increase modularity, reuse, and the development of internal user communities. This chapter highlights the adequacy between the construction method developed in the previous chapter, (software micro-factories) and the operating requirements of a digital platform. The third part is, therefore, an illustration of the principle of this book: the skills and the manufacturing methods determine the speed and the quality of the execution, which are the essential conditions for the success of the strategy. This applies both to the entire digital transformation or to the construction of a single digital platform, materialized by the emergence of its ecosystem of partners.

3. Why is Lean Relevant to Digital

3.1 Lean Roots: Continuous Learning and Continuous Adaptation

The lean roots are the principles that are common to the four components of the book : new organization patterns (Enterprise 3.0) to match the VUCA world and its digital transformation; the Lean Startup approach to co-creating digital services; exponential information systems; and Lean software  factories. The four following principles are a common thread for the book, which appears in every page:

• The VUCA nature of the world requires continuous adaptation to the environment. Lean organization principles, from Kanban to just-in-time (pull vs push), are designed to create a flow of value creation that adapts continuously to what the environment expects.
• In this complex world, the first differentiation that companies must build is the collective skills and knowledge that comes from continuous learning.  Especially critical in a VUCA word is the “meta-skills” (capability) to learn from misfits or errors. This is precisely the antifragile behavior that was mentioned earlier: successful companies in a VUCA world are not designed, they grow from the collective knowledge accumulated when the enterprise reacts to unforeseen situations. The famous “A3” of the lean practices is a cornerstone of the antifragile continuous learning behavior.  
• “Collective learning” is critical : although most learning is actually individual, in a complex world, we need both to learn as a team from each other (from lean practices such as kaizen, or the team crafting iteratively its work standard) and to learn collective behaviors that make collaboration more effective. 
• Innovation is everyone’s job : everyone is called to improve and innovate, because it would be a waste not to benefits from every single brain in the company but mostly because innovation opportunities are everywhere. The only way to adapt fast enough in a VUCA world is to make innovation (smart adaptation) a fully distributed process. Toyota’s famous motto - “to build people before they build cars” – is even more relevant in the digital world.

3.2 Lean Mindset: Focus on Customer

The book’s subtitle is “From customer to code, from code to customer”. Customer-centricity is the most salient trait of companies that succeed in the digital world. Expressed with a short paragraph, “customer-centricity” may sound shallow or weak, so I will only focus on four traits of customer-centric companies :

• Customer satisfaction is the polar star of the company’s strategy and goals; hence it may be used as to unify conflicting goals when different teams work together to fix a problem. You may remember from the Theory of Constraints that when multiple goals create a conflict, one should at higher level goals until a common factor is found.  Focusing on the user, and more specifically the user experience (a more global view of customer satisfaction) help teams to resolve their conflicts when their “ways of working and designing” do not match.
• Listening to the user is critical, it must happen frequently in a VUCA world (this is the root of agile methods). A large part of the book deals with this listening, since the digital world offers many ways of listening, even though the most classical form is still required.
• The voice of customer must be shared and made available to all workers. Once more, this is especially important in the world of digital services. Everyone in the product team must have access to the customer feedback loop.
• « Love of the product » feeds customer-centricity. This may sound counter-intuitive since focusing on the product and the consumer are often seen as different directions. However, the lean way of thinking tells that you must love the product that you build to fully satisfy your customer. This is true in general, as is expressed by many testimonies about the love of the product from Toyota teams, but is especially relevant for digital (software) products that are both “knowledge accumulators” and “customer interfaces”.

3.3 Lean System Thinking

The lean approach is strongly related to system thinking. A key tenet of lean is to help people understand the system that they are contributing to. It includes long-term thinking, which is why lean brings additional value to agile methods for software development. Without going into the details that are covered in the book, I want to emphasize:

• The importance of visual management to develop a shared system understanding. Visual management in the lean practice is not only for managing backlogs and kanbans, but it must also be used to visualize everything that is complex, from problems to architecture.
• System thinking, which is necessary to adapt the system (in the digital world, this translates into continuous architecture). Complex system thinking focuses on delays (a major source of mismanagement – think of the COVID crisis) or reinforcement loops. The book is full of practices that are mostly the management of negative loops (technical debt, weight of software) or positive ones (developing today’s skills for tomorrow’s agility).
• The necessity to keep time for regular clean-ups, exemplified by lean 5S practices. Lean advocates for clarity by removing what is not necessary, as part of regular work practices. The applicability to software development is just obvious.
• The importance of keeping “buffers” to operate below capacity level. This is one of the most important lean systemic principle – a direct consequence of queuing theory. Activity chains are more agile, adaptative and resilient when the utilization rate is kept under control and far from the “full occupancy” mode.

 

3.4 Lean Software Development

As I have told many times in this blog, the concept of “lean software factory” has been strongly influenced by “lean software development” references, such as Mary and Tom Poppendieck’s books. Here I will pick four major traits, where I see the influence of “lean thinking” in software, that I have chosen to develop in the book :

• Software craftmanship, which is the importance of the right way of working, the elegance of the solution, the insights drawn from experience, the know-how from the community, applied to software. The idea that there exists a “better way of doing things” is expressed with the lean concept of the “work standard”. This is not a “best practice”, it is the continuous and relentless pursuit for excellence.  Writing software for the digital world requires skills and knowledge, which must be valued, recognized and developed (the reverse order is on purpose).
• Right on the first time is the proper way to develop software in a digital world because the complexity and the expected rate of delivery make it too hard and expensive to fix errors later. Part of this focus on software quality is addressed through craftmanship, but it also means that we want to detect errors as early as possible – a TQM principle made a lean principle. Hence lean software development heavily relies on TDD (test-driven development) and CICD (continuous integration and continuous development). Continuous integration may be seen as applying lean principles to reduce the “integration debt” (keeping future possible integration issues without seeing them).
• Constantly care for and improve your work environment so that you can work more efficiently. The lean practice for this is « 5S » and it applies to software development as well. “Sort” in the context of software development means to clean-up dead code and to re-factor; “Systematize” tells about modular organization, from classes to packages to microservices. It also represents the application of coding standards and the organization of tests in a test-driven approach. “Shine” is about making one’s code more readable and elegant, through coding standards, code reviews, improving the scores from qualimetry tests. “Standardize”, in the lean sense, is the continuous improvement of the team way of working.  “Sustain” is about making these “standard” practices a regular behavior for the team, so that long-term benefits may be reached.
• Code that is required to be changed regularly and shared for collaboration needs to be loved. The use of “love” here emphasizes the subjectivity of what “elegant” or “good” code is, but the business benefits are very tangible, from agility (ease of modification) and software quality (fewer bugs) to cost effectiveness (code that is easier to share, hence to reuse). One could say that the love a complex task well done is part of the lean ambition towards excellence (for anyone in the company), but this is intensified by the collaborative and ever-changing nature of software in a VUCA world. Agile methods won’t help if you own an ugly code repository full of technical debt.

 

4. Conclusion

To conclude this post, I would like to emphasize three key ideas from the “Lean Approach to Digital Transformation” book:

• Exponential Information Systems play a key role to support the digital transformation of companies, they act as a backbone for the growth of digital services. This statement is shared with many recent excellent books such as “Designed for Digital – How to architect your business for sustained success” or “The Digital Transformer Dilemma”.
• Systems Engineering has never been so exciting, the constant flow of technology innovation and practices brought by the “digital leaders” creates a new playground. The “Exponential revolution” described in “Exponential Organizations” is happening now, which creates multiple opportunities that companies may leverage if they adopt the tools and methods from the best software companies, as Mik Kersten points out in the introduction of “Project to Product”.
• “From customer to code, from code to customer”: These are the two capabilities that companies must develop to succeed their digital transformation. This transformation is “grown, not designed” to paraphrase Kevin Kelly.  Exponential Information Systems grow from a lean mindset and culture, geared towards customer satisfaction and software craftsmanship.

 

 

Exponential Information Systems for a Data-Driven World

 

Today’s post is very short because I decided last month to publish this article under our new  Michelin public blog about IT.  This blog post talks about Exponential Information Systems and Data-Driven Enterprise Architecture.  The pitch about Data Strategy, Architecture and Infrastructure is very similar to what I said in the “Rise of the Data Cloud” podcast episode that was just released.

To give you a preview, here are some of the ideas that I develop in this article:

• A target data infrastructure must follow the lambda architecture principles and support both data lakes for cold analytics and event-driven data flows for hot analytics.
• Hot analytics is more resilient and agile, thus better suited to crisis situations such as COVID, when models trained with past data are no longer relevant.
•  AI and Data Engineering should be embedded into system thinking : there are no obvious quick wins (at least they are very rare) while most successes are built on reinforcing loops. Data, algorithms, usage and business value are co-developed simultaneously and continuously.
•  Advanced AI is most often hybrid AI; the most powerful integration paradigm is the “system of intelligent systems” approach.

I encourage you to visit our Michelin IT blog regularly, we see it as a platform for continuous learning, to share ideas and a passion for building the next generation of software systems.