Small Internal Releases Lead to Happy Customers

If you saw Large Program? Release More Often, you might have noted that I said,

You want to release all the time inside your building. You need the feedback, to watch the product grow.

Some of my clients have said, “But my customers don't want the software that often.” That might be true.  You may have product constraints, also. If you are working on a hardware/software product, you can't integrate the software with the hardware either until the hardware is ready or that often.

I'm not talking about releasing the product to the customers. I'm not talking about integrating the software with the hardware. I'm talking about small, frequent, fully functional releases that help you know that your software is actually done.

You don't need hardening sprints. Or, if you do, you know it early. You know you have that technical debt now, not later. You can fix things when the problem is small. You see, I don't believe in hardening sprints.

Hardening sprints mean you are not getting to done on your features. They might be too big. Your developers are not finishing the code, so the testers can't finish the tests. Your testers might not be automating enough. Let's not forget architectural debt. It could be any number of things. Hardening sprints are a sign that “the software is not done.” Wouldn't you like to know that every three or four weeks, not every ten or twelve? You could fix it when the problem is small and easier to fix.

Here's an example. I have a number of clients who develop software for the education market.  One of them said to me, “We can't release all the time.”

I said, “Sure, you can't release the grading software in the middle of the semester. You don't want to upset the teachers. I get that. What about the how-to-buy-books module? Can you update that module?”

“Of course. That's independent. We're not sure anyone uses that in the middle of the semester anyway.”

I was pretty sure I knew better. Teachers are always asking students to buy books. Students procrastinate. Why do you think they call it “Student syndrome”? But I decided to keep my mouth shut. Maybe I didn't know better. The client decided to try just updating the buy-the-book module as they fixed things.

The client cleaned up the UI and fixed irritating defects. They released internally every two weeks for about six weeks. They finally had the courage to release mid-semester. A couple of schools sent emails, asking why they waited so long to install these fixes. “Please fix the rest of these problems, as soon as you can. Please don't wait.”

The client had never released this often before. It scared them. It didn't scare their customers. Their customers were quite happy. And, the customers didn't have all the interim releases; they had the planned mini-releases that the Product Owner planned.

My client still doesn't release every day. They still have an internal process where they review their fixes for a couple of weeks before the fixes go live. They like that. But, they have a schedule of internal releases that is much shorter than what they used to have. They also release more often to their customers. The customers feel as if they have a “tighter” relationship with my client. Everyone is happier.

My client no longer has big-bang external releases. They have many small internal releases. They have happier customers.

That is what I invite you to consider.

Release externally whenever you want. That is a business decision. Separate that business decision from your ability to release internally all the time.

Consider moving to a continuous delivery model internally, or as close as you can get to continuous delivery internally. Now, you can decide what you release externally. That is a business decision.

What do you need to do to your planning, your stories, your technical practices to do so?

5 Replies to “Small Internal Releases Lead to Happy Customers”

  1. Hi Johanna

    A great article I agree with completely. There are some potential drawbacks of too frequent releases as well. I haven’t experienced them myself but I’ve heard my friends complaining about two things with respect to Google tools releases and Facebook. One they keep changing UI too fast so a user needs to continuosly adapt her habits and two they don’t communicate what and why they change.

    1. Aleksander, those are frequent releases that are external. Those two companies also do A/B testing. I’m not talking about that.

      If you want to do A/B testing, you must do frequent external experiments.

      I’m talking about internal releases, where you know what you want to do. The risk is in changing people’s behavior from bundling a ton of things together to make a big release once or only several times a year, to many times a year. I’m talking about a change in your mindset.

      In an agile program, if you wait until the end to release everything, you are likely to make mistakes about what the customers need or want. Worse, you end up with big-bang or staged integration. One way to move to continuous integration, and to something that looks closer to continuous delivery is to make small internal releases.

      The more small internal releases you have, the more flexibility you have for an external release. You know if you get to done, all over the program, which is good to know. You can see the product come together. The product owners can decide where in the roadmap they can decide to spend more of the teams’ time. You get more bang for your product development buck.

      If you don’t see the product get to done, you don’t see any of this.

      If you want to release to customers, you now have a choice. It becomes a business decision. If you want to confuse your customers with UI changes, that is a business decision, also. (grin.)

  2. Hi Johanna –

    I agree that it’s about changing mindset! I think a sort of muscle memory kicks in or our reptilian brains react to the word “release” and all the work they used to entail when we did them less frequently. When we treat them as celebrations – of success or of learning – and make then fun events, we can create excitement and energy rather than the sort of dread that makes you cross your fingers and hold your breath! If we can change the feelings we experience when we have a release, maybe we can change our attituudes about them – what do you think?


    1. Terry, I like that idea of treating those releases as celebrations, certainly as learnings. I make the point in the book that creating software is all about learning.

      Particularly in agile, we need to release, at least internally, to see what we have and learn from it. If we don’t, how can we learn?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.