Complete the Development Runway

Credit*

You create a skeleton aka runway because you should not try to create a complete product delivery system all at once: you should plan to refine all this plumbing over time. But one thing you should do is go end-to-end from the beginning. That is, create the kernel of each step of all the things needed to realize your vision: create a core design team (if applicable); create the core of an engineering team (if applicable); task the engineers with setting up their “environments”, tooling, and test suites (as applicable); create a core marketing team (if applicable); and arrange for the beginnings of product support (if applicable).

Put every piece in place, but just the beginnings of each piece. In other words, create the “skeleton” of the entire value creation and delivery flow. That enables your teams to gradually fill out those parts of the value flow, taking an approach of continuous improvement.

Design the Product Design Process

It is essential to include product design as a central activity from the outset. This can begin as a kind of placeholder, but over time the design activity needs to be built out. It is rare that there is one individual who is so in touch with users that they can just state what the product should do. In most cases, product concepts need to be tried before too much effort is invested. This is the Lean Experiment concept.

In a talk at the 2020 UXDX conference, John Schrag, the director of experience design at Autodesk, laments that an unintended consequence of the Agile movement was to disconnect product design from product development. Today an attempted remedy for this is often to insert user experience (UX) people into Agile teams. That is only a partial remedy though, because it does not address the need for an ongoing generative process with respect to product design, spanning all of a product’s teams.

In the article Designing the Design Process we provide some guidance for adding product design to initiatives.

Define an Integration and Testing Strategy

Integration refers to bringing together the pieces of a system, both at a design level and at an implementation level. This should be done on a frequent basis. An integration strategy is a set of choices about how to approach. It should begin simple and become more refined over time. An integration strategy is fundamentally a dependency management strategy, because an integration strategy is a decision about how to reconcile the dependencies between things.

Testing is inseparable from integration, because system testing requires integration. Therefore, the integration and testing strategies are merely different aspects of a single strategy for frequently validating that all the components of something work together.

See Dependency Management, and also the four articles that begin with this one, Real Agile Testing, In Large Organizations – Part 1 .

Define a Data Strategy

It is very important to define a data strategy from early on. If you do not, you can easily “paint yourself into a corner”, in the sense that you will have data that cannot be used, tests that cannot be trusted, and will have set behavioral norms that are difficult to correct.

As with any strategy, a data strategy should begin lightweight, as a set of approaches to use, and evolve over time in a thoughtful way.

See Defining a Defining a Data Strategy.

Define Development Metrics

Define some leading and trailing metrics that you feel will (1) drive behavior and (2) reveal progress, respectively. Establish those metrics on an easy-to-find dashboard.

See Defining Development Metrics.

Establish a Dashboard Culture

Establish a standards location for dashboards. Generate discussion around the criteria for what kinds of activity should have a dashboard.

See Creating a Dashboard Culture.

Establish the Paradigm of Event-Based Collaboration

Generate discussion around the criteria for what kinds of communication should occur in written form (such as message platforms, documents, and email), and what kinds of communication justify a meeting.

See Event-Based Leadership.

* Photo is from the blog of Marvin Denmark: https://wildcatman.wordpress.com/category/suspension-bridge/. Image by Henrik Kniberg