Home » projects » Navigating Containers

Navigating Containers

pivotal

Summary

My role

As the Principal Product Designer I led the Balanced Team in planning and executing all user-experience methods and to collaborate with product managers and engineers on strategic and technical explorations

This six-week Discovery and Framing exercise explored how to increase Pivotal’s confidence in their ability to ship containerised software safely.

Team

  • Principal Product Designer (me)
  • Sr Product Manager (x2)
  • Sr Engineering Manager
  • Sr Software Engineer (x2)

TL;DR

Line icon of a warning triangle with exclamation point

WHY: The problem*

Development teams want to ship containers efficiently, in a standards-based way. They worry about toil.

Compliance teams want to make it easy for engineers while limiting Pivotal’s liability. They worry about risk.

Customers want to know what’s in the box, where it came from, and that it’s safe and secure. They worry about how containers will change their ecosystem, but trust Pivotal.

Line icon of a pencil on paper

HOW: The process

A formal Discovery and Framing process, conducted by a balanced team, that included stakeholder interviews, journey mapping, root cause analysis of pain points, a 3-day solution workshop, and an incremental roadmap to achieve the ideal process.

Line icon of a check mark in a circle

WHAT: The solution

A centralised build service building containers compiled by buildpacks and an internal registry that has integrated security and OSL scanning.
+
Education about containerisation, the process, and how adoption of the build service solution would make teams’ lives easier.

* Uncovered during the the Discovery phase

The mission

How do we increase Pivotal’s confidence in our ability to ship containerised software safely?

  • Understand the needs and pains across Pivotal (PKS, CF, GPDB, PFS, PAs, etc).
  • Harness subject matter expertise to come to a shared understanding about priorities in this problem space.
  • Find opportunities to promote consistency across teams and orgs that are dealing with these problems.
  • Determine whether software based solutions are needed, and how to craft.
  • Coordinate with other teams where cross-team solutions are needed.

The process

About “Discovery and Framing”

Discovery and Framing is an Agile practice to explore the problem and solution space. In each step there is a generative “go wide” phase and an evaluative “focus” phase.

Typical activities in Discovery

  • User interviews
  • Journey mapping
  • Creating personas

Typical activities in Framing

  • Sketch solutions
  • Prototype at low-to-medium fidelity
  • Conduct user feedback sessions
  • Define the MVP
  • Write user stories

My colleagues Roxanne Mustafa and Daphne Lin did an excellent overview of the D&F process for a Voices of Product Meetup.

Learn more about how to use the methods of Discovery and Framing at Pivotal / Tanzu Labs

About “Balanced Teams”

Balanced teams include representatives from multiple disciplines, each of whom contributes expertise and perspective that, together, provide a more comprehensive view of a problem or solution. Thy typical balanced team includes

Product Management

  • advocate for the business
  • view through the lens of “business value.” 
  • ask the question “what is viable?”

Engineering

  • advocate for the solution
  • view through the lens of “implementation pragmatism.” 
  • ask the question “what is feasible?”

Design

  • advocate for the user
  • view through the lens of “user value.”
  • They ask the question “what is desirable?”

Learn more about how we used Balanced Teams at Pivotal / Tanzu Labs

The history of balanced teams

“Balanced Team” presentation by Janice Fraser 

Artefacts

These artefacts describe the process through each of the phases.

Discovery

Stakeholder map

We identified a wide range of stakeholders across the organisation.

Interviews and initial synthesis

We conducted 20 interviews and used those as the core inputs for our discovery.

Proto-profiles

Who is going to be impacted by our solutions, and what do they care about? 

  • Development teams want to ship containers efficiently, in a standards-based way. They worry about toil.
  • Compliance teams want to make it easy for engineers while limiting our liability. They worry about risk.
  • Customers want to know what’s in the box, where it came from, and that it’s safe and secure. They worry about how containers will change their ecosystem, but trust Pivotal.

Journey map and flow diagram

We constructed a journey map of the current world that shows how containers currently flow through our system. This flow diagram describes what entities (e.g., source files, containers, packages) different proto-profiles are working with at each phase of the flow.

Container journey and pain points

Using the journey map of the current world, we layered in pain points across the journey (including gaps).

Hopes & Fears

We did an exercise with the Shipping Containers Working Group around their Hopes and Fears for NavCon. We then brainstormed behaviours to maximise that Hopes would happen and mitigate that Fears would.

Causal diagram of pains

Some pains influence other pains.

  • We drew an arrow to show which pain may affect another pain (possibly indirectly)…
  • And rearranged from root causes at top to symptoms at the bottom.
  • Closely related or coupled pains became visible.

Relationships between phases

From the causal diagram we can see closely connected pains, including competing tensions. During the workshop we did a solution exercise focusing on optimising each of these relationships.  

Urgency vs impact of pain points

As a team, we evaluated the urgency and impact of the summary pain points from the container journey.

Synthesis and insights

Empathy gap

There is an empathy gap between Engineers & OSL/Legal

Education needed

Education and training is a huge gap

Increased toil

Containers increase toil on everyone

Unsophisticated customers

Customers aren’t as sophisticated yet… but they have a point of view

Philosophical tensions

We uncovered some philosophical tensions.

Security

We heard some pain points re. vulnerability scanning.

Solutions workshop

Journey brainstorm

Considering the pain points and phase relationships, we brainstormed solutions across all 6 phases of the journey.

Solution set

Looking across phases, we identified a set of solutions from our big brainstorm. We then dot-voted on them.

Dependency diagram

We drew a diagram that shows the sequencing of efforts required to implement some of our solution ideas.

Impact vs technical complexity

Using a time horizon of 6-9 months for impact, we placed solutions in a way that represented our best guess at their relative impact vs implementation complexity.

Post-workshop analyses

Solutions vs pain points

We mapped each of the solutions generated in the workshop against the pain points they are likely to address. We used this analysis to identify gaps and better understand the potential impact of each solution.

Solution sequence diagram

We organised solutions generated at the workshop into independent tracks of work with solutions sequenced within each track, then used it to inform experiments.

Ideal journey

As part of ideating on the solution that became “Guardrails,” we eventstormed an ideal journey.

Incremental solution path

We broke down the “Guardrails” solution into chunks of functionality that could be implemented incrementally towards a product vision.

Outcomes

Solution

Conceptual roadmap

🤕 Band-aid: Education and documentation, including best practices around composing and packaging containers.

🛹 Skateboard: a pilot internal registry that enables reuse of container images.

🚲 Bicycle: a registry and a re-usable set of tasks that standardise building containers.

🏍️ Motorbike: internal buildservice using the registry so that we are efficiently building consistent images.

🚗 Midsize sedan: a registry that facilitates streamlined OSL and Security scanning while building secure, compliant container images.

Provisional user journey

A provisional journey for the medium-term solution

Tracks of work

Three interdependent tracks of work that provide value independently of the others and can be worked on in parallel:

  • Education: The what, why, and how of building secure and compliant containers.
  • Build service: A platform that runs the buildpack lifecycle. It generates container images from source code using cloud native buildpacks to be run on a container runtime.
  • Internal registry: An OCI image registry for Pivotal internal use.

Next 90 days

  • Continue experiments to validate hypotheses around proposed medium-term solutions (e.g., Build Service, internal registry).
  • Align with the Buildpack and Build Service teams to identify internal requirements.
  • Integrate a proof of concept OSL scanner and security scanner with the registry.
  • Work with a team to build their containers using the build service and concourse resources and an internal registry.
  • Build out a roadmap for the build service solution in partnership with the Security BLT, OSL, Legal, Build Service, and Buildpack teams
  • Keep in touch with the kubISM and Platform Engineering groups to understand where we’re solving similar problems.