Zero Inventory Driven Development
Tags: trunkbasedevelopment
Published: 2017-11-12 06:57:27

---
title: Zero Inventory Driven Development
published: true
description: What prevents your team from doing continuously delivered trunk based development?
tags: trunk base development
---

**Thought experiment**:
> Given your current product team, what would it take to ship one commit, maybe even a noop statement, to production? That is your team's *minimum cycle time*... Then, what would you need to do today in order to reduce the minimum cycle time to be under an hour? How could your product team continually achieve zero inventory, always safely delivering the highest value work immediately to the customer?
> - Zero Inventory Driven Development

# Introduction 

I have a passion for [software craftsmanship](http://manifesto.softwarecraftsmanship.org/), agile, and [lean startup](http://www.thestartupway.com/) principles.
The [Agile Manifesto](http://agilemanifesto.org/) expresses the importance of *individuals and interactions* AND *customer collaboration*.
Lean Startup is primarily about increasing throughput using [continuous improvement](https://en.wikipedia.org/wiki/Kaizen), [reduction of bottlenecks](https://leankit.com/learn/kanban/lean-flow-metrics/), and [validated learning](https://en.wikipedia.org/wiki/Validated_learning).
Finally, craftsmanship is about always measuring twice and cutting once. Michael Feathers introduced a definition of **[legacy code](https://en.wikipedia.org/wiki/Legacy_code) as code without tests**. *Don't be an ass, don't write legacy code*...

There will be a lot of links, I encourage you to read the contents each one, or at least assume I am not spouting madness no one else believes to be possible...

# Process Requirements

### 1. Trunk Based Development

If you are not familiar with [Trunk Based Development](https://trunkbaseddevelopment.com/), please follow the link and read, I'll wait. This knowledge fuels zero inventory driven development. *Successful companies do it! You could too!*

I have not yet experienced this style of software delivery professionally. Like a nerd, I dream about what that path looks like at my current, and previous, employers. There are **no technical hurdles** that prevent this way of software development in any position I have ever held...


### 2. Whole Team

Autonomous teams following a [whole team](http://istqbexamcertification.com/what-is-whole-team-approach-in-agile-methodology/) approach contain all the skills necessary to own the entire lifecycle of the [sociatechnical system](https://medium.com/@johnpcutler/the-product-system-a5bbd83424a6) they herd, or at least their sliver of it. **There is no concept of 'not my job', it cannot exist**. This mindset may be grounds for expulsion from the team. Delivery of value is always everyone utmost priority.

This is the hardest of the two truths. In your own thought experiment, I guarantee this is a majority of the work/resistance. It takes you MORE time to negotiate around internal team politics, bureaucratic middle management, organizational belief in separation of concerns, and 'process'... than to setup a ci/cd pipeline and deploy safe code.

# Technical Requirements

### Proper CI/CD Pipeline

I assume your company has made it this far. At least push button deployments... but if we have 'push button' deployments, why the fuck do we have to push the button when it is green... *<< screams into a swear jar and collects composure >>* At that point, it should be the machine...


### Zero Downtime Deployments

Can you deliver code to (some) end users automatically without interruption of service? There are many strategies for this. Two of my favorites are [blue-green deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html) and [canary release](https://martinfowler.com/bliki/CanaryRelease.html). I am sure there are MANY others.


### Realtime Feature Toggles

Here is an amazing blog post on [Feature Toggles](https://martinfowler.com/articles/feature-toggles.html). This simple, yet **BRILLIANT**, trick allows us to separate delivery from release. There may be perceived business reasons for delaying the release of a feature, but **no one external to the team should be able to dictate delivery**...

Tie them to a database table (or something changeable at runtime). Create a shared agreement on their usage. The correct default state of being is 'off'... in the case of a flag retrieval error, the user is served current system behavior. Keep it simple.


### Telemetry

If you can't log it, you can't measure it. If you can't measure it, you don't care... Find an asynchronous aggregate logger in the language of your choice, throw it up in a indexed searchable gui, like ELK (Elastic) Stack. Monitor the infrastructure at the hardware and network layers.

This is the foundational basis of the build-measure-learn loop. If telemetry on each layer of the stack is not a concept you are familiar with, please read [devops telemetry-basics](https://www.sumologic.com/devops/devops-telemetry-feedback/telemetry-basics/). First principle...


# Execution

> All characters and corporations or establishments appearing in this work are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.

My teams current *minimum cycle time* varies between projects, 9 days and 23 days.

The *first* thing I would do is get reassurance from my **executive sponsor** that I have magical red tape cutting scissors. Without this, my time is wasted apologizing for trying to deliver value to customers.

Second, is to **convince the team**. I have prewired this idea. I already have buy in from one of the five other individuals. I anticipate the resistance. *It is a fucking mood killer*. As the lead of the team I am going to ask to try an experiment... we program this way for one iteration.

> 'Rather than viewing these individuals as villains, we have to take their objections and skepticism seriously - and find ways to help them support the transformation rather than hinder it.'
> - The Startup Way by Eric Ries 

Third, my **technical requirements** are asserted to be truths. 

I work in a batch processing environment. The canary approach will be my first task. We already have two [Key Performance Indicators](http://andrewchen.co/know-the-difference-between-data-informed-and-versus-data-driven/) (KPIs) we can currently measure *work unit throughput per second* and *bytes received per second*. Objectively, I can measure those two items on a canary server and push changes outward as performance increases. Refinement of the CI/CD pipeline will ALWAYS be a first priority. We already have feature toggles!

**Execute** through leading by example. I have been developing like this for over a year now. I like to believe that EACH commit in every pull request I make could ship to production. I follow a simple process... *tdd, pindown tests, feature toggle, feature code, validate, cleanup*

Gather everyone in a room. Show them what this way of work looks like. Single piece flow until everyone is comfortable. I am a craftsmanship nut. I wish I could dictate that someone reads [Working With Legacy Code](https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052) and [Refactoring](https://martinfowler.com/books/refactoring.html) before discussing with me how to safely work in a monolithic legacy code base.

> To my current belief, XP principles combined with TDD enable execution of complex features pieced into the most difficult production environments safely in real time via CD. #zidd