The second day of the annual Software Product Lines Conference saw me attending a session on Agile Product Line Engineering. The session, advertised as a panel, was led by industry veteran John MacGregor.

In an innovation for SPLC the audience were divided into small discussion groups and tasked with answering three questions:

1. What are the advantages, if any, of using agile techniques in a PL organisation?
2. Where in the operation of an SPL is the agile approach possible/appropriate/advantageous?
3. Are changes to the ‘usual’ product line approach necessary to take advantage of agile techniques? If so, what
   • Research issues should be investigated?
   • Practices should be adopted?

John volunteered me and a few other SPLC regulars to lead the discussion in our respective groups so I rounded up 8 willing participants and we kicked off by introducing ourselves and describing our product line and agile experiences.

In a nice twist of fate we had a couple of researchers who are already looking at combining agile and software product line methods, one representative from a company trying to implement Scrum in a product line setting and a mix of sceptics and optimists when it comes to combining the best of the two approaches.

John will write up the session outputs at a later date but here are a few notes our group made:

• Some people have perceived a conflict between agile methods (e.g. Scrum) and Software Product Lines but the group’s experience was that there wasn’t necessarily a conflict.
• The communities around either approach are probably not known to each other. If they are aware of each other then their perceptions of each other are probably not accurate (e.g. thinking of agile as ‘hacking’ as opposed to a highly-disciplined but lightweight approach)
• Do SPLs need more documentation than agile can support? Some specialised product lines in regulated industries may do.
• Would an agilist resist core asset development (development of a highly-reusable software asset base)? Do such developments violate the principles of avoiding Big Design Up-Front or You Ain’t Gonna Need It? Maybe there’s a role for Agile development after the core asset base has been developed.
• On the plus side, agile’s focus on Test-Driven approaches would sit well in an SPL.
• Agile’s focus on the customer and a strong emphasis on prioritising requirements would also fit well with an SPL. The question would be how to collate and prioritise requirements from a massive customer base across multiple locations.
• Is there a problem with hardware co-development. (Although one participant’s organisation had hardware development done in an agile way through rapid prototyping).
• Size of project may be an issue? Can agile be scaled to an SPL effort? Lots of people in the agile community looking at scaling up agile. Anyone looking at scaling down SPL?

In response to the set questions our thoughts were:

1. What are the advantages, if any, of using agile techniques in a PL organisation?
   • Lightweight methods (SMEs) can adopt SPL more quickly?
   • Strong focus on testing (TDD, CI)
   • Strong focus on prioritising requirements.
   • Refactoring
   • More customer involvement?
     • Distinction between a customer for the product and a customer for the product line.
     • Deliver early and deliver often is typical in SPL already.
2. Where in the operation of an SPL is the agile approach possible/appropriate/advantageous?
   • Define an architecture/ platform first and then become agile when developing products? Can a PL architecture just emerge? But you need stability of architecture in a PL.
3. Are changes to the ‘usual’ product line approach necessary to take advantage of agile techniques? If so, what?
   • Research issues?
   • Practices?
     • Have a strong separation of concerns to enable smaller agile teams? Must still have a hierarchy e.g. Scrum of Scrums.
     • Have agility but keep stable component owners? (As in the InnerSource model discussed in the keynote)
     • If you know you’re going to need something then do develop it for reuse otherwise just do opportunistic reuse as in agile.

So, there you have it. Look out for more on combining Agile Methods with Software Product Lines in the future…