Last year, AmyS blogged on the progress defining our internal Continuous Delivery process. To follow up on those concepts, I would like to share some of our latest experiences from the Product Line Engineering (PLE) delivery team in adopting these processes and the way we started applying IBM design thinking to our solution development supporting businesses that include embedded software development.

Design is good business!

IBM recognizes that good design is good business. And there is a long tradition to back up that statement. Lately, IBM Design Thinking has gathered design practices to identify and ideate on the aspects that makes a solution desirable to its users; the Who, the What and the Wow! These aspects become the mission for release(s) and the business requirements for the solution. Amy identifies these as the business planning artifacts at the top of the planning taxonomy. We call these Release Hills.

The use of Hills to capture the WOW’s

For delivery of improved capabilities for product line engineering, the team has focused on three Hills to drive innovation, to drive our work, and to organize and track our activities. Our first Hill ‘Work in configurations with artifacts and links’ focuses on core capabilities introduced in our solution on configuration management, with streams and baselines of engineering artifacts. The second Hill ‘Create and use product definitions’ extends the value of the first Hill with more targeted support for advanced product line engineering practices and use-cases. Our third Hill ‘Track and report on configurations of engineering artifacts’ is orthogonal to the first two and adds complementary capabilities to the solution with dashboards, queries and reports. To refine our mission to a focused and executable level we have also defined sub-hills that narrow-in scope and prioritize sets of features.

Organizing our solution artifacts by Hills

At the next level in the planning taxonomy we use the Hills as our primary organizational item for solution artifacts. At this level we use Rational Team Concert work items to capture our Epics and Features. And we use Categories to represent the Hills. This makes the process of classifying new capabilities simple by just using the Filed Against field when assigning Epics and Features to a Hill. We refine Hills into Epics to represent our sub hills. Features then become children under their parent Epics to further refine the capabilities into work that we can execute on within a single release cycle.

Our solution features are to be delivered by the impacted products, e.g. Rational Team Concert, Rational Quality Manager, Rational Doors Next Generation and Rhapsody Design Manager product development teams. Any enhancements to products are planned using Plan Items and Stories in each impacted product backlog respectively. To manage relations between solution features and application plan items we use cross-project Tracks links. This linking provides transparency to commitment and plan of delivery. It also provides transparency to progress on work and in-context collaboration.

Using scenarios and playbacks to explore and validating our design

Scenarios are a key concept in our design thinking. They ensure that we can deliver our features in a coherent, usable and desirable solution. Scenarios also support our activities on innovation, exploration and validation. Much like a movie script we let our personas act out in the scenes using scripted steps. Hence, each scenario Act is decomposed into Scenes where the scenario personas act through Steps interacting with the tools and collaborating in context of a configuration of engineering artifacts.  As indicated in Figure 2 above, our scenarios are linked to the features used in each scene using an Implements relation. Using these links in figure 2 we can report on important delivery metrics. As a few examples, lately we have been using the Rational Engineering Lifecycle Manager (RELM) product and the Lifecycle Query Engine (LQE) to index our solution artifacts and provide traceability reports that outline the dependencies and coverage of Plan Items to Features, Epics, Scenes and Hills. This creates a great overview of the design artifacts. On our delivery dashboard we use the artifacts to present key design metrics like; ‘Scenarios with no features’, ‘Features with no scenarios’, ‘Features with no Tracks’.

For our PLE scenario we use a storyline on ‘Fixing a defect in a product variant’. This scenario is exploring in the first act how the scenario personas will initially ‘reproduce the defect’ using the engineering artifacts in the released baseline configuration. In the second act the team will ‘create a new delivery configuration’ with updated engineering artifacts resolving the defect. In the third act the team explores the opportunities for reusing the fix when ‘delivering and baselining a fix to the product line’. Our personas acting in the scenario are the Product Line Manager, the Project manager responsible for product line delivery, the Development lead responsible for platform component delivery, the Configuration lead, a Systems engineer, a Embedded SW Developer and a Tester. To show progress on the solution delivery we conduct frequent playbacks of the scenarios using initially low fidelity mockups and prototypes. Over time we converge to more stabile high fidelity wireframes and working code by milestone.

Exploring design options and usability

Lately we have been using playbacks to explore design options and usability aspects on how the scenario personas are interacting with the configuration management application when creating streams and baselines of configurations. Using a scenario and playback design approach helps us in clarifying implications to usability and consistency across the solution.