One of the interesting problems of being immersed in something for years is that it feels really obvious to you. The curse of knowledge is real.

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.