At Hightower, we release daily. Yeah…daily!

Releasing anything shorter than weekly to me was startling, especially since all my previous tech jobs were mostly a 2-week release cycle, but after a week or two, I finally overcame the shock and started to really enjoy it. Here’s what I learned so far:

What we do to be successful in a continuous release environment

Kanban

We don’t have one-, two- or three-week sprints. We Kanban.

Using Kanban allows us to remain flexible. Once something has been reviewed and sized by the engineering team, the Product Manager has the luxury to reposition any item in the What’s Ready for Development column, allowing us to work next on the most impactful items next even though there might be other items in there that we’re spec’ed and designed earlier.

Multiple Environments

As soon as something is coded, it doesn’t go directly into production. Code makes it way through various environments before making it to production. Having code move through these environments before it hits production allows Product Managers to go into each environment and review features and bug fixes before it hits our customers, allowing us ensure everything is according to spec, quickly find any bugs, and add any followup user stories, if necessary.

 

Automated Tests

This blew my mind: our engineering team is constantly writing unit and feature tests for everything they build, which means they are the first to know whenever new code breaks something, and they can quickly investigate and fix it, drastically reducing the amount of time required to find and fix the issue.

 

Features are broken into the small, atomic units

When we design features, we define and design them in a holistic fashion by thinking of all the ways the new feature pokes through the product’s interface and any other support systems.

But, when we prepare our the features for the engineering team, we always break up the features into the smallest independent aspects that can live on their own. By building what I call the atomic units of the feature, we are able to build and release features a lot fast, resulting in a number of beautiful benefits:

• It’s easier for the engineering team to understand the impact of the system, allowing us to better understand the majority of the impact before going ahead with a feature.
• The engineering team can provide better estimates since they are looking at smaller pieces. With accurate estimates, I can then rely how long it will take time-sensitive issues/features back to other teams and/or customers as needed.
• Each atomic unit is easier to test, in terms of automated testing and quality testing.
• Most importantly, customers are happier:
  • They receive the value of new features sooner rather than later
  • There’s a smaller impact on them since our changes are not “big-bang” changes, but more like incremental changes.

Outside of building features, bug fixing has become audaciously fast since we use Kanban and have daily releases. For bugs that don’t require a hotfix, high priority bugs fixes tend to make their way into production in 2 days! This is incredible, especially since I used to be in a world where it would take weeks to months to fix and release bugs. Our customers have definitely expressed their shock and amazement at our speed.

Although there are all these benefits for building product in a Kanban and Daily Release environment, there are some downsides:

• Regression testing is extremely hard since there is no single build to test as a new one is generated every time something is checked in. Automated/unit tests can only catch so much, and as a result, the entire company is extremely vigilant when using the product during their day-to-day and logging bugs whenever one is encountered.
• On very rare occasions, we may release an incomplete feature—something that isn’t ready to provide value without another piece. This happens when a feature that gets broken down into let’s say two atomic units and one unit released on one day and another unit released the next day. It’s only when both units are in production that users are able to fully utilize the feature and experience the great value we aim to provide.

All in all, I find myself extremely lucky to work in such an environment and after experiencing all the amazing benefits of such an environment, I don’t think I can ever go back to a sprint based, weekly/bi-weekly release schedule…well maybe if it’s for a mobile app!