RFC: Are we nimble yet?

Nimble adj. light and quick in motion.

Introduction

“The link is simple. If a firm measures a, b, and c, but not x, y, and z, then managers begin to pay more attention to a, b, and c. Soon those managers who do well on a, b, and c are promoted or are given more responsibilities. Increased pay and bonuses follow. Recognizing these rewards, managers start asking their employees to make decisions and take actions that improve the metrics. (Often, they don’t even need to ask!) Soon the entire organization is focused on ways to improve the metrics. The firm gains core strengths in producing a, b, and c. The firm becomes what it measures.”

Metrics: You Are What You Measure! John R. Hauser and Gerald M. Katz, 1998¹

What makes us Nimble?

We are nimble when we have the ability to put features into the hands of customers within a reasonable time (lead time), this is measured in metrics that underpin the Technology Department’s ability to deliver:

For 2022/2023 this metric is:

• Time taken to provision a simple service.

Metrics will be adjusted as Ebury 2.0 matures, as decided by a cross team group representing each constituent part of what is to be measured.

How do we measure this?

In whichever way involves the least amount of time and effort.

Simple service metric

Simple service metric can be broken into 3 phases:

1. Initialisation
2. Staging release
3. Production release

What does "simple service" Mean?

• Has a persistence layer
• publishes and consumes Kafka topics
• exposes a Channel API
• manages authorization checks
• basic platform requirements
• Vault secrets
• Elasticsearch logging
• Prometheus metrics †
• Prometheus alerts
• Sentry error reporting
• Tilt
• CI/CD

† These are not meant to be the final application metrics, a single metric is all that's required here, e.g. "Up". We want to measure the mechanics of setting up not the development of client specific metrics.

Directors/Team Leads should identify projects with components that match the base level requirements of this metric.

Team leads should define epics covering this minimal set of requirements as it relates to the component to be built. For example, a "Simple Service" Engineering Plan might have the following epics:

• Project initialisation (git repo, GitHub boilerplate, Jenkins config, Sentry DSN, etc) (label: nimble-service-init)
• Basic "Hello World" API server (/ping) & consumer (connect to Kafka, and "Hello World" topic)
• Basic service deployment to Staging Environment (label: nimble-service-staging)
• API design
• Schema design
• Authorization design
• ... etc.
• Service Deployment to Production Environment (label: nimble-service-production)

The 3 phases are measured by use of the labels nimble-service-init, nimble-service-staging and nimble-service-production. A ProcessLabs insight can then chart the duration of all epics with these labels.

NB This is not designed to measure the time spent on solving the problems unique to the service under measurement, but only the time spent on deploying the service. It is a measure of the platform, not the team.