The following is a transcript from the video. The transcript has been edited for easier reading and organization.

Mark (Host):

Okay, well thank you everybody for coming today. This is going to be very exciting. Adam is here; he’s going to be talking about progressive delivery.

Adam’s worked with a number of startups and also worked at GitHub, and he can tell you more of the things he’s done. But he’s going to be talking about progressive delivery, and I won’t steal any of the thunder from the slides that I saw. I think this is going to be very, very interesting, particularly if you’re coming from a continuous delivery approach. As that being a good thing, Adam may open your eyes to how to maybe take that up to another level.

So, Adam, I’m going to turn it over to you. Oh, and first I say that and then I take it back. Adam said he likes being interrupted. So if you’ve got questions that you don’t want to say, throw it in the chat, and I’ll interrupt Adam, because I’m happy to interrupt Adam. Or throw a hand up or anything like that. There may be some points to pause. He’s going to get through his content, and then we’re going to look at having some discussion. And then we do have a quiz at the end where you can win a copy of his book, which just came out today, if I understand correctly. So you will be one of the first people to order on the day that it was out. I’m looking forward to getting my copy and reading it. So with that, I’ll turn it over to you, Adam.

Adam:

Thank you. Thank you so much, Mark. Really appreciate it, and thank you all for joining today. I really appreciate the audience. As Mark indicated, from my perspective, I really look forward to engaging with you. Happy to share some stuff that gives it some context, but really looking forward to hearing your feedback, hearing your ideas. I would love it if you disagree with me, because if you agree with me on everything that I say, that can be a little bit boring. So feel free to speak up. Either use the chat—I’ll be trying to monitor that as I’m going through some of these slides—or interrupt me, come off mute. This is an opportunity for you to be part of the conversation and not just passively absorbing.

What Is Progressive Delivery?

So with that, I’m here to talk to you about progressive delivery. I’m also excited to say that today is launch day for the book that I wrote with a few of my co-authors for talking and exploring this topic. This is something that I have been talking about and exploring for the past seven years. And with my co-authors, we were the ones who actually invented this term and have been exploring what this means and what this looks like, and ultimately, how can we enable people to start thinking about it and being successful with paying attention to what they’re building and who they’re building it for.

So with that, let’s talk a little bit about who I am and why you should care what I have to say. I am one of the co-authors of Progressive Delivery. I have been building products, process, and teams for about 25 years in the industry. The majority of time spent has been in the areas of infrastructure and developer tools. I’ve done some interesting stints at various companies. I’ve also been an advisor and a board member for a number of other startups in the space. The common thread throughout my career has been: How can we actually enable people to be more successful with technology? What does that mean for users to be able to actually get value from the products that we’re building and from the ways in which that we’re delivering them to the end users?

All this comes from my background in physics. And as Mark pointed out in one of his LinkedIn posts about this talk, yes, my first career was actually as a street performer, juggling things like fire, knives, and circular saw blades. Basically, I’m just an attention seeker.

The Problem: Technological Jerk

I want to pose this first from the perspective of a story. This is a little vignette that makes an appearance in the book, but it’s one that I found that a lot of technologists can connect to.

It’s Friday, 9:52 p.m. You open an app on your phone to adjust an alarm on your smart speaker. You need to make sure that everyone’s alarms are all set up because you want to wake up early for a flight that you’ve got to take in the morning. You open the app and you notice it looks different because there was an update, and you’re like, “Oh, cool app update, right?” And then you go and you start to say, “Oh, I need to find the alarm to adjust it.” And you can’t find it. You’re looking and looking. Then you’re like, “Wait, something’s going on.” You go to Reddit and you’re like, “Hey, where’d this go in the new app?” You find out after reading a number of threads and subreddits that it turns out the purveyors of the app deemed that to be a non-critical feature and removed it from their latest app update. Then you get the pleasure of running around trying to find a solution that can help you because you have been jerked around by technology—technology that you chose to depend upon is no longer actually helping you; it is in fact making your life worse.

As was pointed out, Mark, this is not entirely a hypothetical situation, but I’m sure that we’ve all been there. As people who use technology on a daily basis, there’s been some instance in your life where software has been updated without your consent. You have now been jerked by that technology.

I keep using that word jerk. This comes from my physics background. In the context of physics, jerk is actually the third derivative of position. The first derivative is velocity, the second is acceleration, and jerk is the change in acceleration. The reason I use this term in the book is that this is what we experience: that rapid change in acceleration. We often feel this in the real world when an elevator moves too quickly or stops too suddenly, or if you’ve ever been in a car accident or stopped short in your car. That is an example of jerk. In the context of technology, we’re starting to see that jerk is becoming more common in technology release and adoption.

The rate of technology adoption used to be measured in decades in the early 1900s. By the end of the 1900s, that adoption rate started to collapse. We were talking about years, then months. Now, with things like ChatGPT or other AI tooling, adoption rates can be measured in days or even hours to reach 60% adoption. That rapid change is hitting the mainstream, but what does this mean for those of us that aren’t ready for that change?

A Shift in Delivery Focus

From a user perspective, we really need to be thinking about that user adoption function in the context of how we’re building products. A big part of the book is talking to the builders—the people responsible for building and shipping software—and trying to help them actually start to think more deeply about user adoption.

We developed a quadrant to explore this, based on two axes:

1. Developer Autonomy: How flexible is it for the developer to just ship?
2. User Adoption Alignment: How well do we align with the user’s adoption rate?

• Waterfall was the predominant methodology when software was tightly coupled to hardware. There was no user context or ability to provide feedback, so user adoption wasn’t a major metric. Developer autonomy was low because of the tight coupling to physical hardware.
• When we introduced Agile and started decoupling software from hardware, the focus shifted to the user. We had user stories and sought feedback to make course corrections. It had a pretty good level of user alignment, but it continued to lack a high level of developer autonomy.
• With the rise of the cloud era, developers wanted more flexibility and wanted to push code on their own. Continuous Delivery was the expected model, driven by the motivation to get code to production quickly. Unfortunately, with that, we lost sight of user adoption. The focus shifted too far toward the developers building what they thought was important, often shipping things without the ability for users to say no. This was the epitome of the SaaS movement where, “I control the entire user experience on the back end, I can push out changes whenever I want, and the user just has to take them.”
• This is where Progressive Delivery comes in. We want to start encouraging builders to think about both the speed of Continuous Delivery and the user focus of Agile. From an Agile perspective: We support your concern for users, but we think there are practices from Continuous Delivery that will enable your developers to be more autonomous and ship at a faster pace. From a Continuous Delivery perspective: We think what you’re doing is great from a developer autonomy perspective, but we think there are things you can do to actually better align with the needs and value you’re delivering to your users.

Ultimately, Progressive Delivery is about two things:

1. Enabling your developers to build and deploy without friction.
2. Enabling your users to adopt at a rate that maximizes value to them.

We are talking about building the right thing for the right people at the right time.

The Third Loop

We’ve added a third loop to the standard DevOps infinity sign—the virtuous cycle between dev and ops. That missing loop is the user adoption loop. We need to make sure we are mindful of this when defining criteria and constraints, and paying attention to it from a monitoring and observability perspective.

Core Tenets

Progressive Delivery has two core tenets:

1. Progressive Rollout: This includes things like using feature flags and cohorting to expose new functionality in production only when your users are ready for it. Start with an internal staff ship, then move to beta users or power users who are most excited for the change. Get their feedback so you can refine the feature before pushing it out to people who may be more hesitant or more impacted if you change their workflow.
2. Radical Delegation: This term comes from the U.S. Navy. In early days, pre-satellite communication, orders were issued to the captain of a ship in the form of an objective, and the captain was responsible for managing the way that objective was reached. In the context of technology, it means providing the controls and objectives, and giving someone else the ability to execute. We want to help organizations delegate control over who gets to make the decision of when a feature is available to a given user.

A good example of Delegation is when a developer has a new widget:

• Developer is responsible for control at the beginning (sharing with other developers, operations team for validation).
• Operations Team is responsible for the next cohort (beta users, staff ship) because it’s their infrastructure and they hold the pager for outages.
• Product or Marketing Team dictates the release to a broader audience, perhaps to time it with a press event or marketing push.
• Customer Support/Success/Sales Team handles feature functionality gated on licensing or tiering, performing the enablement of that customer.

Radical delegation means delegating control of who gets to see what when as close to the customer as possible. The ultimate example is personalization within an application, where users are given access to make their own choices about whether a feature is on or off. Organizations have adopted this practice by asking: “Do you want the latest and greatest version of everything that comes out, or do you want to wait?” This is the push versus pull dynamic, ensuring users who are excited get changes right away, and those not interested in change have the ability to hold off until they’ve been prompted with videos, tutorials, or documents that help them understand the changes.

The 4 A’s Framework

To measure organizational readiness for progressive delivery, we developed the 4 A’s Framework: Abundance, Autonomy, Alignment, and Automation.

1. Abundance: We live in a cloud era and have access to all the resources we could want. This asks: What have you done from an organizational perspective to ensure that your developers and builders actually have the ability to access those resources? A lack of abundance is an immediate bottleneck.
2. Autonomy: This couples closely with abundance. Are developers capable of moving their work forward on their own, or are there constraints? The goal is for any developer to push to production at any time, backed by controls, not constraints.
3. Alignment: This is the flip side of autonomy. How are you making sure that the things being built are actually relevant, needed, and desired by your user base? We must ensure the teams and individuals are aligned with the goals of the organization and the expectations of the customer. This requires paying attention to the feedback loop with your users: direct feedback (support requests, bugs, NPS surveys) and indirect feedback (observability on feature adoption, workflow dropout rates, time-in-app data from tools like Pendo or WalkMe).
4. Automation: This is extraordinarily important for organizations as they scale. We often talk about automating build and deployment systems, but a critical component is using technology to actually lighten the toil of our users. How are we monitoring user adoption and workflows to introduce automation to make tasks easier? Instead of 15 clicks, maybe it only takes one or two because you already know what the user is going to do. If you know 100% of the time the answer is going to be the same, don’t ask the question—just autofill that information.

Conclusion and Q&A

Adam:

I’m going to pause for a second for any questions.

Max (Audience Member):

Why are continuous delivery and progressive delivery opposed to the Agile quadrant? Isn’t that weird? We also talk about developer autonomy working at a team for a product, and maybe what I understood better is individual autonomy as regards teamwork, but I’m not so sure. Could you make a difference between Agile and Continuous Delivery and Progressive Delivery? What does Agile mean in this?

Adam:

I think I know what you’re saying. The point of this was to really talk about what the various different development life cycles are optimized for. In the context of Agile, it was still a very structured software development life cycle, which works for a large organization in particular. That structure gives you the ability to have visibility up the organization of what things are being worked on, as well as some level of autonomy down to the team level of making sure that you’re able to adapt to changes.

In the case of continuous delivery, the autonomy is much more about the individual developer’s ability to drive a piece of work from idea to deployment. An Agile team might not go in and just do a bunch of technical stuff because it’s very driven by “here’s what you need to do,” rather than a situation where they’ve got a lot more control over “here’s what I think needs to be done, I’m going to go do it, and I don’t necessarily have to find a user that’s asking for this particular piece of things.” That’s definitely one way to talk about it.

Mark (Host):

Does this eliminate staging or test servers?

Adam:

From my perspective, I have been advocating for a while that you consider your users’ regulatory constraints or other things. One of my favorite organizations that I worked with when I was at LaunchDarkly was Fannie Mae. Fannie Mae, a rather large, federally regulated organization, had a bunch of contracts that actually restricted the frequency with which they could update software and required them to have a certain level of training hours made available to the users prior to its release. This really inhibited their ability to adopt SaaS tools because they couldn’t control what the experience was going to be like.

One thing they tried to work with us on was becoming an evangelist for LaunchDarkly back to their supplier vendors, saying, “Hey, can you actually use LaunchDarkly so that we can have greater granularity of control of when we get new software updates from you as a SaaS product?” And then they used it themselves to make sure that they had protected releases and granular control for the software they were providing to their end users.

This is how we make it so that the notion of user adoption becomes front and center again, but at the same time, take advantage of the continuous innovation. It’s the difference between getting the update for a new online video game, which is fun, and your bank rolling out a new website that completely changes the way you log in, which can be frustrating. 

Mark (Host):

My bank put a confirmation step after bill pay that I was not expecting. I had lots of late fees because I didn’t have to click through before, and now it was there. It wasn’t a bad change, but if I could have opted out of that, it would have saved me 15 bucks.

Mark (Host):

Taylor was asking if there’s a place to learn more about the Fannie Mae case study.

Adam:

I know that there used to be a Fannie Mae case study on LaunchDarkly’s website. I haven’t been there in a number of years, so I don’t know if it’s still up or if they’ve taken it down. I know that we did do some webinars with them, so there were some other resources. I can probably check in and do some digging for you and send Mark a note, and maybe he can add this to the show notes at the end. That may be one of them.

Bringing Change to Your Org

All right, let’s talk a little bit about what some calls to action are for your organizations or your teams. As one of my favorite authors, Brandon Sanderson, says, “Journey before destination.” Part of this isn’t about getting to an end state of “Ah, look, we’re doing progressive delivery.” It’s more about how do we start to think about these ideas and make some incremental improvements? How do we bring this back to top of mind for how we’re building and interacting with our users?

• From a dev’s perspective, this looks a lot like a continuous delivery mindset: How are you looking for bottlenecks and identifying areas to increase the efficiency and speed with which your developers are able to build and deploy to production?
• From an ops perspective, this is about taking continuous delivery ideas and thinking about controls. How do you deploy feature management or feature flagging? How do you start to look at modern observability techniques instead of just simple monitoring where you’re looking at uptime? Instead, how are you looking at the number of users that initiate a workflow, how far they make it through, and what the dropout rate is? How are we actually looking at feature adoption?
• From a product perspective, what do we consider “done”? As one of my co-authors, Heidi Waterhouse, says, “Is software ever really done?” The reality is that in today’s world, the answer is often no.

From a user perspective, how are we starting to imagine this through the user’s mindset? What is the rate of change that is appropriate for the user? This is going to be different if we’re a bank that has cohorts ranging from new bankers at the age of 10 or 13 up to people in their 80s or 90s. How do we make sure that we’re providing the right level of change to all those individuals?

A review of the 4 A’s:

• Abundance: Giving your developers all the computing resources they need to move their work forward.
• Autonomy: Measures the developer’s ability to move their work forward on their own without external constraints.
• Alignment: The focus on the user, paying attention to both direct and indirect feedback to ensure what is built is actually needed and desired.
• Automation: Using technology to lighten the toil of both builders and users.

The key thing here is that you want to think about how every small improvement helps to reduce that notion of technological jerk that your users will potentially experience. This is really about removing the jerk from your software.

Thank you all so much for your time today. If you’d like to learn more, the book, as Mark indicated, launched today. So it’s available on your online book purveyors, as well as in some local bookstores, available in most Barnes & Noble. I would also encourage you, if you have a favorite local bookstore, ask them to order you a copy. I’d love to get it on their radar and see it on their shelves. With that, you can provide me with feedback in the form of a five-star review. I would always welcome that, and would love to hear from anyone that has some interesting stories either with regards to how they’ve experienced technical jerk, or how they have used Progressive Delivery to build better products.