Note: For my developer friends, you’ll likely need to squint a bit at how I use the word integration. I go from using it in the context of integrating code all the way up to “integrating” different perspectives.
A team goes for a couple weeks without integrating, releasing, testing, or discarding work. What’s going on? The team is accumulating inventory, and the code and design is just sitting there. You haven’t put it to work yet. Meanwhile the “business” is nervously concocting a Plan B. The problem is especially acute when you have no idea whether any of this is going to “work” on a technical level, user level, customer level, or business level.
When considering inventory and integration there is a spectrum, however. If CI is humming along, you are reducing some risk. If you’re showing half-working prototypes to customers, you are reducing risk by generating learning. If you are disproving assumptions and discarding ideas, then you are exchanging inventory for learning. Releasing a cohesive end-to-end thing into production — even behind a feature flag — is a form of inventory risk reduction.
…it is still “sitting in inventory”. And any effort to define an exact point that something leaves inventory is futile. Consider a feature that is in production, being used, and “generating value”. At a certain point the market may shift. That feature becomes less and less valuable as time passes. In reality, the complexity added by that feature has always sat in inventory…adding a slight bit of drag. With time, that drag becomes a net liability.
It’s sort of like planting and tending to a farm. Work bears fruit and veggies (value). Shipping is planting, pruning, and harvesting. You can’t “scale” without adding land, and pathways, and irrigation. There are non-linear effects to contend with like changes in soil health, the impact of climate change, and a beneficial increase in biological diversity. In short, you can’t divorce the “product” — the stuff harvested and packed into boxes — from the farm. You have all kinds of inventory (seeds, biomass, water maybe) and all kinds of integration…ranging from inspecting the farm each day, to seeding, pruning, and harvesting.
I was thinking the other day that Lean & Agile are basically about doing some things more often (not necessarily faster, just more frequently)…which necessitates doing things smaller. Note how most of the things on the left involve some form of integration (using the non-technical definition) and inventory/risk transfer.
I would contend that the mental leap is internalizing the joint concepts of “inventory” and “integration”, and how those things impact the ways we work. Not in rigid terms (e.g. “we shipped the code” or “that queue has precisely 5 tickets” or “CI ran”)
, but in looser and and more profound terms. We can use “integration” to convey end-to-end learning, validation, testing of the whole, etc.
- Consider the team dutifully “doing Agile” and releasing reasonably usable work (hey, we tested and the PO said “this is great!”) into a massive queue for so-called “sales enablement”. That is lots of inventory, and a long delay to “integrate” (in the “integrate the value-proposition” sense). But hey, R&D is kicking ass!
- Consider going to work with a dull sense of dread. You’re worried about the state of the system in production. You’re worried something may happen. You and your teammates have an inventory of cut-corners weighing on your psyche.
- …Or the very simple sensation of seeing a chock-full calendar, and not being able to schedule the meeting you really need to schedule.
…Or the string of things that feel incredibly wasteful and inefficient — like duplication, far-flung ideas, unstructured time — but that buy us options, learning, and innovation.
Intuitive, But Not
I did an exercise with a relatively “inexperienced” team recently. They brainstormed on questions of inventory, waste, and integration. I was blown away by how easily the concept percolated with the team.
It’s like we inherently understand these things — we get the theory — but we have a lot of trouble turning it into actual action. Why? Until you’ve seen it “work”…smaller batches, keeping inventory low, and frequently integrating will make absolutely no sense. You probably won’t even feel the inventory stacking up.
You can tell a good bit about a company by how the organization views inventory and integration.
We’re Lucky To Ship Anything! Many companies have so much inventory and work in progress, and so much debt dragging them down (UX, technical, organizational, partner and customer relationships, learning, measurement), that they rattle on about the problem of “getting anything out the door”. The irony is that “getting anything out the door” was probably what led to their predicament. But you find absolutely no awareness of inventory and the need for frequent “integration” (end-to-end testing, validation, pivoting, etc.)
“Heck, we’re lucky to ship ANYTHING!”
Left to Right. More “mature” orgs can ship things (whole things) that don’t explode. The work is usable and stable. Developers and UX view themselves (self identify, even) as some kind of “station” on an assembly line. Focus! Break it down! Ship it out! Left to right. Move to done! Off our plate! Pray for no rework! Get this in production! Here, inventory is reduced when, in theory, the work can be handed over the operations to “run”. Risk is reduced prior to shipping. You still have plans and promises piling up, but the factory just hums along (and hopefully your complexity inventory doesn’t drag you down).
Systems Thinking. From there you start to get increasing levels of systems thinking (and more conceptual views on inventory and integration). Is the org healthy? Are we slowing the march of entropy? Is the work producing long term benefits? Are we “integrating” our learnings, priorities, promises, and assumptions? How do we swarm on areas of poor org health to avoid chronic illness? Can we change course quickly to pursue new opportunities? How long will we continue to go down the wrong path, even after knowing we need to change course just out of the sheer inertia of inventory and lack of integration?
Nothing groundbreaking here, but some thoughts and questions.
- We can guide new teams by helping them frame integration and inventory more broadly. Inventory might be better understood as “drag”. Any tricks to do that?
- Somehow we need to ween people off of this left-to-right delivery fixation with an arbitrary done-ness. The story isn’t over. How?
- Inventory and integration can be viewed from many different perspectives and at many different levels. We should be careful about deciding on a “hard transfer” (e.g. moving a ticket to “done”).
- Perhaps it doesn’t really matter if we use sprints or continuous delivery. Use whatever helps you integrate frequently (again, across multiple dimensions).
- Companies evolve when they start to take a more systems based view of inventory and integration.o