The Best of Both Worlds Agile Development Meets Product Line Engineering at Lockheed Martin
Agile development has long been touted as way to optimize software development team efficiency and improve project success. Product line engineering (PLE) brings large scale improvements in cost, time to market, product quality, and more. Can these two paradigms work in concert with each other? This paper details the experience of Lockheed Martin as it introduced large scale agile development practices on one of its largest and most successful product line engineering efforts. Introduction Agile software development refers to a group of software development methods in which requirements and solutions evolve through collaboration between self organizing, cross functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change [8] Its adherents tout higher quality systems, delivered faster, which much better match customer needs and expectations. Systems and software product line engineering, or "product line engineering (PLE)" for short, is a way to engineer a portfolio of related products in an efficient manner, taking full advantage of the products' similarities while respecting and managing their differences. Considering a portfolio as a single entity to be managed, as opposed to a multitude of separate products to be managed, brings enormous efficiencies in production and maintenance; these efficiencies are delivering order of magnitude improvements in engineering cost, time to market, staff productivity, product line scalability, and quality [9] What happens when an organization tries to apply both of these groundbreaking, organization changing methodologies at the same time? Can they work together at all? Is PLE, which relies on cross product planning and well entrenched coordination, compatible with Agile, the very essence of which is exceedingly short feedback loops and the ability to pivot as needs change? This paper conveys the experience of Lockheed Martin, the world's largest defense contractor, as it is applying PLE and Agile together on one of its largest and most important projects. Not only is the project highly visible with demanding requirements, it is also very large, comprising some 10 million lines of code. This setting would challenge either methodology by itself; putting both of them together is yielding many lessons. At the end of the day, however, the answer to whether the two methodologies can work in harmony is resoundingly affirmative. This paper will show how Lockheed Martin is using the two methodologies to support each other, and the lessons it is learning as it does so. What Is Product Line Engineering? Product line engineering (PLE) is a way to engineer a portfolio of related products in an efficient manner, taking full advantage of the products' similarities while respecting and managing their differences. By "engineer," we mean all of the activities involved in planning, producing, delivering, deploying, sustaining, and retiring products. Born in the 1980s in the software field, but now having grown well beyond those early roots, PLE offers large savings observed from engineering the whole family rather than separately engineering each member. Numerous case studies [1][4][5][10][14][15] show that exploiting the commonality throughout the products' total life cycles can return substantial improvements in time to market, cost, portfolio scalability, engineer productivity, and product quality [13] no other engineering paradigm shift has, to our knowledge, brought about results that rival these. PLE as a Factory An analogy with factory based manufacturing serves to illuminate the important concepts. Manufacturers have long used engineering techniques to create a product line of similar products using a common factory that assembles and configures parts to produce the varying products in the product line. For example, automotive manufacturers can create thousands of unique variations of one car model using a single pool of parts carefully designed to be configurable and factories specifically designed to configure and assemble those parts. In PLE, the configurator is the factory's automation component; the "parts" are the assets in the factory's supply chain. A statement of the properties desired in the end product tells the configurator how to configure the assets. Figure 1 illustrates. This factory's supply chain is at the left, in the form of shared assets that are configurable because they include variation points that are expressed in terms of the features [8] available in each of the products. A product specification at the top tells the configurator how to configure the assets coming in from the left. The resulting products, assembled from the configured assets, emerge on the right. This enables the rapid production of any variant of any of the assets for any of the products in the portfolio. Once this production line capability is established, products are instantiated derived from the shared assets rather than manually created. The products in the portfolio are described by the properties they have in common with each other and the variations that set them apart. The products can comprise any combination of software, systems in which software runs, or non software systems that have software representable artifacts (such as requirements, engineering models, or development plans) associated with the engineering process that produces them. In this context "product" means not only the primary entity being built and delivered, but also all of the artifacts that are produced along with it. Some of these support the engineering process (such as requirements, project plans, design modes, and test cases) while others are delivered alongside the thing being built (such as user manuals, shipping labels, and parts lists) These artifacts are the product line's assets. Assets can be whatever artifacts are representable digitally and either constitute part of a product or support the engineering process to create a product. Four kinds of shared assets are shown in Figure 1, but those are just examples. Shared assets can include, but are not limited to, requirements, design specifications, design models, source code, build files, test plans and test cases, user documentation, repair manuals and installation guides, project budgets, schedules, and work plans, product calibration and configuration files, data models, parts lists, and more. Assets in PLE are engineered to be shared across the product line. Figure 1: PLE as a factory. PLE Contrasted With Product Centric Development PLE stands in contrast to traditional product centric development, in which each individual product is developed and evolved independently from other products, or (at best) starts out as a cloned copy of a similar product that is then changed to suit the new product's specific needs. Product centric development takes very little advantage of the commonalities among products in a portfolio after the initial clone operation. In particular, it derives very little benefit from commonality in a product's sustainment or maintenance phase, where data shows most products consume up to 90% of their project resources. Figure 2 shows a production shop in which N products are developed and maintained. In this stylized view, each product comprises requirements, design models, source code, and test cases. Each engineer in this shop works primarily on a single product. When a new product is launched, its project copies the most similar assets it can find, and starts adapting them to meet the new product's needs. To see how this form of reuse can lead to intractable complexity, assume that a defect is found in Product B, and that the defect is traced to an ambiguous or incorrect requirement in Product B's requirements. The Product B team fixes the error, re designs as necessary, then fixes the code and test cases before re deploying Product B. Product B is now healthy again. But suppose that the defect in Product B's requirements was "inherited" when the Product B team copied the requirements from Product A. Suppose further that the source code for Product N was copied from Product B's (defective) source code, and the test cases for Product N were similarly "borrowed" from Product A's (inadequate) test cases. Figure 2: Product centric development yields O(N) complexity To really root out the defect from the entire portfolio, each of the N product teams should really confer with each of the other N 1 product teams. These communication paths are shown in red in Figure 2. This communication obligation imposes an overhead that grows as the square of the number of products. This complexity will quickly overwhelm any engineering staff; in order to get their products out the door on time and on budget, each product team will focus more on their product silo and less on taking advantage of the commonalities and interdependencies among the other products. The result is divergent product silos, low degrees of sharing, and high duplication of effort across the product silos to fix the same defect multiple times in multiple products, or to independently implement the same enhancements in different ways in different products. Figure 1 alluded to PLE as a factory, and that analogy can be brought to bear to remedy the O(N) problem of portfolio management. In a manufacturing factory, a defective product would not be fixed by one off repairs to the product itself. Rather, the factory, its supply chain, and the manufacturing process itself would be scoured to find the source of the defect. So it is with PLE. Rather than fix a defective product, PLE engineers fix the shared asset(s) that need to be modified (perhaps by adding a new variation point) in order to produce the product correctly. Then, the configurator is used to re generate the product, as well as any other product affected by the changes in the shared assets. Since re generatio