Prioritizing finding a solution for it will focus work on a solution to reduce "debt at risk" and increase our capacity to deliver value to our customers.

2022-04-30

Introduction

Building on the foundation in this article, we now turn our attention to reducing debt at risk, or, as the title suggests, accelerating value realization. This article proposes a path to assure that a production pipeline serves the business as much as it does the tech org, such that decisions can be made based on observability and accelerate the VSM.

Schema

Observation and premise

Please note the number of feedback cycles emanating from the “Observation” node which is proof that it’s in our critical path. Prioritizing finding a solution for it will focus work on a solution to reduce “debt at risk” and increase our capacity to deliver value to our customers.

The components of the schema

Hypothesis

This is the origin and motivation for exposing the current implementation to change. Whether this is for technical or “business” reasons, we should keep in mind that it’s merely a hypothesis in most cases. We expect that introducing change to a running system, at any scale, will destabilize it. This may manifest itself at the technical level, or the effect it will have on our customers.

The above-mentioned flow and schema are tools that control and measure those effects. The goal is primarily to assure that the change does not cause a regression in the parts that were not planned to change, as well as to assure that we can measure the effect of the change as soon as possible and adjust as needed.

Suggested activities:

• Describe the change using the Elvator pitch

Behaviour-driven-development is a methodology that allows us to describe the intended behaviour in simple spoken language that focuses on the customer of the system. It allows product owners to describe the changes in non-technical language, yet be implemented using a testing framework and is a methodology that supports Feature and Story writing sessions

Feature Writing

This is the main vehicle by which we describe the change with wish to introduce, aided by BDD. Features should describe a persona’s experience without technical concerns. It is important to remember that features describe “the what” without concern with “the how”. Complex features (primarily those that concern multiple personas) should be divided into other distinct features to aid prioritization.

Prioritization

From the business perspective, prioritization is the most important factor when planning to introduce change to a system. It guides the feature that will be introduced initially and will focus the organization on its implementation and completion, subject to feedback from the customers.

Ideally, the organization would implement a single feature at a time, reducing concurrent work in progress to a minimum, hence reducing debt as risk.

Prioritization is aided by a set of Furuturespective sessions that attempt to predict issues as well as their resolution with the implementation. This greatly helps planning for the “knowns”.

Story Writing

Stories break down feature requirements to smaller implementation units for the delivery teams to work on. My rule of thumb is that story complexity should be proportionally inverse to their risk to business. In other words, high-risk items should be described by multiple low-complexity stories. This allows the product owner to monitor the implementation at a granular level, giving more flexibility for mitigation.

BDD scenarios greatly help define story acceptance criteria. An introduction to BDD can be found in this article

Coding

Try to avoid it.

• Supported by TDD
  There is no better path to evolutionary architecture than to use TDD to code one’s self out of a problem.

• Supported by Feature Flags
  Use of feature flags early in the process will allow main to be deployment ready at all times, and will allow you to configure runtime parameters while in prod without redeployment code.

At the base of the pyramid

• Code - everything is mocked, we’re testing the protocol, not functionality
• Contract Tests - Consumer sets the expectation, Provider meets them with a mock that returns models shared with its implementation.
• Infrastructure - Assure that we’re provisioning what we think we provisioned

Functional Tests

• Features - There’s a Customer, and a feature does not exist if they don’t articulate a need for one. BDD will guide us best.
• Security Tests - Shift left, as pipeline tasks
• Compliance Tests - Shift left, compliance as code.
• Performance Tests - Nightly, with analysis debriefs the following morning.
• Deployment Tests - Nightly, with smoke tests, , with analysis debriefs the following morning.

Game-Day Simulation

Which is the logical step after deployment tests. Here, we simulate the features, and, using observability tools, apply them as a simulation in prod. Basically, here we exercise our capabilities against the ring

Production Deployment

• Canary Deployment - Roll forward if the Canary is unsuccessful
• B/G Deployment - Using feature flags

Observation

• A/B Testing