Expedite value. Learn sooner. Generate options.
The seventh behavior, “Release ridiculously often,” is usually met with nods from half of the crowd and raised eyebrows from the other half.
The nodding half usually asks, “Why is this the seventh behavior? Why is it so low on the list?”
It is low on the list because the prior behaviors are prerequisites for this one to be effective. I am amazed at organizations I go into where they don’t clearly define the problem, don’t make the work particularly visible, and don’t work together much; places where development is done in large chunks with high coupling and most of the behavior isn’t validated — much less the need or the value — BUT they have a CI/CD pipeline in place.
I’m not saying you should dismantle the CI/CD pipeline. It’s probably fine. What I am saying is that as you work on the first six behaviors, the value of actual Continuous Integration and Continuous Delivery, and your ability to release ridiculously often improves.
Now, from the eyebrow raisers, I often get the question, “What do you mean by ridiculously often? What is ridiculous?”
My answer is, “I don’t know. You tell me.”
If you are working in an environment that releases every six months, I’ll bet every three months seems pretty ridiculous. If you’re releasing every week, every day probably seems ridiculously often.
Of course, there is some point at which releasing more often is either beyond your risk threshold or simply offers no discernible additional value. But in my experience, most organizations, especially those running release trains or some other form of larger dependency “managing” coordination effort, have many aspirational points of “ridiculousness” before they approach diminishing returns.
In future articles, I’ll share more on tools and techniques related to releasing ridiculously often.
If you want to keep up on the progress of the Behaviors Book, pay attention to the Behaviors Book page. And if you would like to learn more about how we use The Behaviors to guide teams, reach out.
Whether you’re still figuring out your general product offering or you are enhancing and adding capabilities to a well established product, the ultimate test of whether or not you’ve hit the mark (or are at least trending in the right direction), is how your audience engages with what you’ve created. Yes, you can (and should) do market research before designing and coding up a potential solution to an identified problem, but the only way to know for certain, is to see what happens when your concepts come in contact with your audience.