Sunday, May 3, 2020

Agility at Scale and Lean Software Development

1. Introduction

I have just finished writing a new book about the lean approach to digital transformation, where lean and agile software development methods receive a fair amount of attention. This has led me to read about SAFe and revisit my opinions about the best ways to perform Agile at scale. SAFe (Scaled Agile Framework) has become the de facto standards for agile at scale, but there exists a large amount of controversy and debates about SAFe. On the one hand, SAFe addresses a real complex question, which is how to scale the Agile Manifesto’s principles, with software development programs of more than 100 or 1000 team members. SAFe has been around for more than ten years, with constant enrichment and improvement. Most large companies that are not software product companies are using either SAFe or something similar for their Agile practices. On the other hand, there has been a lot of warnings and quite negative opinions, such as the famous quote from Martin Fowler who sees SAFe as a poor and dysfunctional version of Agile for companies who do not have an agile mindset.

I do not have much first-hand experience with SAFe (and keep in mind that SAFe is fast evolving so early opinions need to get revised), but I have been trying to address agile at scale for close to two decades. Like most in the “large-companies agile community”, I have looked at Spotify for sources of inspiration. Over the years, I have experimented with “scrums of scrums”, “multi-squad planning meetings”, “chapters and guilds”, “backmaps” (hybrid between roadmaps and backlogs) and many tools or rites that could be easily replaced today with those from SAFe.  When I read comments from Agilists that there is no reason to scale, I find myself clearly in the “SAFe camp”: large companies do manage large programs, large information systems or large products, with many external stakeholders, that make all the questions found in the SAFe introductory books very relevant. At the same time, I have evolved my vision of agile development with lean roots over many years of practice and observations, but I have a hard time qualifying the overall SAFe philosophy of software development as “Lean Agile”.

SAFe is a development framework which, in my opinion and those expressed in “SAFe : A Collection of Comments from Leading Experts”, fights the VUCA nature of the world and proposes a very structured, detailed and rigorous method to deliver value through software development. The need to constantly learn from the (user) environment and to adapt is here, but it is nicely “boxed into steps”. There are iterations everywhere, but they fit squarely into a big sequential and hierarchical design. SAFe claims inspiration from almost all recent product development frameworks, from Lean Startup and Lean UX Design to DevOps, including all kinds of Agile and Lean software practices. These are all great sources of inspiration, but the result may be overloaded, with a loss of sight about what really matters for a “Lean Agile” approach: customer satisfaction and continuous learning. From a “Scaled Lean & Agile” perspective, SAFe gives you the bones, but not the flesh for your software development culture. If you read SAFe books with a digital product perspective, the intricacy of learning from observing and listening to your users seems lost, the critical role of user experience design is not tangible.  If you read them with a Lean software perspective, you find surprisingly few mentions of software realities and issues. Somehow, my opinion in this debate about SAFe is closer to Ron Jeffries post “SAFe- Good But Not Good Enough”.

This post is organized as follows. The main topic is the review of “SAFe 4.5 Distilled: Applying the Scaled Agile Framework for Lean Enterprises”. Because SAFe is a very rich and complex framework, this section only provides an overview. SAFe is a framework designed to address scale and flow when developing in an “agile mode” for large products, projects and program. It proposes a multi-scale decomposition with the relevant vocabulary, tools and rites, such as the famous “PI (Product Increment) planning”. I will address the depth of the lean roots in SAFe, as well as the influence of Lean UX Design or Lean Startup. The third section talks about two other approaches for scaling Agile : LeSS and Disciplined Agile. I will also use two short book reviews to support these simpler analyses of alternate scaling methods. Interestingly both approaches also portray themselves as “Lean Agile” methods. LeSS is mostly about scaling Scrum and is rich with insights and practical considerations about customer satisfaction. LeSS is the most visibly “product oriented” approaches of the three. Disciplined Agile is strongly focused on the integration of Agile, DevOps and scaling with … discipline, which makes it a close cousin of SAFe. I will conclude this post with a short comparison with my own approach of “Lean Software Factories”, which is more focused on what “Lean Agile” means for the software development squads (i.e., without scaling).              

2.  A Short Glance at SAFe

As told in the introduction, SAFE (Scaled Agile Framework) is a rich and complex framework that has evolved through the years. I have decided to use the book from Richard Knaster and Dean Leffingwell, “SAFe 4.5 Distilled : Scaled Agile Framework for Lean Enterprises” because it proposes a comprehensive presentation of the framework, because it is one of the most popular book about SAFe and also because it addresses the relation with lean in its title.  The latest edition, SAFE 5.0, was released this year, while SAFE 4.5 was released in June 2017, however this does not matter much since I will only brush the surface of SAFe principles and ambitions. SAFe was developed “by and for” practitioners, with the intent to “scale lean and agile software development practices”.  As the title of the section says, this blog post cannot deliver a summary of SAFe : not only is the book long, but it is very often shallow and points out to further readings, because SAFe is a syncretic collection of practices. I will only give you a personal summary of the key tools and principles, together with my own understanding, trying to address the questions stated in the introduction. Obviously, I want to be very clear here, this summary is biased with my own opinion, which is that SAFe is a useful framework for scaling, and a poor software development methodology (so you should bring your own). As you will notice, the first three sub-sections are very positive about SAFe and the next three are definitely more critical, although what you plan to do with SAFe really matters here : there are many kinds of programs and products for which my own interrogations are less relevant.

2.1 Scale & Flow

SAFe is foremost a framework designed to address scale issues and to maintain flow while the scale grows : “The secret to successfully implementing SAFe is to establish a continuous flow of incremental value delivery based on continuous fast feedback and adjustment. Continuous flow enables quicker value delivery, effective built-in quality practices, constant improvement, and evidence-based governance”. As a lean practitioner, I applaud the recognition of the importance of flow and I fully subscribe to the introductory principles : “ The principles of flow are an important part of the Lean-Agile mindset: Understanding the full value stream Visualizing and limiting Work in Process (WIP), Reducing batch sizes, Managing queue lengths ”. It should also be stated that SAFe is NOT a strict set of processes, rules and methods. It claims the lean definition of a standard that the team, the organization, the company (remember the “at scale” approach) must appropriate and revisit and customize if necessary : “Agile processes in frameworks like Scrum, Kanban, and SAFe do matter. However, a process is only a means to an end. When you’re captive to a process that isn’t working, then you may know what you’re doing, but ‘what you are doing’ may not be working. So, favor individuals and interactions, then modify processes accordingly”.

Scaling Agile starts, quite logically, by reviewing the Agile Manifesto principles and wondering if these principles scale, that is, keep being practical when the software organization grows. The position of the authors is largely positive: “The conclusion from this exercise is that the Agile Manifesto does indeed scale. However, many principles require increased emphasis at scale, while others require a more expanded perspective”. The principles that are identified as being the most “scale sensitive” are: (2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage, (6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation and (11) The best architectures, requirements, and designs emerge from self-organizing teams.  Welcoming changing requirements does indeed require more discipline and method when it applies to a large software organization. The practice of Change Review/Advisory/Control Board has been around for a long time, for good reasons. Building large systems that support the agile philosophy of welcoming changes requires modular architectures (to simplify the infamous feature interaction problem) and disciplined practices, which is what SAFe addresses. Similarly, face-to-face interaction is a key agile practice, that requires method to scale. Frameworks such as SAFe are born from practitioners who have experimented with methods and tool to conduct large-scale synchronization meetings, such as the PI planning events. It is also clear that the need for constant feedback does not fit easily with scaling: “Most are certainly willing to comply with the spirit of this concept. However, there are limitations on the economic practicality and convenience of daily onsite feedback from customers of large programs, though we fully agree with the sentiment”. I would actually disagree with the authors, although it more complex to organize, user feedback is required to breed lean & agile development. The last question identified here, the scaling of continuous architecture, is indeed hard to solve. SAFe at the same times advocates for continuous, emergent architecture that co-evolves with the development process, but uses a multi-scale hierarchical decomposition that may seem both too rigid and traditional for a VUCA world.

2.2 Multi-scale approach

A foundation for SAFE is the multi-scale approach, with three separate levels: the teams, the agile release trains (ART) and the large solutions. This is a classical hierarchical decomposition (multiple agile teams organize into a train, multiples trains organize into a solution), with a  strong emphasis on decentralized decision making : “As Kennedy notes, and as decentralized decision-making (Principle #9) implies, centralized planning for significant solution initiatives is problematic. Simply put, the complexity is too great, and the facts change too quickly for a centralized planning function to be effective. In its place, SAFe provides for routine, cross-domain, face-to-face planning”. There are multiple claims that SAFe is influenced by “system thinking” throughout the book. As told in the introduction, I strongly recognize scaling as an issue that most companies must face, as is described in Robert Sutton and Ruggy Rao’s book : “Scaling up Excellence”.
Because the first level of the multi-scale decomposition is meant to reproduce the “Lean Agile squad” without the scaling issues, the contribution of SAFe is foremost the second level : “ The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed-length iterations within a Program Increment (PI) timeboxEach ART is typically a virtual organization (50–125 people) that plans, commits, and executes together”. The size of this second level is no surprise : there is a clear consensus about two sizes that matter with human organization:   the team size (the famous two-pizza rule) and the tribe size, which is linked to the army (starting with the Roman army) and the Dunbar number. The right size for the second-level organization should stay below Dunbar’s number (150) so that everyone really knows each other at this second level (from an emotional connection perspective). We shall see the same scaling pattern in the next section.
The third level, of large solutions, is another level of difficulty (precisely because members cannot know each other anymore) : “Building large-scale and complex systems is one of the most difficult and challenging endeavors today”. The heterogeneity of the workforce roles, as well as the (almost all the time at this scale) combination of enterprises and suppliers make for a different type of challenge : “Building these solutions may require hundreds, thousands, or even tens of thousands of mechanical, electrical, and software engineers, not to mention physicists, scientists, medical professionals, and other experts, along with the integral contributions of an extensive network of external suppliers”.  Large solutions are made of multiple ART, which contributes to multiple value streams. SAFe organizes large solutions with solution epics: “ Solution epics are initiatives large enough in scope and cost to warrant analysis and a Lean business case. Unlike capabilities, which can be split to fit inside a single PI, solution epics usually take several PIs to develop”. I will not address much this level of organization in this post, because of my lack of personal experience building software products with a thousand or more participants (this is not the same as running a thousand-plus organization delivering many hundreds-sized products or projects, which is what I am currently doing).

2.3 PI Planning

The heart of SAFe is how to apply the agile principles, including small steps, face-to-face communication and feedback to level-two organizations (ART). As told by Robert Sutton in Scaling Excellence, this requires synchronization. The most important SAFE Rite is the PI (Program Increment) planning : “This event is essential to SAFe: If you aren’t doing PI planning, then you aren’t doing SAFe”. The PI planning is a synchronization event for the different teams from the same train, so that they can work out their dependencies and synchronize their deliveries. This is the cornerstone of “agile at scale”: “the development of large-scale systems is fundamentally a social activity”.
The scaling from teams to train requires cadence (a common clock) and synchronization (leveraging to common clock to communicate and re-align ambitions). This is a key SAFe principle : “ Apply Cadence; Synchronize with Cross-Domain Planning”, following the advice from Donald Reinertsen : “Cadence and synchronization limit the accumulation of variance”.  PI planning are critical rites, which require careful organization (because of the large attendance) but delivers lots of value (as anyone who has experienced a successful PI planning event can testify): “Whenever possible, attendees include all members of the ART. After all, the people on the teams do the work, so only they can design the system, plan, and then commit to that plan”. One of the famous SAFE tools for PI planning is the program board : “ Typically, the RTE creates a program board in advance of planning and teams update it during planning. The board highlights the feature delivery dates, milestones, and dependencies among teams and with other ARTs”.

The only word that should get our attention in a VUCA world is “planning”. On the one hand, coordination at the ART level (level 2) requires planning and synchronization. Teams must say what they will do and, mostly, do what they said to their “train team-mates”. With the proper agile tools and concepts, the time horizon of a Program Increment (e.g, eight sprints) is short enough that planning works from a capacity view: “ Trains are predictable and can reliably estimate how much cargo (new features) can be delivered in a PI”. On the other hand, this does not tell the story of value creation, nor does it capture the possible complexities that may arise from developing a user story. To simplify (a complex issue), scaling does require planning of capacities and efforts, but the root of Agile which is to adapt constantly the delivery to the feedback of the environment still prevails (planning is not a tool to fight against volatility and uncertainty). For instance, the following quote: “The primary evaluation tool of the ART is a predictability measure that tracks the percentage of business value achieved for each PI objective in the plan” is a departure from agile principles.

2.4 Focus on Value and Lean Startup

The previous point is where most agilists start to disagree, as told in the introduction : the reliance on value creation as a control metric is a departure from the agile mindset and a return to last-century thirst for control (what Frederic Laloux calls “our beautiful illusion of control”). This contradiction is expressed with what the authors call “the economic view”: “Therefore, SAFe’s first Lean-Agile principle is to take an economic view, which is founded on two basic concepts: Deliver incrementally, early, and often. Sequence jobs for maximum benefit”. The idea that the future benefits are known well enough, with a reliable estimate, so that they can guide prioritization and decisions is too narrow for most VUCA situations. The authors quote Reinertsen about scheduling for maximum benefits: “Reinertsen describes an algorithm for job sequencing called Weighted Shortest Job First (WSJF). WSJF is calculated by dividing the Cost of Delay (CoD) for a job (i.e., the value not achieved while waiting) by the duration of the job”.  This works for lean manufacturing but is much harder to apply to lean software, because the cost of delay is most often unknown. For instance, this approach does not work for digital products and services, where value creation emerges continuously from usage. The discovery of value through usage and iteration is the heart of the Lean Startup approach, which makes the constant references to Lean Startup in SAFE confusing.
The authors make multiple reference to innovation accounting in their book : “Apply innovation accounting to establish early, nonfinancial, actionable metrics that provide fast feedback on the important elements of the solution’s new concepts, features, and its associated business model”. They quote Eric Ries on this topic : “Innovation accounting refers to the rigorous process of defining, empirically measuring, and communicating the true progress of innovation—such as customer retention and usage patterns—whether for start-up companies, for new productions, or business units within established companies.” In my opinion, and according to my previous experience of applying innovation accounting to digital products, the reference to innovation accounting is misleading : innovation accounting is a tool for managing the macro-iterations (at the PI levels) not for sequencing the backlogs “according to the economic view”.

An idea that is central to the book is that development (at all scale) should focus on value. No one could dispute this but understanding and considering the fact that value is hard to characterize and even harder to predict is what makes agility so relevant (versus waterfall approaches). Saying that all resource allocation decisions, at all scales starting from the portfolio down to the backlog prioritization, should be made from the value creation hypotheses, is definitely misleading. In a VUCA world, all value creation assumptions made before the product or the service is delivered … are just hypothesis (which is precisely the point of the Lean Startup approach).

2.5 Lean & Agile

SAFe claims to be a framework to scale Lean Agile, so it is fair to ask how much of the “Lean Agile mindset” is here. Deciding if SAFe is truly a lean approach is difficult. On the one hand, there is a strong lean “system thinking” influence, and many references throughout the book, such as “The foundation of Lean is leadership, the starting point of team success. The enterprise’s managers, leaders, and executives are responsible for the adoption and success of the Lean-Agile paradigm”. As said earlier, there are many lean principles stated in the book, such as “Operating a product development process near full utilization is an economic disaster” or “Faster Learning Through Faster Cycles”. On the other hand, for someone like myself who defines “Lean Software” from the reading of Mary and Tom Poppendieck’s books, there is surprisingly little software (software issues, software practices, software principles) mentioned in the book. SAFe offers a vision of lean which is very much system-based and lacks the relationship with the gemba (the code and the people). One could say that the « software » dimension of lean is what is done at the team level (hence visual management, kaizen or 5S are not covered here) … but I think that learning and system thinking practices need to scale.

The same comment applies to the agile roots of SAFe. As shown earlier, the principles of the Agile Manifesto are quoted multiples time in the book, with a deep appreciation : “The first phrase of the manifesto deserves emphasis: “We are uncovering better ways of developing software by doing it and helping others do it.” . Many practical pieces of advice, such as “favor working software. And document only what’s necessary”, tell of the SAFe’s agile heritage. At the same time, I see two potential problems (depending on your activities and what kind of software products you are building). First, there is a pregnant scale-hierarchy built into the roles: those who manage the bigger-size items are (or sound) more important than those doing unit elements. This is very visible with the over-emphasis about architecture and the small recognition given to technical excellence and software craftmanship (the influence of hierarchical system engineering is obvious). I would strongly recommend the reading of “Lean Architecture” from James O. Coplien & Gertrud Bjørnvig as way to balance the SAFe vision: “The SAFe concept of the architectural runway provides the means by which Agile architecture is implemented”. Second, there is the “control illusion” described in the previous section: the emphasis on planning, forecast, value creation … that can quickly become a burden when one wants to lead a true agile transformation, such as a digital transformation. To illustrate with a precise example, the book advocates for parallel design (set-based versus point-based) where experience shows that this really depends on the complexity of the environment (innovation accounting does not mix well with feature interaction).

2.6 One Framework to Rule them All ?

What is striking, when one reads this book or look at the framework schemas, is that SAFe claims inspiration from most product/project methodologies, such as Agile, Lean, DevOps, LeanUX, Lean Startup … as well as many management tools, from Daniel Pink’s motivation foundations or Kotter change management framework to servant leadership. Some of the complexity of SAFe comes from trying to reconcile a very structured, step-by-step, managed and controlled linear vision with the recognized need for iteration and adaptation : “ Even though Figure 9-2 seems to indicate a linear process, in reality, the pipeline doesn’t operate that way. Rather, it’s an overlapping learning cycle that occurs within every PI, which allows teams to establish a number of hypotheses, build and deliver against them, measure results, and learn from that work”. As a proponent of DevOps for many years, I welcome  statements such as “DevOps is the cornerstone of continuous delivery and enables the enterprise to economically develop and release small batches of functionality to the business or end user, providing faster feedback and time-to-market”, but the book does not tell much about scaling DevOps. The book to read on this topic remains “Accelerate – Building and Scaling High Performing Technology Organizations” by Nicole Forsgreen, Jezz Humble and Gene Kim.
It leads naturally to the opinion, expressed by some of the experts that I mentioned in the introduction, that “SAFE is too big, with too much content”. The attempt to squeeze approaches such as design thinking, lean UX or Lean Startup is not convincing. This yields an explorative, divergent, iterative step called “continuous exploration”, that fits into the large ART schedule : “Continuous exploration is the process of continually exploring market and user needs, and defining a vision, a roadmap, and a set of features that propose to address them.” Trying to fit everything on the same schedule does not convince me: I see the benefit of cadence and synchronization for software delivery, not for value delivery. I have written many time about the need for multiple time horizons and nested loops (as opposed to micro iterations within a linear process). Similarly, the books talks a lot about “building quality in”, which is fitting to the lean approach: “ Built-in quality is one of the four core values of SAFe. The enterprise’s ability to deliver new functionality with the fastest sustainable lead time, and to react to rapidly changing business environments, depends on solution quality”. However, the book contribution on how to improve software quality is shallow at best. Similarly, the reference to lean UX, “In short, the Lean UX cycle provides the knowledge that Agile teams need to adjust and redesign—or even pivot to abandon a feature—based solely on objective data and user feedback, enabling them to iterate toward a successful outcome”, does not bring much and one wonders why lean UX is invoked here. It actually highlights the fact that customer-centricity, a key principle both for lean and agile way of working is poorly represented here. Customer satisfaction does not receive much attention here, it is over-shadowed by value creation.

3. LeSS and Disciplined Agile

3.1 LeSS : Scaling Scrum to develop software products

I will now complement the analysis of SAFe with two other competing frameworks. The first one is LeSS (Large Scaled Scrum), a multi-team scrum framework designed to scale Scrum with teams of hundreds or even thousands contributors working on the same software product. The name also tells the intention to scale with less rules, less guidelines, less methodology than SAFe. To deliver my short introduction to LeSS, I will propose a short book review of “Large-Scale Scrum: More with LeSS” by Craig Larman and Bas Vode. Since this post is already quite long, I will simply focus on five key areas and attempt to compare LeSS with SAFe. “Large-Scale Scrum: More with Less” is a beautiful book, well-written and full of insights about scaling Agile, so I urge you to get your copy and give it your full attention.

Less is Large-Scale Scrum. Since Scrum is the de facto standard practice for Agile in most companies, it makes adapting LeSS a much easier proposition: “Large-Scale Scrum is Scrum—It isn’t new and improved Scrum. Rather, LeSS is about figuring out how to apply the principles, rules, elements, and purpose of Scrum in a large-scale context, as simply as possible”. The framework aims at keeping what makes Scrum easy to understand and to adopt. The emphasis is on transparency (using things that everyone can see as beacons), short cycles, working together and common definitions. There is a strong will to keep the framework simple and to avoid adding many roles to take scale into account: “We don’t want more roles because more roles leads to less responsibility to Teams. We don’t want more artifacts because more artifacts leads to a greater distance between Teams and customers. We don’t want more process because that leads to less learning and team ownership of process. Instead we want more responsible Teams by having less (fewer) roles, we want more customer-focused Teams building useful products by having less artifacts, we want more Team ownership of process and more meaningful work by having less defined processes”. LeSS is a Lean Agile methodology as is expressed, for instance, with two funding principles: “System thinking” and “empirical process control”. These principles, or should I say these words, are part of the SAFe book as well, but they have a different flavor here. System thinking is more concrete and applied to the product: “See, understand, and optimize the whole system (not parts), and use systems modeling to explore system dynamics. Avoid the local sub-optimizations of focusing on the efficiency or productivity of individuals and individual teams. Customers care about the overall concept-to-cash cycle time and flow, not individual steps, and locally optimizing a part almost always sub-optimizes the whole”. Empirical process control captures the heart of agility, which is, in my opinion, to constantly adapt to the customer environment: “Continually inspect and adapt the product, processes, behaviors, organizational design, and practices to evolve in situationally-appropriate ways. Do that, rather than follow a prescribed set of so-called best practices that ignore context, create ritualistic following, impede learning and change, and squash people’s sense of engagement and ownership”. Although this is out for scope for this blog post on scaled agile, it is worth telling that “Large-Scale Scrum” is a great book about Scrum, scrum masters, scrum communities and scrum tools.

LeSS proposes a scaling methodology with three levels. The first level is clearly, as was the case with SAFe, the SCRUM agile team. There are two additional levels (LeSS and LeSS Huge): groups of up to 8 teams, and assembling a large number of such groups : “ Large-Scale Scrum has two frameworks: LeSS for 2–8 Teams, and LeSS Huge for 8+ Teams”. The two levels, with a similar cut-over, should not be a surprise since we explained earlier that the difference between managing less than 100-150 people and more seems to be deeply rooted into our sociology and anthropology. The heart of scaling comes from the product structure: one product (one product owner team) and many product development teams (up to 8 teams). This works for LeSS and changes at the “LeSS Huge” scale where the product is divided into requirement areas (“Customer requirements that are strongly related from a customer perspective are grouped in Requirement Areas”) that are managed with a LeSS structure : “Each Requirement Area works as a (smaller framework) LeSS implementation, each working in parallel in one overall Sprint. We sometimes summarize a Sprint in LeSS Huge as a stack of LeSS”. Each requirement area follows the “four to eight teams” rule : “why does a Requirement Area have a suggested upper limit of eight teams? See The Magic Number Eight. What about the lower limit of four teams? Why not one or two teams? Naturally, four isn’t a magic number, but it strikes a balance so that the product group is not composed of many tiny Requirement Areas”. To manage the set of teams in the product structure, at all scales, LeSS uses a Sprint Planning which is not very different from the SAFe approach in its form, even though some of the intents are different because of the product focus. The planning belongs to the teams :  Especially at scale with myriad different contexts and the need to improve, how Sprint Planning meetings are done in LeSS must be left up to the teams”. Sprint planning work very well when everyone can gather in the same space, but it can also be adapted to remote teams : “Multi-site—Use video, and offer items, using a virtual shared space. If questions, the simplest solution is to just talk together. If there are many teams and lots of items to discuss, try a diverging technique such as a chat tool with one window per item”.

LeSS is a product development framework. The move from project to product is a key transformation of software development methodology; it is a key foundation for Lean Software as defined by Mary Poppendieck. The authors tells how Scrum has also embraced this paradigm shift in the past years : “Luckily, this confusion is resolved. The Scrum Guide now states, “Scrum is a framework for developing and sustaining complex products” and eliminated projects. Does that matter? Hugely!”.  The focus on product is everywhere in the book, as the product is a key part of what defines the team : “Whole-product focus—One Product Backlog, one Product Owner, one shippable product, one Sprint—regardless if 3 or 33 teams. …  Your product definition determines the scope of your adoption, the content of the Product Backlog, and who makes a suitable Product Owner. Broader product definitions are advantageous, but your definition has to be practical enough to start”. The focus on product leads to long-term engagement, long-lived teams and patience. LeSS promotes technical expertise over project management skills: “LeSS requires technical excellence. Technology, team, and organizational decisions are strongly related and your coach needs to have this broad and deep perspective. Avoid people with no or limited technical expertise. These are often ex-PMI-project managers”. This is quite different from a project culture of assembling the right people for a short time and letting them go, it bears repeating and is illustrated by the LeSS requirement for the initial teams : “dedicated—each person is a member of one and only one team stable—the members of the team aren’t changed frequently long-lived—the team isn’t a temporary project team but stays together for years”. As told in the previous paragraph, the product organization scales with feature teams (and Requirement Area at the “huge” level). One product owner (either a person or a small team depending on the size) work with a set of feature teams, as peers (there is no hierarchy between the product team and the features teams). All feature teams operate in a continuous integration mode: “The continuous integration of all code across all teams creates the opportunity to cooperate by checking who else made changes in the component being worked on”.

LeSS is a customer-centric framework. The importance of customer-centricity – a key component of Agile – is much more visible in this book than the SAFe one. Many pieces of advice are given to enable customer-centricity and achieve better prioritization: “ Focus on learning the customers real problems and solving those. Identify value and waste in the eyes of the paying customers. Reduce wait time from their perspective. Increase and strengthen feedback loops with real customers. Everyone understands how their work today directly relates to and benefits paying customers”. LeSS acknowledges that customer-centricity is hard to scale (“In a small one-team product, organizing by customer value is trivial. The more teams, the more they become like cogs in the large development machine”). The feature team organization is designed as a tool to scale the focus on customers.

LeSS is a Lean Agile software development framework with clear lean roots. It makes “Lean Thinking” one of the founding principles: “Create an organizational system whose foundation is managers-as-teachers who apply and teach lean thinking, manage to improve, promote stop-and-fix, and who practice Go See. Add the two pillars of respect for people and continuous challenge-the-status-quo improvement mindset. All towards the goal of perfection”. As explained in the previous section, some of this could be found in the SAFe book (we find the same references to queues and work in process), but the importance of the gemba (people and code) is more visible. The same remark applies to the importance of continuous improvement: “A LeSS adoption ends only when you’ve achieved perfection and world domination. Without that, there are always things to improve. The job of managers is to build an environment in which teams continuously deliver and continuously improve. Preferably the teams themselves do most improvements, but managers and Scrum Masters are often involved for organizational and environmental improvements … Here’s a perfection goal: Create and deliver a product almost all the time, at almost no cost, with no defects, that delights customers, improves the environment, and makes lives better. Do endless humble and radical improvement experiments toward that goal”. The guidelines that are provided to managers are deeply influenced by lean thinking : “Create an organizational system whose foundation is managers-as-teachers who apply and teach lean thinking, manage to improve, promote stop-and-fix, and who practice Go See. Add the two pillars of respect for people and continuous challenge-the-status-quo improvement mindset”. Even with the small set of quotes that I have included here, one can see that the LeSS emphasis is not on the framework or its methods, but on the product that is being build. LeSS coaches needs to be former doers: “Prefer hands-on experience. Ensure that your trainer/coach has hands-on experience in LeSS from both inside (as a team member) and outside (as coach). Avoid training providers who don’t care about who teaches, and avoid trainers with only theoretical knowledge. …  De-emphasize certification. Most certification of people and courses is almost meaningless. It probably doesn’t hurt, but certification is not a reliable guide”.

3.2 Discipline Agile : Scaling and improving agile development processes

I will now turn to Disciplined agile, which is often considered as the most natural competitor to SAFe. Disciple Agile started in 2015 and has scaled, with successive versions, to incorporate “disciplined DevOps”, then “Disciplined IT” and later “Disciplined Agile Entrerprise”. Disciplined Agile focus on people first and acknowledges the diversity of development life cycles. In a way that is similar to SAFe, Disciplined Agile claims inspiration from many sources such as Scrum, extreme programming (XP), SAFe, Spotify, agile modeling (AM), Unified Process (UP), Kanban, outside-in software development, and agile data (AD). Following the same principle as the previous section, I have selected “An Executive’s Guide to Disciplined Agile : Winning the Race the Business Agility”, by Mark Lines and Scott Ambler, as my path to describe DAD (Disciplined Agile Delivery) shortly in this blog post. Since I only selected four themes to feed my comparative analysis with SAFe, it is clear that I will not do justice to Disciplined Agile or to Mark Lines and Scott Ambler’s book.

Disciplined Agile is a “process improvement toolkit”, that is, a framework that can be used on many software development processes: In many ways Disciplined Agile (DA) is very different from other process offerings. DA is a process improvement toolkit, not a process or methodology”. In a way that is very similar to Jurgen Appelo’s writing (cf. his great book “Management 3.0 – Leading Agile Developpers, Developing Agile Leaders”), complexity theory and system thinking play an important role in the proposed approach to scaling. Organizations are seen as complex adaptative systems, for which DAD uses to Cynefin framework to identify the “unknown unknowns”. I applaud the reference to complex system thinking, but I find the application to stay too much on the conceptual side. There are many pages about how to organize you governance, without mention of what kind of issues this governance should resolve. Similarly, the part about architecture is very generic. In a lean spirit, it would make sense to describe which problems architecture is trying to solve (such as modularity, open-ness with API, reactiveness, high availability and resilience, extensibility and unified data semantics, etc.). DAD is a transformation framework; it proposes a long journey towards continuous improvement. I quote here a long fragment from the conclusion that I like very much:
  • Solution delivery is complex. DevOps is complex. IT is complex. Your overall organization is complex. What makes it even more challenging is that your people, teams, organization, and the world around them is constantly learning and adapting.
  • No silver bullet. There are no quick fixes, no silver bullets, no one process or scaling framework to rule all regardless of the marketing rhetoric surrounding them. Every person, every team, and every organization is unique.
  • It will take time. This is a multi-year journey. And when you have achieved what you perceive to be true business agility you will need to evolve to a long-term continuous improvement approach as everything around you will continue to change.
  • It requires sustained investment. Achieving your transformation goals will take a material investment.
  • It requires courage and commitment. Every single success story, every single one, starts with the organizational decision to do the hard work to get better. And every single one eventually recognizes that improvement is a way of life, not a project.
  • Change must be pulled not pushed. You need to pull agility and discipline into your organization, you can’t push change onto people and hope it will stick.

Disciplined Agile is organized around seven principles: “Delight Customers, Be Awesome, Pragmatism, Context Counts, Choice is Good, Optimize Flow, and Enterprise Awareness”.  These principles reflect the pragmatism of the framework authors, the agile and lean heritage and a focus on system thinking. DAD embraces the preference for long-lived stable teams: “A very common trend in the agile community is the movement away from projects, and the project management mindset in general, to long-lived teams”. The fact that “Delight Customers” is the first principle is a good indication that customer-centricity received more attention than it gets with SAFe : “In 2001 the writers of the Agile Manifesto told us that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This is a good start, but disciplined agilists prefer the lean philosophy that to succeed it isn’t sufficient to simply satisfy the customer but instead we must regularly delight them if we wish to keep them as a customer.” However, the customer-centricity claim stays as a principle and does not lead to the practical focus that is found in the LeSS book.
Disciplined Agile is a Lean Agile framework with many sources of inspiration : “DAD is an agnostic hybrid approach that puts proven strategies from Scrum, Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, SAFe and several other methods into context”. Similar to SAFe, DAD also claims inspiration from Lean Startup: “The toolkit includes support for multiple delivery lifecycles, including but not limited to a basic/agile lifecycle based on Scrum, a lean lifecycle based on Kanban, two modern agile lifecycles for continuous delivery, and an exploratory lifecycle based on Lean Startup”. Notice that there is no attempt to create a hybrid monster lifecycle that includes everything (including Lean Startup in a “continuous exploration” mode), which is definitely a good thing. Lean is often quoted as a source of inspiration for principles: “The 10th principle behind the Agile Manifesto suggests that “Simplicity – the art of maximizing the amount of work not done - is essential”. Similarly, Lean advocates regard any activity that does not directly add value to the finished product as waste”. However, when it comes to practical guidelines, such as those for the “Lean Change management cycle”, any lean practitioner will cry for the absence of any mention about the “gemba” (people and code). It is hard to imagine a lean software development practice without deep diving into what people do and which issues they meet. The authors explain that enterprise culture and organization need to evolve to match Disciplined Agile ways of working – this is definitely true, as was pointed beautifully by Jurgen Appelo or by Steve Dunning in his great post “How To Make The Whole Organizations Agile”. They use the wonderful book for Frederic Laloux, “Reinventing Organizations”, as a guideline: “ There are several important observations we’d like to make about Laloux’s organizational maturity scale: Green and teal align well with agile. For your organization to support Disciplined Agile it should at least be (mostly) Green, with a participative and values-based culture, or better yet Teal with a truly adaptive and aware strategy”.
Disciplined Agile is a framework for Agile DevOps. The integration of DevOps is what makes this book stand apart from the other two : many thoughts have been given to scaling DevOps practices, and this shows in the book organization, with a collection of schemas that will be useful to agile practitioners at scale. The emphasis on “discipline” becomes the vehicle to promote the scaling of unified development methods (something that my own experience confirms: the laissez-faire spirit about what “agile really means to you” works beautifully at a team level, but does not scale) and the fierce promotion of automation (hence DevOps). The larger the organization, the larger the benefits of constant, relentless and continuous automation. I mention in the introduction that the software giants such as Google, Facebook or Netflix do not use SAFe, but they do use DevOps and very large amounts of scripting and automation. Disciplined DevOps is a valuable framework for large enterprises: “Disciplined DevOps is the streamlining of IT solution development and IT operations activities, along with supporting enterprise-IT activities such as Release Management, Support, Security and Data Management, to provide more effective outcomes to an organization”.          

4. Conclusion

Before I conclude with what I take from these different reviews, it is worth telling briefly where I come from. As you may have found if you clicked on the URL links, the divergence of opinions about scaled agile is quite wide. You cannot have an opinion that is independent from your own experience as a software practitioner. I discovered the agile manifesto in its early day because of my past as an object-oriented language designer and my interest with software development methodologies in the previous century. I moved to Scrum in 2005-2008 when I had to scale my agile practices. I then moved from Scrum to DevOps when faced with the challenge of developing software for internet gateways and set-top boxes. The practice of Scrum+DevOps has led me to look into Lean Software development around 2010 and progressively define the “Lean Software Factory” ambition, which I refined progressively when I moved to digital products development at AXA Digital Agency. I have covered this lean agile software approach many times in my blog, but I have never written about scaling before this post.  Interestingly, there are two separate topics: what does lean & agile software development mean? and how do you scale this approach? I have given the first question a lot of consideration, but not much to the second although I have been faced with scaling challenges since 2005.

The short version of my conclusion is that SAFe is an interesting toolkit for scaling but should not be used as a lean agile development methodology. If you know what you are doing, you may derive great value from SAFe rites and practices, but If you follow the guide/books too closely, your are likely to get yourself back into 20th century software development (not always a bad thing …). If I try to expand my concluding thoughts about these three books, here is what I would propose:

  • I really liked the LeSS book, and the LeSS framework, but not everything is here. The lean (kaizen) and DevOps angles are missing from my perspective. The good news is that there are no incompatibilities between LeSS and the Lean Software Factory Principles, so using LeSS as a scaling framework works for me. What makes LeSS the best book of the three is the focus on software products. As told earlier, I believe that moving from projects to products is the center of lean software transformation.
  • I liked Disciplined Agile for its DevOps integration. I also appreciate the flexibility to support multiple kinds life cycles. However, to me, this is only a companion book since it says too little about software development and stays at a “meta” descriptive level on too many topics.
  • I would recommend SAFe for the practices at scale, such as PI planning, but definitely not as a development methodology. In my opinion, SAFe and DAD suffers from the same drawback of trying to integrate too many ideas and concepts from other methodologies. DAD does it with more grace, while SAFe tries forcefully to fit all the pieces together.
  • None of these books do a compelling job to explain the value of combining lean and agile, nor how does it really work at the squad level … but this is not the topic of this post. 

I will end with a COVID-related note. There used to be a debate whether agile development required co-location. It is very clear to anyone who has experienced both, that colocation – of all team skills, but mostly of the product owner with the developers – works better. Multi-site agility requires more experience, more discipline, a strong set of common language, concepts and tools. “Remote agile”, however, has become a necessity for large-scale organizations because of geographic constraints. What we see currently is that “remote agile” may become a standard practice in a more general sense, when most software workers are required to work from home.

Sunday, March 29, 2020

Re-inventing the Product : From Industry 4.0 to Digital Experiences

1. Introduction

This blog post will talk about product development, digital manufacturing and the necessary integration between software and hardware engineering. This topic is dear to my hear because of the many years that I have spent at Bouygues Telecom developing new internet gateways and set top boxes. I will talk today about Eric Schaeffer and David Sovie’s book, “Reinventing the Product”, which is one of the important sources for my own new book, to be published in the month to come. The focus on product makes this book a great companion to the larger vision of the Industrie 4.0 transformation, as described in the Acatech document « Industrie 4.0 Maturity Index - Managing the Digital Transformation of Companies » from Günther Schuh, Reiner Anderl, Jürgen Gausemeier, Michael ten Hompel and Wolfgang Wahlster.

Re-inventing the product is clearly about smart products, but it is also about new products built in smart, connected factories. It is driven by technology and the introduction of digital tools throughout the lifecycle, from design to usage and operations. It is also a transformation of mindset, culture and organizations. As a part of the larger digital transform, re-inventing the product starts with the customers, since the digital world allows to re-invent the customer relationship from listening to supporting. Physical products still require a strong emphasis on manufacturing and product lifecycle, but software engineering, software ecosystems and the power of platforms have become equally important ingredients of the product success. Because software moves fast, because “AI is eating software”, the role of software strategy plays an ever-increasing role with product differentiation and innovation.

I had the pleasure to invite Eric Schaeffer to give a talk at the NATF. He has been a keen observer of the manufacturing industry for many years, leveraging key positions at Accenture. His previous book “Industry X.0 : Realizing Digital Value in Industrial Sectors” was already dedicated to the digital transformation of the manufacturing world. “Re-inventing the product” tells the story about what happens when companies have deployed digital tools and connected product architectures, to transform these products into platforms and start selling outcomes and experiences instead of products and services (a simplistic but useful characterization being that B2B companies are now selling outcomes and B2C companies are selling experiences). Digitization transforms the value chain and moves value to the edges: the few who are the world best-in-class with technology and the companies that control the experiences. As always, digital transformation is about speed: Eric Schaeffer quotes Haier, who is about to move from the capture of a new customer need to the delivery of a new product in 30 days. This capacity is illustrated with a wonderful story about understanding from failure analysis that customers in Asia were using their washing machine to clean sweet potatoes, which lead to the design and delivery of a new specialized – and more robust – product for this very use.

2. Reinventing the Product

This blog post is structured about “Reinventing the Product – How to transform your business and create value in the digital”.  I have sorted the key take-aways in six subsections, that reflects both the relevance with my own product experience and how well suited these principles and examples are to the challenges that I can observe today. Thus, this is as usual a subjective and personal summary of this book. “Re-inventing the product” is especially rich with figures and diagram, which I will only describe briefly and will not reproduce. Therefore, I strongly advise you to get your own copy of this book after reading this summary. The authors have collected a very, very rich set of testimonies and quotes from key industry players. I have selected a few in this blog post (which is, therefore, not as short as I would have wished) but there is no way that I could do justice to the breadth of scope of the work assembled by Eric Schaeffer and David Sovie. This does not mean that the book covers all the possible aspects of smart product design (it is much too large a scope). The authors spend a lot of energy covering the interaction between software and hardware design, but only mention briefly the “systems of systems” aspect of modern products. In many cases, the “smart behavior” of a product is not the sum of the embedded intelligent software components, but the emergent consequence of “system of smart system” design.

2.1  Products in the digital age

The authors start their analysis of smart and connected product design with a useful two-dimension framework that illustrate the rising importance of experience design and contextual intelligence of products, thanks to the combination of connection to the environment and artificial intelligence. They propose to name IQ and EQ the two axes of this analysis : “Developing smart connected products is a journey … we have boiled down this journey into two key dimensions that are show on the Product Reinvention Grid … a product’s Intelligence Quotient (IQ) – the level of smartness, connectedness and cognitive intelligence – and it’s Experience Quotient (EQ), reflecting the quality of experience it can offer”.  Smart connected products are more than the combination of embedded intelligence and better design. The book proposes ten traits to characterize them : always on, sensorized for awareness, AI-smart, hardware value amplified by software, evergreen via update, digital age UI (user interface), Hyper-personalized, A platform for multiple parties, embedded in ecosystems, digital continuity throughout lifecycle (from design to recycling/grave). Evergreen is a critical concept here, it means that the connected product keep constantly up-to-date and in synch with its support software ecosystem, which is critical for cybersecurity.

Digital continuity is a key principle of Industry 4.0: it means that the digital data that represents, and with associated with, a product will follow the product throughout the product lifecycle, from design and manufacturing to delivery and usage. This makes the digital framework a collaborative platform for all company functions to work together, using the digital representation as a shared object. This digital continuity is described by the authors as “digital thread as an eternal umbilical cord”: “The brother, if you will, of the digital twin is the digital thread. It is the umbilical cord of a smart connected product that is never cut once a device, coming from complex multi-sourced delivery, has been released into the market”. Olivier Ribet, from Dassault Systems, talks about the use of Digital Twin as a collaborative platform: “The technology used to model and simulate an experience end-to-end makes you fast as creator and manager of a product. It orchestrates every step and weeds out processes that you do not need. It also can cut out a lot of linearity. So, designers, engineers, factory workers, distributors and marketers all work with one single version of the truth”.

When they become smart and connected, products become parts of large software ecosystems, a key idea that I will explain further later on. This makes the choice of ecosystem a strategic decision for product companies: “In fact, a large part of the business leader’s management skills will be about building or joining the right ecosystems. Businesses have two basic options here: they suggest and create a partner ecosystem defining the way they work, or they join an existing ecosystem that is already well established with widely accepted software or hardware standards”. The fact that software becomes a critical part of product development means that the product development process must evolve and adapt parts of software development methodologies, such as agile development. The authors quote Steve Myers, the CEO of Mindtribe : “Today there is still a big gap between engineering and product development. Product development is not taught in engineering schools and most engineers are developing products in ways that seem rational and logical, but that don’t benefit from the many lessons learned … my dream is to share what we have learned applying agile techniques to hardware to enable every team developing a product to spend more of their time developing things that matter to people and less time on things that don’t.”         

2.2 Start with the customer

Focusing on customer experience is a critical landmark of digital transformation. As the authors point out, thinking about experience is a quantum leap beyond designing for features and services. The principle of experience design forces to become user centric and to focus on the emotional aspect of the outcome, a combination of the perceived value (valence) and the expected satisfaction (arousal) : “The perception of an experience is formed by the interaction of the human with their environments and consists of two emotional qualities, arousal and valence”. The focus on experience design is critical to leverage the capabilities of digital to deliver personalized journeys. The analysis of customer journeys deliver the context that is necessary for successful experience design: “The way products are designed, engineered, manufactured and supported when in use will change. The work of research and development teams will be less and less predictable as manufacturers will be forced to embed new and not yet fully mature technologies to keep up with fast moving consumer markets”. Tesla is quoted as an example of experience focus: “one of the most important tasks for the car-maker’s designers is the development of the user interfaces integrating the vehicle capabilities to a unique experience from the user”.

This no longer a requirement for B2C companies only, B2B companies need to embrace customer journeys and experience design: “It has long been well known that customer experience is top priority for consumer-facing businesses. Now business-facing companies have started taking this seriously too … This is clearly because they know mere product features and functions are losing traction and the capacity to create traction in the marketplace”. As the authors point out, the product companies’ missions have moved from “understand consumer usage & expected product attributes to design and live customer experience journeys”. The book uses many concepts, principles and techniques that one would find in digital service design methods such as growth hacking. For instance, tracking “aha moments”: “Leading companies identify what we refer to as the key ‘moments that matter” across the customer journey”. Experience design now applied to B2B companies: “This has created a new and special discipline – experience engineering – focused on designing, creating and managing products while they are in use – with the single goal to create an experience for maximum user satisfaction”. Experience design for B2B companies it is actually harder: “In the B2B world the experience happens at enterprise levels. There are multiple touchpoint in parallel, which makes the experience much more complex to manage”.

The “Customer Feedback Learning Loop” (CFLL) is a key concept linked with the digital transformation.  CFLL is about learning from the customers, using three paths: the explicit (conversation), implicit (analytics) and social (communities) ways. There are multiple examples of CFLL described in this book, especially at Tesla. A Tesla manager says: “Continuous monitoring of real-world performance and usage data allows product makers to see and fix design problems that testing missed”. I mentioned the Haier example earlier in the introduction. Samsung tells a similar story about continuous design of products thanks to customer feedback: “Consumer listening is an important part of innovating home appliances. We do have data analytics teams. We have teams doing core research. We have teams who improve data analytics algorithms. We employ specialists looking into the data to come up with usage insights”.

2.3 Software is eating the product

The authors have a saying, “software is eating hardware, and digital is eating software”, which says that digital has brought a new way of producing software, together with new software capabilities, which have a huge impact on smart and connected products. When they talk about “digital software skills”, they mean for instance: design thinking, scrum masters, AI experts, product managers or cloud architects. Software becomes a critical component of product design: “The product architecture is becoming software-driven, which needs to be reflected in the overall product engineering approach”. This includes software engineering “inside the box” and “outside the box” (product as a platform that is part of an ecosystem). To succeed with this new challenge, it is critical to integrate hardware and software engineering. The book provides this quote from James Heppelmann, the CEO of PTC : “The engineering teams don’t know that much about the data concerns, the security concerns, the failover concerns and the cloud analytics capability of the business. … The IT people within the organization know a lot about that, but they never have been involved in a product delivery process”. A similar thinking is found with Dassault Systems: “That is the essential logic behind these technologies. From the first day you think about a smart connected product, you don’t want to separate development and engineering from product usage and ultimately the end-to-end experience it provides”. One of the key reasons for this tight integration is the need for speed: “The most important challenge is getting enough speed. Software can so quickly be changed and pushed into the market via downloads. The same pace is hard to achieve on the hardware side”.
Since software is eating the product, information systems classical strategic issues, such as modular architecture or data exchange infrastructure, becomes part of smart product design strategies as well. A key message from the authors is to look at software companies to import their best practices: “experts from software-making companies are role models for the more traditional product-making companies”. The book makes a few references to the common bimodal architecture pattern (system of records vs system of engagement, or CORE vs FAST IT). The authors insist on the importance of common, shared data models: “The data models used by the vast majority of product companies are decades old, and fundamentally ill-equipped for smart connected product world”. Shared data models are the necessary foundations to make data circulate between different roles and functions, which is the only way to extract all the value from the data that digitalization has produced. This is still a major challenge for many companies: “Today most companies are far, far away from such a unified business model. In a recent study, over 50 per cent of product companies reported having over 20 different product systems”. This deep (and business-focused) work on common business objects models is necessary to implement a company-wide version of the digital twin: “The digital twin is a complete digital representation of a physical product, including not only 3D modelling, but also the material properties, the software and data. The digital twin becomes the single version of the truth of all product-related master data”. 

Mastering the software engineering skills and the software development process is a way to leverage digital transformation towards a massive (10x) improvement in product development efficiency. The following is a simplified version of Figure 8.3 of the book.

2.4   AI is eating software

As explained earlier, software development in the digital age is evolving rapidly. This book, like many other great books that I have reviewed in this blog, clearly sees AI as a modality of software systems. Digitization has created the foundations that makes it possible to derive smart algorithms that are curated from the data that was collected : “More broadly, what has happened is this : over decades, in both hardware products, manufacturing method, electronic, micro-electronic and digital technologies have grown in importance, laying the foundations for increasing level of software. This in turn has created a bedrock for Artificial Intelligence”.  AI gives product designers the ability to develop smart and adaptative behaviors, at different scales (from product components to systems). Although smart connected products can leverage remote intelligence from back-end support systems, not everything happens in the cloud; embedded smart software gives smart products more flexibility and resilience : “AI-driven software is to be embedded to make the hardware intelligent while operating in the field”. The same idea is developed by Rajen Seth from Google: “It is clear that there will be multiple layers where intelligence can reside. It can sit at sensor level or at a product level. It can sit of an edge device such as a server in a retail store or on a mobile base station and if course it can reside in the cloud”.
This transformation to AI-driven software is not without challenges: “Major challenges for industrial manufacturers when embedding AI and digital technology in their product and services are : Data quality, Data/cyber security, the choice of making vs. partnering”. Agile organizations, and the close collaboration of engineering, product, business and data science skills is necessary to deliver value from AI algorithms: “Self-organizing, product-focused teams sit at the core of development activities around smart connected products. Only they can muster the agility for quick regrouping that is needed when products are so closely connected to their makers”. According to the authors, most operators in smart factories welcome this transformation towards digital manufacturing and smart products : “A 2018 global study, based on a survey of 14000 workers … found that 68% of highly skilled workers and nearly half of their lower-skilled peers speaking positively about the impact intelligent technologies will have on their work”. Although the will to leverage AI to improve products see to be ubiquitous, the book points out that many companies are lagging behind their implementation strategy : “So, belief is not the issue – yet many industrial players still seem to struggle to realize their AI dreams. Although most know they need to change, only 24 per cent recognize that digital reinvention drives their top- as well as bottom-line growth … Product companies need an increased sense of urgency to build AI capabilities and embed them in their product and experience roadmap”.

2.5 The power of platforms

A key idea of the book is that platforms play the role of a fulcrum to leverage the energy and contribution of other players: “the rise of the smart connected product is part and parcel with the development of seamless ecosystems that make life less stress from for users and more customized to the needs of the individual “. The book addresses briefly the strength of platforms and the network effects:  “All successful platforms create what are called network effects where the value of the platform increases as the number of users and the usage increases”, although I would suggest that other books give a much deeper view on the topic of platforms. What matters the most is that the platform is not a prerequisite but an asset that emerges as a co-development of the product: “The emergence of the product as a flexible and living platform goes hand in hand with the emergence of the ecosystem that builds organically around it”.  Tesla gives many great examples of this platform vision: “Smart connected products all have a platform character in my view. In many cases they are not one single platform but a portfolio of platforms”. One of Tesla manager offers this great quote: “Tesla absolutely views itself as a platform company and regularly published software updates that fundamentally upgrade the car … The same Tesla car a customer acquired in 2013 is today a much better car that it was when it was bought – due to permanent software updates”. The authors underline here to move from aging products to evergreen products.

The book gives multiple examples of types of platforms: Marketplace Platforms, Social & collaboration platforms, Sharing Platforms, IoT platforms and Developer Platforms. It then illustrate the platform approach with many examples, such as Ford who is building the Transport Mobility Cloud, a platform of mobility services for smart cities, a in a joint effort with Autonomic. The book proposed many other examples, such as: GE Predix, Schneider EcoStruxture Power, MyJohn Deere, Faurecia Cockpit Intelligence Platform or  Haier Cosmoplat.  Building a platform requires careful strategic positioning to make sure that a company known who it can count as allies and which other platforms they may be competing against: “Our view is that all product-based platform companies need to have a clear friend-or-foe strategy when it comes to defining their relationship to the Internet platform titans and other rivals”. The book includes some 2017 numbers about R&D spending from the better-known company (Amazon B$ 22.6, Google B$ 16.6, Samsung B$ 14.9, Volkswagen B$ 14.8, Microsoft B$ 13.9, Huawei B$ 13.3, Intel B$ 13.1, Apple B$12.1), to illustrate the importance to think carefully about the leading ecosystems and the need to leverage the strength of the major tech companies. Patrick Koller, CEO of Faurecia explains the importance of understanding your position in the global ecosystem: “As a system integrator we understand the full value chain of the cockpit of the future. So we can identify points where it does not make sense for us to invest on our own because the entry cost are too high and because you would anyway have world leaders, with stronger market positions on hand you could partner with, who are recognized experts in these domains”.

Not all software aspects in a smart product need to be seen as a platform, especially since cyber-security is of the most important challenge of smart product design. Steve Myers has this to say when he is asked about the most urgent topics to be tackled in a smart product world: “Product security comes to my mind; it is a really big deal in any IoT landscape. It is very easy to overlook all the different ways your product needs to be secure. We, as well as our clients, have to build more skills into product security; that is why we work with outside security auditors to review potential weaknesses”.  The need for security means that some aspects of the product software need to be kept proprietary. The authors recall the following testimony from a Caterpillar engineer: “We keep the system closed. In that regard our connected machinery is not a platform concept. We are not creating a Linux solution open to third parties when we create an expert system for a building project. The main reason is operational safety on the side, but another reason is data safety, as attempts have already been made to hack into construction equipment. In that light it is better to keep our systems closed and thoroughly encrypted”.

2.6 Enterprise transformation

Reinventing the product is a transformation journey for most companies. We have already seen it implicitly throughout the previous sections, to design, to build and to operate new smart connected products that deliver the expected outcomes and experiences, companies also need to re-invent themselves: “The move to “as a service” is an enterprise-wide challenge, based on five pillars : Business and product strategy, Enterprise operating model, Product & Experience Innovation process, Shared Product platform, Agile Workforce”.  The Haier company has completely reorganized itself, with a spectacular reduction of management to move from a consolidated and uniform group to a federation of one thousand smaller product companies. These new forms of organizations need to accommodate new ways of working and to be more attractive for top talents: “Top talent is likewise vital for delivering top-class experiences. And, as we have shown, to retain the best personnel, organizations must deliver an engaging work experience”. As we showed in Section 2.2, re-inventing the product means rethinking the role of the customer. As mentioned by a Tesla manager, a smart product like the Tesla car finds itself in a permanent optimization mode : “Due to its quality as a smart and connected product, you can follow in a meticulous way how the product is being used. You see which features are more relevant to the customer and which are not. You can adjust interfaces along their actual usage patterns. You can prioritize features that are most commonly used and deprioritize that that are less used”.

Smart product companies need to organize themselves to bring together multiple forms of skill and engineering, such has hardware, software engineering, design, operations and data management. The following quote from a Tesla manager is a great blueprint for such an organization: “There is the universal recognition that all three engineering components that deliver the final product are equally important and need maximum dedication. There is the physical product itself, the combination of hardware and software that provides the operation of the vehicle. Then there is the development of the user interfaces integrating the vehicle’s capabilities to a unique user experience for the user. And then there is thirdly the back-end infrastructure that monitors, manages and enhances the fleet of products in the field, enables improvement via software updates and operates the data collection. Tesla recognizes that all three need to be executed extremely well; most companies don’t yet have that done”. The book makes a few references to exponential organizations, as described by Salim Ismael : “To bring exponential organizations to life requires diverse, complementary teams and smart systemic steering. But once this has been achieved, they can be 10 times faster, better and cost-effective compared to their rivals”. Without any surprise, the need for experimentations is a cornerstone of smart product companies, as illustrated by this quote from Jeff Bezos : “If you double the number of experiments you do per year, you are going to double your inventiveness”, which is very similar to Thomas j. Watson famous quote: “If you want to increase your success rate, double your failure rate”.

There is no standard recipe to design the perfect organization for the product company of the future: “While there are standard components and skills required for a digital innovation factory, there is no standard organizational model. Every company must create its own, based on its existing position within the product evolution space and its ambition for the future”. However, the need for intense communication, colocation of various expertise and deep collaboration is quoted by most successful product companies. Tesla advocates for the use of one-roof organizations, which reminds me of the same expression that we borrowed at Bouygues Telecom ten years ago when we launched ourselves into the challenge of designing our own set top boxes: “The need for improved coordination across all the various business functions increases dramatically in the as-as-service world”. This last quote is a pivotal sentence to understand the rise of the networked model of organizations. A Tesla manager says that “Elon Must actively encourages engineer-to-engineer communication and strongly discourages hierarchical communication”. Rich Lerz, the CEO of Nytec, has strong words about the need for colocation for designing the next generation of connected smart products: “The breadth of skills needed for these new future-generation products is very broad, and we found that we needed to house all these skills in the same physical location. All members of the team work along every step of the product lifecycle together, from ideation to prototyping to the manufacturing ramp using the same agile integration development methodology”.

3. Conclusion

I will conclude this blog post with the key take-aways that I take from reading – twice – this book. The following list is even more personal and biased with my own experience than the rest of this post.

  1. Product development in the digital world is a continuous and iterative approach, based on short customer-centric learning loops.
  2. A product digital twin is a knowledge engineering collaborative platform that unites multiples teams through out the lifecycle of the product with a shared “single point of truth”.
  3. The massive use of real-time data from multiple sources, together with a new generation of AI algorithms based on machine learning, makes it possible to dynamically optimize operations even when forecasting is not possible.
  4. Experience design plays a critical role in the success of designing and developing successful connected smart products.
  5. The ability to collect data in a transverse manner from all functions in a company, throughout the product lifecycle, stems from the existence of a unique, shared data model. Data collection is a continuous cycle, since there is more value in future data than data from the past.
  6. Software engineering and information systems make the backbone of smart connected products. Their role is to allow the enterprise to leverage the continuous flow of digital technology innovation.
  7. Success in the world of digital products and experiences is a race to continuous learning. Designing the right organization, securing the access to powerful computing resources and extensive data flows are key factors to improve the speed of learning.

Technorati Profile