Another year, another Pipeline Conference. In addition to hard-hitting talks, sneaky hallway discussions, and passionate Open Spaces, I found myself taking part in a Park Bench during the conference wrap-up.
It was great fun once I'd overcome my initial terror but a particular comment by Dave Farley stood out to me- paraphrasing, he said
If you focus exclusively on cycle-time, and optimise on that, everything else in Continuous Delivery falls out
Days later this was still rattling around in my head so I put pen to paper and here we are.
Continuously Delivering Value
I've always believed and maintained that Continuous Delivery isn't about just delivering features into production - it's about delivering value to the business which I'd always assumed was in "features for the user" form, or improving some metric. Maybe not. We frequently deliver features into production that may turn out to be throw-away work. Throwaway work isn't inherently bad if we learn something from it!
Continuously Delivering Knowledge
So my moment of realisation was that to me, Continuous Delivery is about high-tempo learning - taking a cue from Dave Farley, it's about aggressively optimising the cycle-time between "I want to learn something" to "I have the information I need".
This is why throwaway work is not always a bad thing if we're learning important information about not just the production systems but the business direction.
It's our responsibility as developers to learn as fast and as much as we can given the time we have. We may not have our hands on the tiller, but we can be first to spot the rocks and cliffs. We can warn the business, change course, and continue delivering value.