So we were really excited to give a talk at IT Revolution’s conference, the Enterprise Technology Leadership Summit. It gave us a chance to lay out our vision of what Progressive Delivery is, and what it may be in the future.

What does it mean to get the right thing to the right person at the right time? How do we build teams that can break the silos separating software makers from users? How do we show that consent, accessibility, optionality, and humanity are a crucial part of the software story? We don’t have all the answers, but have a listen here:

If you want to know more, pick up the book!

ETLS talk Transcript

Adam Zimman: All right. We are here to talk to you today about progressive delivery. And contrary to my eldest child this is not about a book on liberal birthing. instead, we’re talking to you about the next iteration of the product development lifecycle. specifically thinking about how you build the right thing for the right people at the right time.

So there are actually four authors to a book that we recently wrote. Three of them are here before you. The fourth one is currently in London so he will not be joining us today. but myself, I’m Adam Zimman.

It’s a pleasure to be here with you today.

Kim Harrison: I’m Kimberly Harrison.

Heidi Waterhouse: I’m Heidi Waterhouse

Adam Zimman: And our fourth author is James Governor.

So we came together about seven years ago when we started to notice some patterns in our industry. Who here has ever used an application or any device that actually has software and experienced the creator, the manufacturer of that device or the owner of that application making a change that they were not prepared for ?

Heidi Waterhouse: Adam.

Everyone loves change.

Everyone loves it when their phone does a new thing.

Adam Zimman: Exactly. I completely concur. Everyone loves change.

Heidi Waterhouse: All the time. All the time. Every day.

Adam Zimman: And this is one of those things where we’ve talked a lot already today. And I’m sure you’ve been to more than one, talk in the past, decade hearing about how you can ship faster, how you can remove bottlenecks from your development life cycle. Who’s been to one of those talks? Maybe one. One. Yeah. It seemed like a good idea at the time, didn’t it?

Alright, so we think that there’s actually something missing, with regards to all of this. Increase in pace and increase in change. First off, it’s the recognition that change is hard, right? Change is hard for all of us. Now there’s a caveat to that. There are some things, some changes that we personally want.

That we will push for, we will fight for, we will work for, but that same change is not necessarily going to be appropriate for everyone, right? A good change for me may not be a great change for you, right? But it’s really hard to know who fits into which category, which segment of your user base. So one of the things that you need to understand is that there’s this concept in physics.

So my background is in physics. There’s this concept that I feel like captures this perfectly. It’s actually in physics, it’s called jerk. All right.

Heidi Waterhouse: We wanted, to name the book Jerk, but we decided to be nice.

Adam Zimman: We were told by our publishers, thank you, IT Rev, that, maybe that would be an awkward thing for you to hand a book called Jerk to Your Boss and say, I think we should talk about this, which we had to concede that was probably true. but the concept of jerk. In physics and also in the context of the book and how we talk about it for progressive delivery is jerk is actually the third derivative of position. For those of you that don’t recall your college physics or didn’t take college physics, because that sounded like a horrible idea, ultimately this means that it’s the change in your rate of acceleration, right?

So think about that. If acceleration is your change in velocity, right? You’re starting to move faster, right? Jerk is that next iteration, that next degree that you’re talking about. And this is what we kind of experience, like the most, obvious, type of physical jerk is if you’ve ever been in an old elevator that abruptly stops or you’ve been in a car where someone slams on the brakes, it’s that rapid change in acceleration.

That you just feel right. It’s a physical feeling. And what we started to notice is that this was very similar to how people were describing and reacting to changes in their software, right? And this was something that we wanted to really get people that are building software to start to think more about and more directly about, because we believe that as builders, we need to be actually better at understanding this concept of jerk in the context of our users so that we can actually provide a better experience that will actually accelerate adoption of the things that we’re building.

So when AI started to become the thing that everyone was realizing, wait, this is a game changer. We say we were in the middle of writing this book, right? And we’re just like, oh, we should probably make sure that we’re incorporating something around AI. And as we started to have some conversations about it, we realized, wait a second, this is actually validating everything that we’ve been doing, everything that we’ve been talking about.

This is, something that we took a look at it. And I remember actually Nathen gave a talk, last year on some changes in the door report and how they were thinking about ai and they’re just like, oh wait. Same thing. This is just validating all of the data that we’ve been collecting for years, right?

We’re starting to see how AI is once again, making it even easier for people to ship more product, to be able to ship more features. Nothing is getting slower from the perspective of building software. But that doesn’t necessarily mean that people are capable of adopting things faster because we are still humans.

And so one of the things that we talk a lot about in the book is this notion of how do we actually decouple this idea of building and innovating from the experience of change. How do we make this easier for users and make sure that they are actually in greater control of how they’re experiencing all of the amazing awesomeness that we’re all building?

That one.

Heidi Waterhouse: So we think that it’s important to provide some factors to teams that are building so that they can understand the effect that they’re having on their users and their consumers. we grouped these into four As and they’ve held up for the entire time we’ve been writing this book. It’s been very interesting to us.

We were talking literally this morning about whether it. Whether we would reorder them if we were writing the book again, and maybe not. Maybe we got it right the first time. So the first one, or the, what we need is to accept the changes that come into our teams as they come. So it turns out all of the Tetris pieces have names, and I’m fascinated by this also, orange Ricky is such a weird name that it had to be an actual software designer who did this. But we can’t control when we’re going to get more of these factors. We can only say we have an organization that is going to get these factors at different speeds. So the first one is abundance. When we think about abundance, the easiest example is the cloud.

I’m looking at most of you in this room and you remember. When the cloud came in, when your data center started to shrink, when you could have elastic scaling, all of a sudden whether we had enough computers physically on our campus to do something stopped being a limiting factor. It started being, okay, we can do that.

If we pay enough money, we can do anything. And that abundance really enabled the transformation to a cloud native accelerated rapid pace deployment and development system. Then we need enough autonomy. The thing that abundance gave us was the ability to do anything we wanted. And the curse that abundance gave us was the ability to do anything that we wanted.

And it turns out, if you give developers all of the scope in the world. They won’t all use it the same way, and they won’t all use it in the same direction. What we need is enough autonomy, enough independent action for our development teams to be able to feel internally rewarded, to feel like they’re creating something and to get something done.

Many of you have been on teams where you’re like, I would like to fix that, but I cannot fix that because I am not authorized to fix that. We want to fix that with more autonomy. So that’s another Tetris piece that’s dropping down to add to the capabilities of our system. Then we need enough alignment for direction.

Remember when I said that developers will do anything they want? I want them to have that feeling, but I also want them to point in more or less the same direction. It would be great if we used all of our autonomy to accomplish things together instead of squirreling around and doing a lot of independent projects.

And when we talk about alignment in the software development life cycle, frequently what we talk about is internal alignment. Are teams aligned with each other? Are they aligned with the platform? Are they aligned with the corporate vision? Progressive delivery is really challenging you to say, are you aligned with the user?

Do you know what the user experience is when they use your software? Do you know what it’s like to use your application in a low data environment? Do you know what it’s like to use your application on a tiny screen? These are things that we think of as accessibility, but if we think of aligning ourselves to the needs of our users, we’re always going to make better software.

Then automation. We need enough automation for ease and efficiency. We need to be able to say, this is a platform. Build on it. Pick the software that you want to make some, other software. We’re, not going to make it difficult. Like here, there’s some preset templates, some guardrails, some tests.

Go to town and you don’t have to do this re-creation work all the time. When we combine all of these four as abundance, autonomy, alignment, and automation, we get this transformative work where we can do things together in a way that gets the right thing to the right people at the right time.

We’re gonna iterate this over and over. When you’re playing Tetris, the blocks don’t stop falling. We’re always getting resources. We’re always getting demands. We have to keep saying, okay, we cleared that bar. We cleared that line. What’s the next thing that’s dropping? Shipping software is not the goal.

Shipping software is part of the process. The goal is delivering value to users, not just what they want, but what they need, what they’re going to use, what’s going to make their life more productive.

Kim Harrison: So this is progressive delivery. It is chat GPT, even in its imperfect state, giving people the ability to query large amounts of information with natural language. It is the ability to do things in a low code or no code environment. The ability to vibe code. It’s offloading work you don’t want to do using a platform that’s helpful managing processes that you don’t want to be distracted by so that your team can focus on providing value.

for myself, I’m more on the marketing side. This is something like Grammarly or language programs that automatically give me captions, or notes from meetings that I’m in. So how did we get to progressive delivery? In the beginning there was waterfall. I think some people here might remember that time.

yeah, some people still remember that going from waterfall to Agile was possible because of abundance. suddenly we had the cloud. This meant that instead of delivering products on physical media once a year or every few years, we could provide updates directly to our users more frequently, such as quarterly.

Then we had Agile moving from Oh yeah. So moving from Agile to continuous delivery, was about developer autonomy and the rise of DevOps. We did a great job of improving development pipelines, to the point where continuous delivery became the new normal. Now, in whatever moment this is, we’re asking you to bring that focus back to the user.

Consider the most recent tools that have become available, how you can take all of this focus and align so that you can better prioritize actually delivering value to your users.

So the right thing lets your users do their work, the right people are the actual users. That’s where the rubber meets the road. And the right time is the moment that it’s useful, not too soon and not too late. So we’ve talked about progressive delivery as a theory, but what does that look like in practice?

How do you actually do it and how do you know that you’re doing it well?

Adam Zimman: And so go for, there we go. And. So for progressive delivery to actually be used, it ends up looking a lot like continuous delivery. Okay. This is something where, this is an iteration, above and beyond what we’ve been talking about for the past decade, right? Continuous delivery was all about smoothing out that pipeline from build to deploy to release.

Now one of the things that we are talking about with progressive delivery, that is a, the two core concepts that we wanna make sure that people are starting to adopt because it has such a significant impact on the way in which you’re not only building, but the way in which you’re publishing and releasing software is progressive rollout, right?

This is simple things. This is feature management, feature flags. This is observability. This is all the things that you want on that kind of, standard DevOps, infinity loop, right? Everything that takes you from the building of the code all the way through to the release to the users.

But start to think about it in the context of this, progressive approach that allows you to expose your code to the right people at the right time. If you think about this, in the context of individual users of a B2C type organization. This could be something where you’re actually going out to a set of beta users, first or early adopters, exposing them to a new feature, getting some feedback.

Then you’re gradually rolling it out to your power users. Then you’re finally rolling it out to your entirety of your, user base in a B2B context. Similarly, if you’re actually a B2B business, this is something where you should be thinking about which customers, which actual, companies are going to benefit from your features first.

Now the advantage in the B2B context is you may also put this behind some type of pricing and packaging, right? And have that actually be a part of how you’re actually bringing that to market. But you wanna still be mindful of how do I make sure that I have those controls in place, these control points in my code, to be able to choose who I expose these features to and when?

How do I know that they’re ready? How do I make sure that I don’t just roll something out to 100% of my audience and have 50% hate it and 50% love it, right? How do I expose it to the people who love it and make sure that they are as satisfied and, feel comfortable with it and either never expose it to the people who don’t want it, or do so over time when they’re actually ready for that change.

And part of this, knowing when is the right time is the second core tenant of progressive delivery, and that’s what we refer to as radical delegation. So radical delegation is a concept, from the Navy. That, or that’s where I first heard about it. This is something that was first, brought about as a terminology that was used when you are referring to orders given to a captain on ship, right?

If you are unable to communicate between the captain and the shore or multiple captains that are headed towards a similar objective that are apart by an ocean, right? There needs to be the ability for the captain to make the decisions that are most appropriate to meet the objectives that are set.

Similarly, with regards to how you are thinking about change and introducing change to your users, the best possible outcome is for you to be able to delegate that change as close to the user as possible. So in some cases, for a consumer product or B2C type organization, this is gonna be how do you provide the properties or settings page to your users to allow them to opt in to an experience.

Examples of this are, Google has Google Labs, right? Which was the ability for you to be able to basically turn on and off individual feature flags in products allowing you to see, functionality that was still in development prior to it being released to the general audience.

There are a lot of other examples of organizations that do this to be able to provide preview or have early access to new functionality. In the enterprise context oftentimes this may still be something that you actually are not exposing all the way down to the end user.

But something that you’re exposing at a company level, and maybe that’s being managed instead of by an engineer, it’s being managed by a customer success representative or a sales person who is actually closest to the account. You’re giving them the ability and the functionality to be able to turn on and off features, whether that’s because of a pricing and packaging decision, or whether that’s because of a new UI that you’re rolling out and you know that there’s actually a requirement of one of your regulated industry clients that says, Hey, wait, you actually need to give us time to be able to do training before you roll out a new UI across our company. These are all real world examples that we’ve seen in the course of our research for this book, where we really wanted to make sure that people understood these ideas.

And so being able to, articulate these as the two core tenets that make this the next iteration from continuous delivery tends to be really helpful for folks. Another way to think about this.

Heidi Waterhouse: Is to look at what we think of as the DevOps cycle. This is not the DevOps cycle, obviously, because there are three loops.

What we want to do is add the user into our understanding of how the DevOps loop works. So building the right thing, that’s, your software creation and your testing and all of the things that go into making software. And the next loop is the ops loop, the deployment, the maintenance, the uptime, the resiliency, the observability, all of that goes into the second loop.

None of this is new to you. The third loop we put sparkles on because it’s about the user. The user is the person who decides how they feel about software. They decide if it is useful to them or if it is something that is annoying, that is bloatware, that is yet another AI feature shoved down their throat when they don’t want it.

The user is an essential part of the software development lifecycle, and we’ve been ignoring them for all of these years. The way that progressive delivery is reaching out to pull users in is not just surveys like, who here, flew here and then got a thing from your airline about how your service was, which you promptly ignored, right?

I’m not answering that. I got here. I don’t care. we don’t, we can’t just rely on surveys. That’s, it’s very lossy data. It’s very, like any statistician will tell you why they’re so broken. We have all of these cool tools that we could be using to look at how people feel about our software. Do they click the link?

Do they dwell on the page? Do they download the app? Do they talk about the app? Do they do anything besides click X to close it? I want to know, and I have the ability to tell how people are using my app. And so if we instrument properly, we’re going to get observability, not just from our systems that are computers, we own, but from our systems that are the sociotechnical systems that encompass the entire working life of our software, and if we do that properly, we are going to make so much better software because we’re not going to be imposing it on someone.

A lot of media critics talk about how important it is to understand that once a film is released it is not just an artifact. It is an artifact. You can frequently buy a physical disc with a film, but it’s also a conversation with the viewer. People bring their own understanding of what’s happening in a film, their own background, their own context. If I watch Sinners, it’s a different thing than if you watch Sinners because you are bringing a different context.

We want to have that kind of relationship with the people who are consuming our content. We want to say, we care about your context. We care about what you’re doing. We care about what industry you’re in. Because if we’re not doing that, what the hell are we doing here? Okay, we sold some software and what does that mean?

So we really want. Progressive delivery to be about using all of these tools to bring the user into our software development lifecycle and to consider them co-creators and partners of our work.

So we’re doing a book signing tomorrow night. We are so excited about this book. We, fought about the name and the cover and the justification and the kerning. We fought very little about the content. We, all pretty much agreed that the stuff that we put in there is the stuff we want to say to you.

We want to say, here’s how we think you can do it. We want to hear your stories about how you’re doing progressive delivery, because I assure you. All of you have a progressive delivery story.

Kim was talking about how her hotel room has well labeled light switches. And I was thinking about the first time that I came to Vegas. I stayed at the Cosmopolitan and the hotel room freaked me out. Like I walk in the hotel room and the curtains flew open and the TV turned on and all the lights came up. And I’m like, what happened? And then Kim said. A

Kim Harrison: few years later, I arrived at the Cosmopolitan. The nothing was on, the curtains were closed, the lights were off.

Could not figure out how to turn the lamps on. I had the opposite experience.

Heidi Waterhouse: Neither of these was a great experience. Neither of them was what we wanted. But yesterday when we checked into our hotel room, the hotel room politely greeted us. The curtains were already open so we could see the beautiful view and all of the switches were labeled that we can tell how to turn them on and off from different points in the room. This is a story about progressive delivery. They got angry calls when the room was too dark and nobody could see it, and they probably got a little bit of Yelp whining when somebody was like, my hotel room was like a very excitable puppy.

This is information that they took in and made physical changes to better reflect user needs. All sorts of progressive delivery examples exist everywhere around you. Vaccines like the mRNA vaccine story, it was going for a long time, but we did a lot of progressive delivery to get it here really fast.

Even things like supply chains are affected by progressive delivery and an understanding of how the user affects the whole life cycle.

So we are hoping that you come to our book signing tomorrow, and we want you to come to Adam’s talk

Adam Zimman: with Brian Scott from Adobe. one of the case studies from our book will be, Brian, and I’ll be doing another kind of deep dive on progressive delivery and its impact on, Adobe’s adoption of AI, on Thursday.

Hope to have many of you come by that. Also we’d encourage you to read the book and if you like it as Corey Quinn says, leave a five star review, on your reviewer of choice. If you don’t like it, just leave a five star review on your, review site of choice.

Heidi Waterhouse: That’s not very, good feedback though.

I. I’ll take it, you’ll take it.

Adam Zimman: If you got issues, we want to hear about ’em. Absolutely. just not on the review sites. No. anyways, we also have a podcast, coming out. So if you’re interested in learning more about that, you can find us at progressivedelivery.com as well as on Blue Sky, at progressivedelivery.com.

And, feel free to come up to us and ask us any questions. and we are out of time. Happy to, take questions off stage. If you have trouble finding me, better glasses. Yeah. But thank you very much.

Heidi Waterhouse: Thank you all.

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.