Lean Startup and Lean Software Factory

1.      Introduction

I had the pleasure to attend and talk at the Lean IT Summit in Paris last week. The first keynote, entitled “Lean Journey: what have we learned ?” was given by Dan Jones, the world-famous author of the Machine that Changed the World, the “book that introduced lean production to the world”.

I encourage you to watch the video as soon as it gets available on the Lean IT Summit web site. Meanwhile, here is a short selection of some of the most salient key points:

• Convergence is happening, between lean and software, because as Mark Andreessen said, “software is eating the word”. Convergence means interplay: Lean software development has become a key theme of this conference for many years, while software development issues are becoming central to any production process, making the convergence between lean and IT critical. Dan Jones notices that lean works very well at the team level for IT: agile, scrum, Kanban … or Devops, seen as a great example of lean single flow continuous stream.
• Lean is, foremost, a management system about learning. The imperative of continuous learning applies to all : front-line operators to all level of managers. Dan quoted Amazon as an example of a learning company that is trying things all the time. Learning from the customers is critical, from their feedbacks and using short cycles. One learns from daily practices, with the practice of measure to learn scientific discipline and to avoid jumping to conclusions.
• Dan made a great review of the lean foundations: understand the work, break in small increment, standardize, that is, codify best practices to define the baseline for continuous improvement (standards are different from one team to another), etc.  Tools are important, they provide the scaffolding for learning, such as visual management (critical to create the see-the-problem culture). Lean is something that is self-learned: You cannot simply invite experts to come and show it to you.
• While visiting a back-office in a bank, Dan Jones noticed how much rework is one of the major plague of IT departments (something that I have seen firsthand), due to silo mentality and organizations being still jealous of their boundaries. When technical people do not know about their customers, inefficiency is unavoidable. This does not do justice to Dan’s testimony, when I head it I twitted “customer-centric software is eating the world while siloed software is eating dirt …”.

2.       Lean Startup – A Global Perspective

Lean Startup was a common theme to the first half day of the summit. Dan Jones defined Lean Startup as the combination of design thinking and using small increments to get to fast production, in order to get enough of a design in a first product to get feedback and start continuous learning and improvement. I gave my own lecture later on about the use of Lean Startup at AXA Digital Agency. I was following Susana Jurado  who talked about her experience with Lean Startup at Telefonica, and followed by Pierre Pezziardi who talked about the French government incubator.

My vision of Lean Startup is broad, as shown in the following illustration which is inspired by a schema from Dave Landis which we have extended at AXA together with Stephane Delbecque. We see the Lean Startup cycle covering from problem definition (with a clear influence from Design Thinking) to continuous growth (Growth Hacking) through the definition of a Minimum Viable Product. This broad vision is coherent with the scope of the seminal book by Eric Ries.

The slides and the video of my talk will also be available soon. Here is a show overview of the three parts which are portrayed in this schema :

1. Design thinking is about identifying a problem that matters and crafting through dialog and prototyping a promise called a Unique Value Proposition. Pain points must be collected analyzed through a lot of observation, resulting in the definition of the “job to be done”.
2. The central idea is to build a true product “that does not do much but does it very well”. The minimalism of the MVP is what guaranteed the lean principle of getting to meet the customers as soon as possible to learn from them. But the lean principle “right on the first time” applies as well: customers have no patience for half-baked stuff. The solution of this conundrum is to focus: select very few user stories and deliver an amazing solution. This is what Nathan Furr and Jeff Dyer are calling the “Minimum Awesome Product”.
3. Once the MVP is out, the real life starts – one must grow customer satisfaction. Growing customer usage and satisfaction is a co-learning process where feedback and iteration plays the central role. By listening and measuring, one may validate or invalidate the assumptions made during the design phase. By harvesting and improving what works for the customer, the goal is to reach the “Product market fit” and then scale (fuel the growth proactive & viral marketing) – what is described as “nail it then scale it”.

3.      Dual Processes from Customer to Code and Code to Customer

I concluded my talk by stating that “Lean Startup must co-exist with the new requirements of producing software in the digital word”, which is another ways of expressing the “convergence idea” of Dan Jones. Two years earlier, I had given a talk at the Lean IT Summit about “Lean Software Factories”. Lean Startup and Lean Software factories are closely related, they are two faces of the same “digital innovation question”. The following picture expresses this as a set of dual processes:

• A product design process (from customer to code), that is embodied by the Lean Startup approach as described earlier
• A product delivery process (from code to customer) that is embodied by the Lean Software Factory metaphor, although I could also have selected Devops to capture the continuous build and delivery.

Obviously, the representation with arrows is misleading because, as shown in the previous picture, none of those two processes are linear. There are sequences of intertwined iteration loops. You do not apply Devops once you have built a MVP, but precisely to deliver this MVP and its successive evolutions.

What this picture expresses is that a great digital company must excel in both dimensions : to produce digital innovation and customer satisfaction though a customer-centric co-development process (Lean Startup) and to achieve excellence and speed in iterative delivery. A digital company produces experiences that are delivered through lines of code. The may KPI is speed, which is necessary to be innovative (first on the market) and, foremost, relevant (customer satisfaction stems from iteration, which requires speed).

Another way to say this is that you cannot be great at Lean Startup if you do not master the fast software delivery process, and that you cannot implement develop and reach the rewards of agile development if your company does not embrace the iterative, customer-centric, lean principles of Lean Startup product development. This is explicitly explained in OCTO’s book, “Les Géants du Web”, where digital innovation best practices are expressed both along the lean startup / culture  and the DevOps / technology mastery  axes.

4.      Multi-Stage Learning Engines

As Dan Jones mentioned in his keynote, or as Michael Ballé explains in his books, the lean journey is mostly about learning. What makes the dual process of the previous section work well, and work well together, is the skills of the teams. These skills requires efforts and time to be learned. The following picture shows a complex system with three actors: the consumer, the product and the team. There is learning and adaptation everywhere:

• The consumer learns from the product: it takes time for the consumer to discover and understand the product. Good design - which is about reducing friction and increasing pleasure - makes this as fast and as pleasurable as possible, but it still takes time. There is a learning curve associated with each innovative usage. 
• The product will “learn from” the consumer through feedback (the heart of the lean product development cycle). The core principle of Lean Startup is that one needs this feedback to manufacture really great products. Some of it is old-fashioned (listening to customer complaints and solving problems), some of is more “digital” (machine learning and big data from real-time analytics).
• The team leans from building the product: there are skills that you only learn by doing. You can think, design and train all you like: it is only when you start the production adventure that real life happens and that some of the hard skills may be learned.
• The product learns from the team: the product can only improve when the team grows its skills and knowledge.               

In these four learning loops, there are delays everywhere, and obviously interaction (co-dependence of these learning loops). Quite logically, this is hard to grasp, understand and accept by upper management. There is always a delay between cause and effect. Good decisions usually create the context (empower the team or the product) so that learning may occur, and value (customer satisfaction) happens later. Because of this complexity and these delays, I have seen projects killed at the wrong moment many times: the hard/difficult point had been passed successfully, but the benefits was not yet visible.  This is clearly related to what makes complex systems complex, especially our difficulty to understand loops and delays (cf. the sixth keys on my previous post about complex systems).

This schema does not necessary talk to every reader but it encapsulates two key ideas. First, there is a lot of learning that must take place before Lean Startup and Lean Software start to deliver massive improvements, both in time-to-market and customer satisfaction. Second, there are too many loops and delays involve to maintain the “illusion of control”. The art of lean product development is an emergent practice, something that you grow over time, not which is decided and rolled-out.