Trajectory Nano Series Takeaways: “Making Releases Boring in the Enterprise”

Recap of week 1: Build

Leading up to Trajectory LIVE, LaunchDarkly’s two-day conference on August 26-27, we’re hosting Trajectory Nano Series, four interactive talks on Wednesday mornings at 10AM Pacific Time. These will focus on the Four Pillars of Feature Management: Build, Operate, Learn, and Empower. The first week is now behind us. In the first segment of this four-part mini-series, we explored the Build Pillar of feature management.

The Build pillar

Build covers feature flag use cases that enable teams to build and deliver software faster, with less risk. In Build, it is also assumed that you incorporate feature flags in the design and planning process for new features. In Build, product delivery teams use feature flags to do the following:

Separate deploy from release. Engineers can deploy code—even incomplete code—to production whenever they want; the marketing team can then release when they are ready.
Test in production. Take the stress out of releases by first testing code directly in production without exposing it to the wrong users.
Targeted rollouts. Progressively deliver features via targeted rollouts, ring deployments, and other controlled techniques while gathering valuable user feedback and engagement data along the way.
Canary launches: Release to a small group of low-risk users first to see if it’s safe to forge ahead.

Speaker John Feminella, Technical Advisor at ThoughtWorks, unpacked some of the core ideas of Build in their talk on “Making releases boring in the enterprise.” You can watch the whole video here, or if you want the tl;dw (too long; didn’t watch), here are three takeaways from his talk.

Put customers first

The ultimate goal of software delivery is to serve your customers. Customers are using software to improve how they work, live, or serve their own customers. You need to provide the outcomes customers are looking for when they use your software. Even if you’re not a software company, if the customer completes a task using software, your company needs a software delivery organization.

For example, airlines are in the business of flying customers from one location to another. As part of that process, customers want to purchase tickets and check-in on-line. This requires a software delivery organization to meet these aspects of the customer’s journey. All companies are software companies if a customer uses software when trying to complete a task.

Make releases routine

As releases become more routine, their risk to the organization is reduced, and less risk is better. Three ingredients are needed for this to happen:

Minimize the time spent in the pipeline to deliver outcomes in a timely manner
Maximize the number of times a pipeline is traversed in a given time
Deliver the right product and the right outcome to customers

Progressive delivery is one way to make releases routine. Instead of releasing one version of software to everyone, you can release software to whoever you want, whenever you want.

User segmentation and feature delegation

Not every user is equal when it comes to a release. Segment your users to minimize risk and maximize feedback. Ask yourself who the best person in your company is to help identify the user segments and manage feature delegation. Feature delegation refers to who within the organization is responsible for In many instances, this falls to the product owner.

Conclusion

A big thank you to John and our sponsor, Rollbar!

Next week, the Trajectory Nano Series will cover Operate, the Second Pillar of Feature Management. Michael McKay, Senior Development Manager at IBM, will touch on some of the core concepts of the Operate Pillar in his talk “I <3 Feature Flags”.