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.
Figure 1. Cross-Solution Planning Taxonomy
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.
Figure 2. Artifacts used for solution and product planning
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’.
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.