SPL and Agile

Blog by Andy Hayward, Senior Product Marketing Specialist, PTC

Today’s product engineering organizations are under unprecedented pressure to produce high quality software in as short a time and as low cost as possible. Most are finding the traditional development methods to be insufficient and ineffective in this high paced environment, and are looking at alternatives, most often in the form of either Agile or Software Product Lines (SPL).

Agile, defined in the infamous manifesto in 2001, focuses on delivering working software quickly and regularly using time-boxes and an iterative approach. It advocates a minimalist or “Just Enough” approach to documentation, recommending that organizations focus instead on keeping teams small and co-located so as to emphasize more effective face-to-face communication. Agile also pointed out that the traditional method’s focus on putting together an architecture and design at the outset of a project demands an often unrealistic understanding of future needs and limits teams’ abilities to respond to change. Agile proponents instead recommend a “Just In Time” approach to design, where most design decisions are postponed until they are needed in order to minimize the risk of making key architectural decisions months before implementation, when details on the project are still scant and when risk of change is high.

SPL is the practice of creating multiple variations, or variants, of a product from a common set of assets. SPL is usually associated with large engineering organizations, such as automobile, cell phone and even aircraft manufacturing. While Agile’s guiding principal is to have small teams working closely together, these development efforts require the coordination of tens or hundreds of people or organizations all over the world, and can involve the development of systems that contain 10s of millions of lines of code. Also unlike Agile, SPL emphasizes the planning and development of the software architecture that the product lines will be based on. Whether it is done before the first product is released or when defining an architecture from an existing product, this demands making key design decisions sometimes years in advance of the product being released.

At first glance the guiding philosophies of Agile development and SPL seem to be incompatible. Agility’s defining characteristic is minimizing planning and emphasizing the ability to react to change. SPL is plan-driven, and “inherently means you set out to understand future needs” (Software Engineering Institute), and requires extensive documentation in order to coordinate the large number of people involved. And yet, some of our largest product engineering customers have successfully applied both philosophies to their development process.

Over the next few installments I will investigate how some of our leading edge product engineering customers have overcome these differences to successfully leverage the benefits of both methodologies. If you have experience, thoughts, opinions, questions or suggestions, please feel free to post a comment or tweet me at @andyptc.