To Grow Digital Opportunities, Ask You Developer

1. Introduction

API (Application Programming Interfaces) play a key role in our digital world. API are both interfaces, the famous “plugs” that let others connect and use your capacities (data, services) and contracts (service contracts) that brings decoupling and a form of modularity. API have become a buzzword and I must say that I talk about API a lot in my writings, including my blogposts. Let me first recall very briefly why API matter so much in our digital VUCA world.

• Architecting digital and information systems around API is a strategic necessity. It is a way to foster future reuse and to increase flexibility and agility, thanks to decoupling. It requires to think about capabilities more than functions. Capabilities must be designed and exposed with anticipation (long-term), but functions and services may be assembled both quickly and outside. I love this quote from Chet Kapoor, the former CEO of Apigee: “We need API because we do not known the future.
• “API first” is a complete mindset change, which is necessary to deliver modularity. Designing API requires outside-to-inside thinking: you need to put yourself in the shoes of the API users and to write a piece of code for a final use that you do not know. This leads to co-design with a developer community, which you must learn to grow by thinking in “product mode”, like a software editor
• APIs are the lego blocks of innovation. Innovation spurs from the meeting of needs and capacities. APIs enable the construction of a “situation potential” (I refer you to Francois Jullien or to my last book) and the wide distribution of these capabilities. APIs are the lingua franca of innovation software ecosystems. To innovate and to leverage the full potential of software communities, one must speak this language.
• Last, API are critical tools for software system modernization. Unless you are part of a brand-new company – like a startup –, digital transformation necessarily implies the constant replacement and modernization of your software assets. This is achieved through service-oriented architecture (SOA) both for construction and de-construction. To replace or kill the “mammoth” (monolith), one must “slice the mammoth” and leverage APIs to perform a smooth transition from the old to to new.      

In this list, the technical aspects of API are not critical. One does not need to be a software developer to understand the benefits and the relevance of API-thinking. Indeed, every business leader needs to understand this list, because it describes a new mental model about leveraging software ecosystems, and the contributions of other players to reach your own goals. The “Why API” is first and foremost a business strategy issue. It starts with two simple ideas: (1) the world is changing constantly – especially the landscape of digital opportunities (2) there are more smart people outside your company than inside – to borrow the famous quote of Bill Joy – so one must think as software as a platform.

However, the “How to API” has to be co-designed with software developers, both inside and outside. The world of telcos (telecommunication companies) is a great example to learn from. In the early 2000s a number of large, worldwide telcos, decided to expose their services through API. Very significant sums of money were spent to create catalogs of web services to lure developers to build new applications on top of the capabilities of the networks. However, nothing big happened; the “software culture” difference produced a service catalog that did not appeal the majority of the web & mobile development community. To develop an API strategy, one cannot pick a “if you build it, they will come” strategy; on needs to grow a community of engaged developers. Today’s post is about the new book of Jeff Lawson, “Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century”. Jeff Lawson is the CEO of Twilio, a unicorn that delivers API to developers, to interface with the various telcos of the world enabling – for instance – the easy delivery of SMS messages. I have decided to share a short review of Jeff Lawson for three reasons:

• He is de facto one of the best experts about API, software ecosystems and understanding how to bring value with a platform to a community of developers. All the four points about API that I have briefly outlined in the beginning are clearly explained and illustrated by Jeff Lawson.
• His great book is about the “Ask Your Developer” mindset, which is a critical requirement to succeed in the 21st century. This is not a book for technical readers, it is a wide-audience book that should speak to all roles in a company. This is not a naïve praise of software developers but an analysis of how digital innovation works – the foreword is signed by Eric Ries – and a plea for a role distribution that is different from what most companies do today
• This book is a treasure trove of relevant pieces of advice to companies that need to become “software companies”, which is probably the case of the overwhelming majority of companies. API, cloud, microservices are the software flavors of the moment; the success of Twilio is based on mastering these “new” ways of software development. 

2. Ask Your Developers

 

 

As usual, I will not propose here a complete book review; I will focus about the “Ask Your Developer” mindset, which is the backbone of the book. The book is not intended first for developers or for technical persons, but for business managers. The “Ask Your Developer” mindset is about asking the right questions to the right persons, about understanding the software ecosystems that all companies are part of : “Now, a Software Person is not necessarily a developer—it’s anybody who, when faced with a problem, asks the question: “How can software solve this problem?” That’s because being a Software Person is a mindset, not a skill set”; “This book, as well as the Ask Your Developer mindset, isn’t really about software. It’s about people—the software developers and businesspeople who need to work together to hear customers’ needs and answer them”. I strongly recommend to read “Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century”. Jeff Lawson writes about his personal story, his previous positions – including his job at Amazon Web Services – and the fascinating adventure of Twilio. He also gives many examples about companies that get this mindset right, such as Amazon or ING : “One of those rivals is located just across town—ING, whose roots reach back to the 1700s and which manages more than $1 trillion in assets. It’s about as far from a startup as you can get, and it competes in an industry that is notoriously stodgy, risk-averse, and highly regulated. Yet ING has become one of the most innovative software development organizations in the world”. Because Twilio delivers communication API to many companies in the world, which are at the heard of digital customer relationship and engagement, Jeff Lawson has a great view of Digital Transformation as it happens in his customer companies. His messages are, from my point of view, spot on. As he notices, the current acceleration of digital transformation caused by the COVID crisis makes this message even more urgent than before: “Customers will become accustomed to these digital experiences, and expectations will just continue to rise quickly. Companies that get this right will have loyal, engaged, productive customers. Those that don’t will struggle even more than before the COVID-19 crisis”. My short summary of this book will focus on the three key messages that Jeff Lawson underlines in his book: “Company leaders who build industry-changing software products seem to do three things well. First, they understand why software developers matter more than ever. Second, they understand developers and know how to motivate them. And third, they invest in their developers’ success”.

 

2.1 Software is Eating the World, Hence Digital Transformation is a Mandate

Readers of this blog know that Marc Andreesen famous quote (and article) about “software eating the world” is one of my favorite. This is also a starting point for Jeff Lawson: “Building software has become existential for companies across nearly every industry. Digital transformation has gripped nearly every company as the threat of digital disruption has completely challenged how companies operate”. Thus the theme of the book is not simply about getting more value from you product development or your IT department, it is about succeeding your digital transformation to survive in the 21st century: “so the Ask Your Developer mindset isn’t just a way of making developers feel appreciated, it’s a new way of operating to succeed in the digital economy”. Following the same thought process that Mik Kersten shares in the beginning of his book “Project to Product”, there is good news and bad news with the necessary software ambitions for most companies. The bad news is that this is a survival matter – because software is eating the world – the good news is that the tools, the practices and the mindset of the software giants are accessible once a company puts it mind on it : “Every kind of company can become a software company—all you have to do is internalize the value of rapid iteration. You don’t need to be Elon Musk or Jack Dorsey; you just need to believe in the power of iteration, and Darwin will be on your side. But of course, to iterate, you first need to build. You can’t iterate on something you’ve bought off the shelf. That’s why it’s Build vs. Die”.

This quote shows the strong message of Jeff Lawson about software ecosystems. To succeed in one’s digital transformation, each company must understand and reuse much of the software capabilities that are already here – which is one of the reasons why one should Ask Their Developers – but it must also build its own differentiating capabilities : “But in fact companies succeed at digital transformation not just by using software but by building software. Startups like Uber, Lyft, Airbnb, and Spotify have become household names because they’re really good at building software”. The book gives a great testimony about Amazon realization of itself as a software company: “But Jeff came back with an answer most of us didn’t expect. “Amazon,” he said, “is not a retailer. We’re a software company” … “Our business is not what’s in the brown boxes,” he said. “It’s the software that sends the brown boxes on their way”. The success of many startups, Amazon included, comes from their capacity to leverage the new – and constantly increasing – powers of modern software tools : “These two trends became apparent in the early 2000s. Suddenly startups that were great at building software, and had no legacy infrastructure or storefronts to deal with, began springing up. These digital native companies focused their early energy on creating great customer experiences, and they used their software-building expertise to their advantage. The new playing field was digital, and they brought an A-game”. Bringing an “A-game” is about talent, bringing in and keeping, the best software skills. So there are two sides to the “Ask Your Developer” mindset: one is about getting more value from your existing talents, the other is about creating an environment that attracts and nourishes these talents : “I’ve talked about why it’s so important, and easier, for companies to become software builders. To do that, you need talent. In the coming decade, the winners will be companies that build the best software—which really means, the companies with the best software developers”. As mentioned previously, the “Ask Your Developer” transformation is enterprise-wide and needs to reach every position in the company: “Ask Your Developer isn’t just a skill set—it’s a mindset. Over the last decade, I’ve met so many people who exhibit this mindset, in every function—from finance to customer support, from marketing to operations, from sales to product—who are building the future of their respective companies as digital businesses”.

2.2 Writing Software is a Creative Activity

As a software developer myself (I should write amateur software developer these days), I must confess a bias: I was delighted to read about the importance of creativity in software development. Although a Math major, I could not agree more with Jeff Lawson: “Writing software is more similar to making music or writing a book than it is to doing math or science”. One could write an entire blogpost about this statement because it holds the VUCA key of digital transformation. There are many domains where software development is more like maths than music. I started my career and PhD dissertation on compiler design, where mathematical skills and abstraction is the rule of the game. But as we turn into the 21st century and as we focus on human-centric software where user experience design is the key to success; creativity, experience and aesthetics (the sublimation of practice) become the key success factors, hence the analogy with music. Jeff Lawson offers many quotes from one of the most revered software thinker in the industry: “I’ve always thought that engineering is one of the most creative jobs in the world,” Amazon’s CTO, Werner Vogels, says. “Every day you get to create something new. Engineering is an extremely creative profession. Not all engineers are trained to become creative players. But it can be taught over time”. It is important to notice that creativity does not preclude discipline and the use of tools – a statement that I make each time I hear criticism about the “software factory” term – as we shall later see, the book covers in depth the need for automation and the importance of DevOps practices.

Once you understand the importance of creativity, you derive that context is critical: developers must understand the “why” to perform their jobs fully. In my own book, “the lean approach to digital transformation”, I recall our experience at AXA’s digital agency, where we found that it was mandatory for developers to be given not only the user stories, but also the pain points that were detected during the design thinking phase. Good agile practices require user stories to be descriptive and user-centric (hence the name), but the problem that the product is trying to solve should be fully disclosed to the developers: “Enabling the developer to deeply understand what the user needs, and then letting them meet it, is what sharing problems is all about”. This is one of the main message of this book : you should bring talents with technical and software skills as early as possible in the design of a product: “I’m convinced the key to building a world-class engineering culture is bringing developers into the big problems you’re trying to solve, and leveraging their full brains. It’s not too hard to tell if that’s happening in your company. When you see a developer, ask what they’re working on, and what customer problem it’s going to solve”. This mindset, of bringing a technology view early into the business discussion, works both ways: it produces better solutions and it produces better engagement. This is underlined by Werner Vogels: “Engineers sometimes need help to realize that nontechnology companies are filled with important, challenging, and difficult technology problems that would be really cool to work on. “I’m finding there are a lot of very interesting challenges in every large corporation”.

 

2.3 Winning the Software Race is Hard, this is a Competitive World

 

I have written my recent blogposts reviewing books that notice that digital transformation is hard and that succeeding with the new “digital offerings” is definitely a challenge for most. This is not a surprise for Jeff Lawson: “Building software is incredibly hard, and building a culture of digital innovation is even harder”. On the one hand, this is the good news that we noticed earlier, much is available about how to do software development right, small startups demonstrate this all the time. On the other hand, good software development requires talents, experience (lots) and the proper tools and environment.  The 21st century is indeed very competitive, it is not enough to churn good software, you need to do it fast: “Another challenge is speed. Digital natives can turn a great idea into production code in a matter of weeks—or even days. They roll out new iterations every day. For traditional companies, keeping up means speeding up. “You can no longer afford to spend six months or twelve months in development before you launch,” Vogels says”. Speed is critical, and it requires discipline, skills and practices. There is no quality versus speed trade-off in this new world, both are mandatory: “As I’ve noted, the cadence of software innovation is faster than ever before. Turning customer insights into products is happening at a lightning speed in this digital era. Yet there’s often this question of whether teams should move quickly to capture opportunities and respond to customer needs, or whether they should move more cautiously, ensuring that everything works properly, scales well, and is bug-free. However, at really good software companies, this is a false dichotomy”.

 

The focus on the developers’ “environment” is critical: the whole company is part of the software development environment. The complexity of our VUCA world means that the idea of “software development in an isolated (organizational) box” is practically over (as noticed earlier, there are still domains where full specifications and waterfall development are practical and deliver value, but they are more the exception than the rule). Becoming a software company is an enterprise-wide transformation: “If you want to become a software builder, you need to start by changing the mindset of the entire organization. It’s not enough to just hire a bunch of new developers, or to change the way developers do their jobs. None of that will work unless you also change the culture around them”.  Transforming the company is a strategic endeavor because success requires to develop new software capabilities: “you can’t buy differentiation. You can only build it” ... “Looking ahead, the companies that harness the power of software to deliver the best digital customer experiences will survive and thrive in the digital age”.  In this post, I will not cover the talent shortage topic although it is today in the top of mind of most CIOs that I know, myself included. However, Jeff Lawson talks about the obvious shortage of talents that the COVID crisis has even worsened: “There’s a shortage of developers in the world. In 2019, there were four times as many open software jobs as there were new computer science graduates”. In the spirit of the global advice to link developers and business as much as possible, he sees the recruitment of software talents as a key priority for senior business management: “when you’re recruiting top technology talent, they should be involved. Ideally your CEO already knows why technology is important to the company, intends to work closely with your top technologists, and therefore already intends to be part of the recruiting process”.

 
2.4. In the Digital World, Doing and Thinking should be Mixed 

The root cause for missing the opportunities that are offered by the exponential development of digital technologies is Taylorism, that is the separation between thinking and doing. The over-emphasis on processes, coupled with specialization and hypertrophy of roles, create segmented development processes where much of the potential value is lost: “The cold, dispassionate process of software development common in some companies is a tragedy both for the business and the developers. I see it as a failure to fully realize the potential of this amazing talent”. In the digital world thinking and doing must be mixed, product development is a cross-functional effort. Thinking get constantly enriched and modified by what one discovers while doing; doing must adapt continuously hence thinking is required. This means that the business and the software skills must be applied at the same time, in a iterative manner: “I think there’s often a false divide between businesspeople and software developers. At many companies, there’s a disconnect between the way businesspeople think, and what they want to accomplish, and what the software developers in those companies think they’re supposed to do”. Business decisions are intertwined with technical decisions, which is why developers must be involved early on: “Oftentimes, these decisions to not leverage cloud services are made at the top because . . . strategy. I think this is foolish. Executives should look to their developers and technical talent to help make these decisions”. The clear piece of advice of Jeff Lawson is “to let business experts and developers work together, early in the development process, to co-develop the strategy, the design and the product”.

Breaking the Taylorism in favor of cross-functional teams and adopting the “Ask your developer mindset” is, as we stated above, both a way to unlock more creativity, innovation and efficiency, and also the best way to become attractive to software talents : “If you’re having trouble hiring great technical talent, or worse yet, you hire them but they’re leaving before they add value—Ask Your Developer can help you create the conditions to attract and retain great developers by unlocking their intrinsic motivation to build”. Creating cross-functional teams with diversity in skills and profile is better achieved when the team members focus on problems first. Diving onto the solution is probably the most common errors in many companies since it produces second-rate quality products and frustrated teams. The deep exchange about customer problems is the best glue to grow collective intelligence: “the key to getting businesspeople and developers to work well together is for the businesspeople to share problems, not solutions”. As you build your software development team, the fundamental ask of your developers, your architects, and your technical leadership is to pick the right areas to build. This is clearly one of the strong points of Amazon: “Business leaders like Andy Jassy provided leadership guidance and wisdom, but really created an environment for technical leaders to flourish and add business value, not just code”.

Eventually, this is all about tacit knowledge. People with software development experience can make better and faster decisions not because they bring more knowledge to the discussion, but less. This is a critical trait of complex situations: you cannot summarize everything on the Powerpoint, nor should you. Companies need to rely on experience and delegate the decision closer to the ground. Jeff Lawson uses the term “bikeshedding” to characterize those meetings where there is an avalanche of technical details that make it hard to focus on the real issues, something that most of us have seen in our professional lives. This is often the consequence of a lack of experience, and the fear of missing out : “Bikeshedding, therefore, is the tendency for nonexperts in charge to expend a lot of calories on unimportant details, because they lack the context to make the most important decisions”.

2.5. Intrinsic Motivation Rules in the 21st Century

Jeff Lawson is a big fan of Daniel Pink and his best-seller, “Drive – The Surprising Truth About What Motivates Us”. Frankly, I find that everyone should have read this book or at least be familiar with the overwhelming evidence that science has collected about motivation. Still, as Daniel Pink noticed ten years ago, “There is a gap between what science knows and business does”. If you are not familiar with Daniel Pink, you must definitely watch this world-famous video. Fortunately for Twilio members, Jeff Lawson has understood that extrinsic motivations does poorly in a complex world and that, once fair compensation is offered, companies need to focus on intrinsic motivations: “Once you meet the bar of fairness, employees focus on the real reasons for work: autonomy, mastery, and purpose. I believe this is especially true for developer”. His book recalls the main findings of Drive, and how they are applied to the management of developers. An original contribution of the book is to introduce us to a collection of highly skilled developers, to help us understand better how they think and how they work. He also speaks a lot about hackathons, one of the easy way to reveal software talents: “More interesting, from my perspective, is what this reveals about developers themselves. The people who participate in these hackathons often work for companies that treat them like code monkeys. Thorn invites them to spend a weekend trying to solve an important and difficult tech problem—how to wipe out child sex trafficking—and gives them complete freedom. And guess what? They shine. These mild-mannered cubicle dwellers turn into superheroes. Imagine what might happen if their employers knew how much good these people are capable of doing”. I will reproduce here a few quotes from Kaya Thomas, as told by Jeff Lawson, since they tell vividly about what motivates software developers: “I don’t want to work in tech to fool around, I want to create amazing things and learn from other smart people. That is the culture fit you should be looking for,” Kaya wrote (italics mine). The statement I’ve italicized is probably the best distillation I’ve ever read of what young developers are looking for in an employer. Those two factors—create amazing things and learn from other smart people—are basically what all of us look for from our work”. She then adds: “There’s a common misconception that you get hired as an engineer just to write code, but communication is a huge aspect of the job. How do you take very technical ideas and make it possible for people who aren’t engineers to understand them? You need to learn about code reviews, how to give a code review and how to receive one, and how to learn from that information. You need writing skills, to create technical documents. You need public speaking, to be able to speak at conferences, or just to get up and disseminate information to other teams.”

2.6.  Modern Digital Organizations are Continuous Learning Organizations       

Because technology is constantly changing, a modern software development organization is foremost a place of continuous learning: “An open, learning environment is one where the organization is receptive to not having all of the answers, is comfortable with uncertainty, and strives to get better every day”. Jeff Lawson was trained as a lawyer, he is repeatedly promoting in his book the Socratic method of learning, through asking many questions : “ We want to teach employees how to teach themselves. That’s the essence of a learning environment. We’re building a mindset, a way of analyzing and solving problems. The Socratic method is as effective with business problems as it is with complex legal cases”. Asking questions about customer problems is the easiest way to create a common perspective : “You can do this, too—it’s easy. Another thing to ask your developers: during product reviews, start the conversation with the customer problem”. This leads naturally to the lean roots of learning through problem solving: “The way you get there is repeatedly asking “Why?””  and its “Five whys” practice. This is the best way to learn continuously from operations problem, through “blameless postmortem : “We, and many other software companies, do this via a ritual called the “blameless postmortem.” The purpose of the blameless postmortem is to dig below the surface of some kind of bad outcome to the true root cause, and address that as an organization”.   

The focus on constant and iterative learning is emphasized with the reference to Lean Startup and leads to numerous explanations about how Agile software development is implemented at Twilio: “While there are many ways to implement Agile development, they all revolve around three main ideas: anticipating change, chunking up work, and maintaining close collaboration between the business and developers”. Anticipating change is clearly the landmark of 21st century development. One should expect changes during the development process and organize oneself to welcome such changes as (differentiation) opportunities. The second agile principle underlined by Jeff Lawson is about small value delivery increments, popularized as sprints: “chunking up work as you go, into units that are manageable, predictable, and implementable …  This process is designed to make each work item predictable in scope and time to implement, giving a high degree of confidence to the work”. This is the key ingredient of agility: breaking into small manageable units and not reverting to the fallacy of adding more resources : “Who wouldn’t want more budget and head count!? The reason is that throwing more people at the problem, especially if a project is in progress and running behind, is not likely to help. In fact, it’ll probably further delay the project”.

2.7. Innovation Requires Experimentation, Experimentation Requires Best-In-Class Infrastructure.

 

The Lean Startup approach is a learning engine that delivers units of learning through controlled experiments. Controlled means that, through innovation accounting, assumptions are made explicit, then validated or invalidated through experiments carried with a minimal viable product. Innovation requires experimentation: “This is how innovation works: experimentation is the prerequisite to innovation. The more quickly and cheaply you can run experiments, the faster you’ll eventually find something that works”. Experimentation is required because the world is too complex, and nobody knows what is going to work for the customer or not: “That’s the essence of experimentation. It’s also the essence of the Lean Startup revolution started by Eric Ries, who wrote the foreword to this book. If you can try things in a low-risk way and quickly learn about your customers’ needs, why wouldn’t you ?“.  The unpredictability of digital successes apply to everyone, including Amazon: “In his 2015 letter to Amazon shareholders, Bezos reminded investors that three of Amazon’s biggest successes—Marketplace, Prime, and Amazon Web Services—began as experiments, and that, when they were conceived, nobody knew whether they would work or not”. Consequently, Jeff Lawson has made Twilio into a very impressive experimentation engine: “At Twilio we’re always trying to run as many experiments as possible. We ship new versions of our product over 120,000 times per year—more than 300 times per day”.

 

Experimentation requires both speed (to run many of them) and discipline (to learn, you need to be clear about your assumptions). It is critical to write your assumptions down:” Having a hypothesis, and a set of assumptions to prove or disprove, is great—but you need it in writing so you can track progress. At Twilio, one of our core values is “Write it down,” and experiments are a great place to exercise such a practice”. Discipline is a critical: “You build products for your customers. It’s not like, ‘Let’s go build some technology in the wild and see what happens with it,’” Werner Vogels says. “You need a very strong mechanism to make sure that you know exactly what you’re going to build for your customers.”

Fast and robust experimentation requires to invest into great infrastructure: “To make your developers successful, you need to invest in infrastructure”. First-class infrastructure is about capacity and speed of execution, it is also about flexibility and speed of development. Without surprise, Twilio have moved to DevOps: “This combination was crucial as we started to embrace a methodology called DevOps in building our developer platform. Even if you don’t work directly in technology you might have heard the term DevOps without really understanding what it is”. There is no surprise because production platforms are the innovation engine, the place where experiments happen, in our digital world. The time of the lab environment is over, you need to build your production infrastructure so that it may be used to run safely the multiple innovation iterations : “In short, by providing platforms and processes that helped developers build faster while still having guardrails to ensure that customers and the company were protected from truly bad outcomes, Rossi made sure that when developers moved fast, they didn’t break things too much. It turns out, great infrastructure is the foundation of innovation”. This is top reason why Google is attractive to software developers and should be looked at as a source of inspiration : “Ever wonder why engineers flock to companies like Google? Sure, the pay is good. But the support infrastructure is world-class. It’s one thing to coddle developers with free lunch and tricycles, but Google really coddles developers with great infrastructure on which to build. When your tools direct nearly all of your energy toward the task at hand—serving customers and being creative—it’s magical. The opposite is also true—when you’re fighting your tools, it’s a real morale hit”.

2.8. Customer-Centricity for Everyone

 

As stated earlier, customer-centricity is the best way to unite a diverse team around a common and sensible goal: “For a team to develop the intrinsic drive of a startup, they need organizing principles that articulate their purpose. I typically start by defining the customer they’re serving”. This applies at all scales in the organization, down to the product development squad: “Defining customer, mission, and metrics is the foundation of the small team”. Customer-centricity has become a very fashionable buzzword, but it remains a very demanding mindset which requires practice to develop the necessary behaviors : “Customer centricity, as the name implies, is creating an organization that constantly self-corrects to put customers at the center of our decisions. Like a gyroscope that resists being moved off-center, a customer-centric organization resists the many forces that attempt to deprioritize customers. But it’s incredibly hard to do, and that’s where it’s helpful to learn from the masters”.

 

Because Jeff Lawson works in B2B, he takes customer-centricity to a deep level of customer empathy (“walking in your customer shoes”) which he describes through the concept of hospitality: “Hospitality is the foundation of my business philosophy. Virtually nothing else is as important as how one is made to feel in any business transaction. Hospitality exists when you believe the other person is on your side. The converse is just as true. Hospitality is present when something happens for you. It is absent when something happens to you. Those two simple prepositions—for and to—express it all”. Hospitality reveals the key concept of customer experience, which is much larger than the service that company is delivering: “Service is the technical delivery of a product. Hospitality is how the delivery of that product makes its recipient feel. Service is a monologue—we decide how we want to do things and set our own standards for service. Hospitality, on the other hand, is a dialogue”.

 

Developing this customer-centric mindset requires to share the “voice of customer” throughout the organization. Customer-centricity cannot be delegated to some department, it is the common soul for all teams : “But by putting engineers directly into the flow of customer feedback, you achieve two things. First, you humanize your customers. Instead of being a requirements document, the developers get to hear straight from customers not just what they need, but why they need it”. This last quote is especially meaningful for me, because I have witnessed first-hand the power of sharing the customer (issues) testimonies across multiple teams when I was developing set-top boxes at Bouygues Telecom. Earlier in my career, I had witnessed the terrible situation that Jeff Lawson describes when companies overengineer their organization and specialize roles: “ But in a cruel irony, these are the types of companies that are often most likely to separate customers from the people building the product. Business-to-business companies, for example, typically employ armies of salespeople, customer success advocates, customer support agents, and domain-expert product managers as buffers between customers and the development team”. Customer-centricity starts with listening and observing. Here also, I find the following anecdote related in the book to hit close to home. I have had the humbling experience to discover, many months after completion, what users were really doing with the piece of software that I had written. Iterative and repeated observations and conversations with users is the only way to avoid this: “Back in the software shop, Ben and the others were writing programs with the assumption that their applications would fill the entire screen on a trader’s terminal. But in fact our application was in this little teeny corner of the window and they had nine other things going. They’re viewing my stuff on this tiny little window, so everything looks terrible and they can’t read it. I realized that things like font size mattered, and contrast mattered. It made me realize that the choices I was making as a developer were wrong. It was really enlightening.”

 

 

2.9. Software as a Service and Software Platforms

 

As told in the introduction, reading this book will also help you to learn about Twilio and how it was born from the desire to simplify the developers’ experience when building software products that embed communication services : “Our software would abstract one hundred years of complexity that the industry had accumulated and present it as a simple API for developers”. Jeff Lawson explains how he went to call and interview prospective customers – software developers – to find out which kind of API would be useful. He then moves to the software platform development phase at Twilio, and how they had to optimize the delivery through automation. Here is an illustrating example of the search for automation – which is how you achieve the capacity to experiment: “Jason grabbed two platform engineers, and they automated a bunch of steps in our development process. Their work slashed development time in half—from forty days to twenty days. The impact gets magnified because we develop about two hundred new Java services per year. Yes, we spent money on those two platform engineers. But their work saved us four thousand person-days per year”.

 

Thinking your software product as a platform is part of the “new” digital mindset: it tells how you propose your services to others, but also how you integrate other players services into your systems. Platforms plays two critical role in the software ecosystems : they act as market places (interfaces) to support the dynamic interplay of cooperation and they hide complexity by hiding (through service APIs) the underpinning of what is exposed in the platform : “The future of platforms will be allowing software developers to focus only on their features and their customers, and not about all the underlying systems that are required to bring software from somebody’s head to the cloud to a device and to an experience for a customer”.  Jeff Lawson uses the supply chain analogy to emphasize this point : “As I noted in Chapter 1, I believe every company that’s going to survive and thrive in the digital economy needs to build software. Thus, your supply chain matters. If your digital supply chain is better than your competitors’, you’ll be in a much stronger position to succeed”. The book quotes Amazon Web Services as a perfect illustration of the platform approach: “Its sales have grown from practically zero in 2007 to an annualized $40 billion as of the first quarter of 2020. From zero to $40 billion in twelve years, which is pretty much unprecedented growth. That’s why it’s obvious that this business model—the platform business model—represents the next big thing in software.

 

 

2.10. Modular Architecture, API and micro-services

 

The power of APIs to achieve loose coupling through abstraction (encapsulation of complexity) is why they are so useful to build resilient, future-proof and modular systems, as explained in the introduction. Modular systems aim at being more resilient because the amount of information and knowledge that must be shared decreases. Jeff Lawson emphasizes this point : “I believe the goal isn’t better collaboration; it’s actually less collaboration. Great companies don’t say: “I need better customer support.” They say: “We should reduce the need for customers to contact customer support.” In the same way, great companies reduce the need for teams, and individuals, to collaborate by standardizing or productizing the interactions between the groups”. The COVID crisis has shown that modular architectures are more resilient “ The crisis also showed how much faster it has become to build and deploy software. Software building blocks, microservices, and APIs have radically accelerated the process”. This way of thinking about modularity and API was made famous at Amazon : “In 2000 Amazon had a giant monolithic mess of engineers and code powering the fast-growing retail business. Engineers were stepping all over each other, and the coordination energy to get anything done was massive. Things were slowing down, so Bezos wrote the “two-pizza team” memo proposing that they divide the company into small teams in order to move faster .. if teams were organized into startup-like sizes, if they owned their road maps and they owned their code so they could move quickly, they could act like startups again, just as they had in the early days of Amazon, when Jeff remembered they could feed the whole team with two pizzas”.  The power of the small team approach it to be able to focus fast on a customer problem (“That’s the power of a small team—there are no proxies; you’re just directly solving customer problems with your code”) provided that the modularity of the complete system’s architecture leaves enough autonomy to the team.

 

This quest for small team autonomy has led to the concept of microservices. The team runs its own system, from development to operations (hence, with DevOps practices), to deliver its own units of value through APIs: “These microservices were delivered not as a pile of code, nor as a website, but as a web-based API. APIs are well-defined interfaces that enable code to talk to other bits of code. Once a team builds and exposes an API to others, it’s important that they teach other teams how to use it via documentation that’s accurate and up to date. So at Amazon, an internal culture of API documentation arose. One team could find another team’s API documentation and start using their services, often without even needing to talk. This enabled the teams to effectively work together, solving the coordination problem”. Once the SOA (service-oriented architecture) patterns emerges, it is a great blueprint to separate between what you build and what you source : “My rule of thumb is that for anything that gives you differentiation with customers, you should build. Software that faces your customers, you should build. … But for most back-end operations, and for things that won’t give you any differentiation with customers, you should buy. You aren’t going to build your own email. Or your own database software”.

The development of microservices is not the result of planed and careful design, it emerges from a Darwinian process of experiment and usage consolidation. This means that duplication of effort is a temporary byproduct: “This may be part of why I’m often asked how we prevent duplicate work in our small, empowered teams culture. My answer is: we don’t”. The key insight is that sharing/ reuse / mutulization emerges from experience, not from design. To focus too early on reuse at the design phase places too strong a complexity burden on the teams’ journeys: “We allow our teams to charge ahead and lead the way. Then, as technical leaders and architects, we watch for the patterns to emerge. When we see multiple teams all inventing similar things you can step in, observe the trend, and staff a team to go solve that problem for everybody—thus achieving efficiency. That’s the essence of platforms. But instead of trying to perfectly plan it out from the top, let teams organically show you the path”.  This the reason why system architecture is a continuous process. Notice that Twilio inherited this view from Amazon, as stated by Werner Vogels: “Amazon also prefers speed and doesn’t obsess about duplication, … We allow teams to just do a lot of things themselves, even if that duplicates some functionality. We’re willing to exchange that for moving fast”.

 

4. Conclusion

 

I will conclude this book review with the emphasis about three key ideas:

1. Taylorism is counter-productive, diversified roles must collaborate and thinking and doing are mixed in the development process.
2. Ask your developer does not mean “leave it to your developer” – it means: (a) to grow cross-functional teams (b) to ask the doers as early as possible in the product lifecycle.
3. Micro services are both a system architecture pattern (about modularity and API) and an enterprise organization pattern (about networks of autonomous teams). It is not something that you design, it is something that you grow. It grows from usage, but it requires constant care (refactoring) similar to gardening.

 

 

 

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.