For my first installment in the SPL and Agile blog series, I decided to start with an organization that has been doing SPL for some time and just started down the Agile road. The organization will have to remain nameless, but I can say that it is a technology company with hundreds of products and employees in the tens of thousands spread all over the world.
Like many organizations in its industry, rapid growth through acquisitions over the last 10 years had created a collection of product development groups in silos, each with their own methodology and supporting tools. Getting portfolio level information in this environment was time consuming and sometimes even seemingly simple tasks, like tracking down which features had been implemented in which products, were difficult. Their ability to innovate and respond to change and opportunities in the market was becoming bogged down with inefficiencies and redundancies. Product development wasn’t able to respond to customer and internal feature requests quickly or efficiently, and the organization’s visibility into product releases was very limited.
One major source of pain was that each product and product line had their own process for receiving requirement and feature requests. This resulted in inconsistent features across product lines and wasteful ‘re-inventing the wheel’ implementations of similar features. It also made tracking which features were available in which products extremely time consuming, even after products had gone to market. To address this, the organization created a single ‘backlog’ system to collect and manage requirements and feature requests, and they established a release planning process where the requests were reviewed, estimated, prioritized and assigned to product backlogs.
Each development group replaced their systems with a well-known Agile development management system and trained their teams in agile development methods. The product backlogs are managed in the Agile point solution using fairly standard Scrum techniques with Sprints, Sprint Planning sessions.
Adopting this Agile-like process improved requirement traceability and the organization is already seeing results in product quality. Requirements change management is much more effective, and when requirements change and new requirements and requests are received, the information can be immediately communicated to the teams through their backlogs. It is much easier to track the progress of features though out the development process.
However, using independent Agile point solutions revealed some issues they were having applying Software Product Lines. While agile improved communication within teams, having multiple independent product backlogs didn’t improve the collaboration required between products and product lines, and the faster development iterations made this more visible. Maintaining a common architecture of features across lines was a cumbersome process because there was no easy means for teams to provide feedback on the architecture. Variants and products with similar requirements sometimes re-invented the wheel, creating new assets for features that had already been developed and tested by another team. When defects were revealed, it was difficult to determine whether this defect also applied to other variants. Issues found in one variant were not always communicated to other variants.
To be clear, the company knew that moving to Agile wouldn’t solve some of their challenges in adopting SPL, and planned a second step. The separate Agile systems used to manage development activities and assets will be replaced with a single repository. Development teams will work from the same assets and be able to use configuration management concepts, such as branching and version control, to the requirements, user stories, test plans and code. For example, a test plan may be created for one product line, and then other lines will either share that test plan or create a branch if they need to diverge from the core architecture. Through automated traceability and trace propagation functionality, the teams will be able to view and leverage work being done in parallel on other variants while automatically communicating their own changes.
So, through the use of Agile and configuration management concepts, this company is managing to overcome some of the hurdles product development organizations face when combining Agile and SPL, and therefore leverage the benefits of both approaches. I’ll be looking at another very different case in the next installment. I’d like to hear your experiences, so please feel free to comment below.