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.

There we go. 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. Myself, I'm Adam Zimman. It's a pleasure to be here with you today.

Kimberly Harrison

I'm Kimberly Harrison.

Heidi Waterhouse

And I'm Heidi Waterhouse.

Adam Zimman

And our fourth author is James Governor. 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.

Kimberly Harrison

Everyone loves it when their device does a new thing.

Adam Zimman

Exactly. I completely concur. Everyone loves change all the time.

Heidi Waterhouse

All the time, every day.

Adam Zimman

And so 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 lifecycle. Who's been to one of those talks?

Heidi Waterhouse

Maybe one.

Kimberly Harrison

One.

Adam Zimman

Yeah, it seemed like a good idea at the time, didn't it?

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. Change is hard for all of us. 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. A good change for me may not be a great change for you. It's really hard to know who fits into which category, which segment of your user base.

One of the things that you need to understand is that there's this concept in physics. My background is in physics. There's this concept that I feel captures this perfectly. It's called jerk. We wanted to name the book Jerk, but we decided to be nice. We were told by our publishers, thank you, IT Revolution, 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 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 that jerk is actually the third derivative of position. For those of you who 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. If acceleration is your change in velocity, you're starting to move faster. Jerk is that next iteration, that next degree that you're talking about. 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. It's a physical feeling.

What we started to notice is that this was very similar to how people were describing and reacting to changes in their software. This was something that we wanted to get people who are building software to start to think more about and more directly about, because we believe that as builders, we need to be better at understanding this concept of jerk in the context of our users so that we can provide a better experience that will actually accelerate adoption of the things that we're building.

When AI started to become the thing that everyone was realizing, wait, this is a game changer, we were in the middle of writing this book. We thought we should probably make sure that we're incorporating something around AI. As we started to have 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.

I remember Nathan gave a talk last year on some changes in the DORA report and how they were thinking about AI, and they were just like, oh, wait, same thing. This is just validating all of the data that we've been collecting for years. We're starting to see how AI is once again making it even easier for people to ship more product, 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.

One of the things that we talk a lot about in the book is this notion of how 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?

Heidi Waterhouse

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 consumers. We grouped these into four A's, 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 we would reorder them if we were writing the book again, and maybe not. Maybe we got it right the first time.

The first one is accepting the changes that come into our teams as they come. 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.

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. 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. The curse that abundance gave us was the ability to do anything that we wanted. 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. 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 sort of squirreling around and doing a lot of independent projects.

When we talk about alignment in the software development lifecycle, 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 experiences 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.

And 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. Here are some preset templates, some guardrails, some tests. Go to town, and you don't have to do this recreation work all the time.

When we combine all of these four A's, 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 going to 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.

This is progressive delivery. It is ChatGPT, 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.

How did we get to progressive delivery? In the beginning there was waterfall. I think some people here might remember that time. 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.

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.

The right thing: let your users do their work. The right people are the actual users. That's where the rubber meets the road. The right time is the moment that it's useful, not too soon and not too late.

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

There we go. For progressive delivery to actually be used, it ends up looking a lot like continuous delivery. This is an iteration above and beyond what we've been talking about for the past decade. Continuous delivery was all about smoothing out that pipeline from build to deploy to release.

One of the things that we are talking about with progressive delivery, the two core concepts that we want to make sure 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. This is simple things. This is feature management, feature flags, observability. This is all the things that you want on that standard DevOps infinity loop, 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 going out to a set of beta users first or early adopters, exposing them to a new feature, getting some feedback, then gradually rolling it out to your power users, then finally rolling it out to the entirety of your user base.

In a B2B context, you should be thinking about which customers, which actual companies, are going to benefit from your features first. The advantage in the B2B context is you may also put this behind some type of pricing and packaging and have that be part of how you're bringing that to market. But you want to still be mindful of making sure that you have those controls in place, these control points in your code, to choose who you 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? How do I expose it to the people who love it and make sure that they are 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?

Part of knowing when is the right time is the second core tenet of progressive delivery, and that's what we refer to as radical delegation. Radical delegation is a concept from the Navy, 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 a ship. 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, 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. In some cases, for a consumer product or B2C organization, this is how you provide the properties or settings page to your users to allow them to opt in to an experience. Examples of this are Google Labs, which was the ability to 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 provide preview or early access to new functionality. In the enterprise context, oftentimes this may still be something that you 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 salesperson who is actually closest to the account. You're giving them the ability and the functionality to turn on and off features, whether that's because of a pricing and packaging decision or 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 wanted to make sure that people understood these ideas.

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.

Heidi Waterhouse

Another way to think about this 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.

Building the right thing, that's your software creation and your testing and all of the things that go into making software. 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've 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. Who here flew here and then got a thing from your airline about how your service was, which you promptly ignored? I'm not answering that. I got here. I don't care. We can't just rely on surveys. It's very lossy data. 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. 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. 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. I mean, 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?

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.

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 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. I walk in the hotel room and the curtains flew open and the TV turned on and all the lights came up. I'm like, what happened?

Kimberly Harrison

A few years later, I arrived at the Cosmopolitan. 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 so we could 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 lifecycle.

Adam Zimman

We are hoping that you come to our book signing tomorrow, and we want you to come to Adam's talk with Brian Scott from Adobe. One of the case studies from our book will be Brian, and I'll be doing another 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. 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.

Kimberly Harrison

That's not very good feedback though.

Adam Zimman

I'll take it.

Heidi Waterhouse

You'll take it.

Adam Zimman

If you've got issues, we want to hear about them.

Kimberly Harrison

Absolutely.

Heidi Waterhouse

Just not on the review sites.

Adam Zimman

We also have a podcast coming out. If you're interested in learning more about that, you can find us at progressivedelivery.com, as well as on Bluesky at progressive delivery dot com. Feel free to come up to us and ask us any questions. We are out of time, so happy to take questions offstage. If you have trouble finding me, wear better glasses. Thank you very much.

Heidi Waterhouse and Kimberly Harrison

Thank you all.