Progressive Delivery with Heidi Waterhouse

In this episode of the DevOps Sauna, Darren Richardson and Pinja Kujala are joined by Heidi Waterhouse (Transformation Advocate and Marketing Advisor) to discuss her upcoming book, Progressive Delivery.

[Heidi] (0:03 - 0:10)

So, we need to consider our whole community of creators and not just the cool techie people.

[Darren] (0:14 - 0:22)

Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development.

[Pinja] (0:22 - 0:32)

Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

[Darren] (0:37 - 0:50)

Welcome back to the DevOps Sauna. Today, we have a special guest. We're here with Heidi Waterhouse, a Transformation Advocate, Marketing Advisor, and Co-author of a book coming out at the end of the year called Progressive Delivery.

Thanks for joining us, Heidi.

[Heidi] (0:50 - 00:52)

It's good to be here.

[Darren] (0:52 - 0:54)

Of course, I'm also here with my regular co-host, Pinja.

[Pinja] (0:55 - 0:57)

Hi, all. Welcome, Heidi. It's good to have you here.

[Heidi] (0:56 - 0:57)

It's great to be here. 

[Darren] (0:57 - 1:08)

Now, this is a term I don't think most of our listeners will have heard of yet. Let's just take those two words: Progressive Delivery.

What are we talking about here?

[Heidi] (1:09 - 1:53)

We are talking about delivery that builds on all the things that have come before it, builds on DevOps, it builds on CI/CD, but it incorporates the user and optionality in a way that we haven't really been talking about before. We've spent 30 years getting better at building and delivering software, and we now need to spend some time thinking about how people accept and integrate that software into their lives. And the way we do that is by giving our developers better ways to do delivery that's more progressive, that's more integrated, that has feature flags, that has ring deployment, that has optionality in a bunch of ways so that people can adapt to the changes in their software better.

[Darren] (1:54 - 2:01)

So this raises the question that I think everyone will be asking, is that how does progressive delivery differ from the concept of DevOps?

[Pinja] (2:02 - 2:20)

If I may add to that also, the main idea of DevOps, if we think about the very core of it, is breaking down the silos and trying to minimize the friction of it, right? So if we build a little bit of that, what is the logical conclusion about this? So moving a little bit further from that main core idea.

[Heidi] (2:20 - 2:41)

I think that's actually a thing that we say in the book is like, DevOps broke down the wall between Dev and Ops. It matters how you build something because it changes how you run it. It matters how you build and run something because it changes how you use it, how you accept it, how you integrate it into your world.

So, we want to break down that barrier between the software creator and the software user.

[Pinja] (2:42 - 3:11)

Because there is what is really close to my heart, always has been, is how do we take into account the user needs? How do we communicate that to our developers? And what is the flow from the idea to the actual final product?

How do we get our developers to not only care but take that in and build the best possible product so that the user, whoever is the final end user of the product or service, might be a SaaS product, whatever it is, actually can get the best value out of it.

[Heidi] (3:11 - 3:41)

Exactly. And I think that's the thing that we started trying to do with Agile. Actually, we started trying to do it with specification delivery, with Waterfall, really.

It's like, these specifications are going to help us build something that people want. It's so hard to do the right thing for all the users because we aren't all the users. We are a very small subset of somebody who might be kind of like the users.

But a lot of us are building software for jobs that we never do. And so it's very hard for us to know how it actually gets used.

[Darren] (3:41 - 4:06)

I think that's kind of right on the money there. Even back at the start of my career when I was a coder, I don't think I was ever using any of the platforms that I was responsible for contributing code to. And I now kind of wonder how common that is, that you have developers who are not users, who are not really tied into that requirement for a feedback loop of understanding user requirements.

[Heidi] (4:06 - 4:16)

And it's so easy for us to slip into the mode of, as a user, I want to database that. Like, no, you don't. As a user, you just want your pictures, dang it.

[Pinja] (4:16 - 4:38)

No, and that is one of the things that we see quite a lot with the companies that we encounter, that somebody, the usual somebody, the famous somebody in the company says that we think that the user wants this. And as you say, Heidi, no, that is usually not what they want. They do not want a database.

What is the job to be done that they actually need, right?

[Heidi] (4:38 - 5:15)

Yeah. So we're hoping that progressive delivery gives us another way to approach that and say, we can't know all the ways our software gets used. The best thing that we can do is actually watch how it gets used.

We now have all of the telemetry that we need to know if we paid attention to it. You can see what features people use. Google knows that this morning I went in and turned off all of the Gemini stuff that popped up.

I'm like, no, thank you. Go away. And, you know, maybe I'm 1%, but they need to leave the option to turn it off for 1% because 1% of Google is a lot of users.

[Pinja] (5:16 - 5:49)

That is true. And I've seen some statistics of how big of a portion of whatever service’s features are being used and by how many people. For example, there's a portion of features that get used on a daily basis by, it might be a professional, it might be a consumer, but it is a staggeringly low portion, small portion of those features.

And there is this huge stack of features that never get used, actually. And the companies might not actually even realize this. And they keep on building that and keeping up with the software evolution there.

[Heidi] (5:50 - 6:15)

Right. And now that we have the ability to see how people are using it, we need to consider that actual meaningful data and use that as a feedback loop into our software planning, our product planning, and say like, hey, is anybody actually using this feature? And if not, is it because we're not socializing it properly, or it's difficult to use, or it's something that we don't want, like something that the user doesn't find relevant?

[Darren] (6:16 - 6:27)

So it's kind of safe to say that one of the outputs of this progressive delivery method is maybe a remedy to the all-too-familiar developer-knows-best mentality, where a developer is developing features for no one.

[Heidi] (6:27 - 7:04)

Well, almost always they're developing them for themselves. This is a projection. I would like it to do this.

I would like these things. But yeah, and I think this is a constant tension. I don't like to even think of it as a battle.

It's just a constant tension between experts in making software and experts in doing the job that software facilitates. Like there are a lot of people working in, say, medical records software. And there are a lot of people who use medical records software, but there's very little overlap between those two groups.

Very few software developers can sit in an exam room with a doctor and watch them try and use it.

[Darren] (7:04 - 7:20)

That is kind of a great point. Now, on the subject of the book, Progressive Delivery, that's coming out, you sent the first couple of chapters to Pinja and I, and we had time to peruse it. And I think one of the things, Pinja, that caught your attention was these four pillars.

[Pinja] (7:21 - 7:31)

Yeah, the four A's. So, Heidi, we would like to know a little bit more about the four A's and how they build the Progressive Delivery. Could you lighten us on that, please?

[Heidi] (7:31 - 9:03)

Right. So, Progressive Delivery is a new way to describe something that's been going on for several years. We've been writing this book for about four years.

We started to see it before that. The things that make Progressive Delivery possible are abundance, autonomy, alignment, and automation. It's hard to do Progressive Delivery if you don't have the computing resources and the scale to make it possible.

It's hard to do Progressive Delivery if your developers don't have the autonomy to work on things that are meaningful in a sort of a rapid response kind of way. And your users need the autonomy to accept or reject features. It's really hard to do Progressive Delivery if you don't have alignment on what you're making.

And alignment and autonomy really work together in an interesting way, because you need to understand what the goal is. And you also need to support a bunch of different things that come together in the goal and reject things that don't. I think one of the hardest things for us to do is say, no, we're not doing that.

No, we're not making that. This is not on the roadmap. And finally, automation is what frees us up to go work on more interesting problems.

Automation is what we do to reduce toil so that we can go work on better things. Because once we figure out how to do something, we don't need to keep doing it ourselves. This is what we have computers for.

[Pinja] (9:04 - 9:49)

I think you hit the right spot there with the four A's. This is always nice to see, let's say categorizations and pillars are always a nice way of putting things. And as you say, this is the kind of equation, how to build it.

And you put together autonomy and alignment in a really nice way. And that's what we've seen as well. When we bring together multiple teams, they need alignment so that they can get into their shared goal.

There needs to be a North Star. There needs to be a strategy. There needs to be somebody, something guiding them.

But then again, so that teams do not lose the feeling of autonomy at the same time, so that they have this balance of, yes, we want you to work towards the same goal, but you have the right to say if this is the right thing from your perspective or not.

[Darren] (9:50 - 10:14)

And that's actually something I'm looking forward to when the book actually comes out because I personally don't know how to go about balancing autonomy and alignment. To me, those are the kind of things that the more autonomous a team tends to be, the less aligned they're going to be with everyone else. And the more they'll be wandering off in their own direction and you'll find them disconnected from the rest of the group working on some feature that no one asked for.

[Heidi] (10:15 - 10:29)

Yes. None of these are absolute solutions. There's always going to be tension.

But I do think that we need to say it's very hard to accomplish progressive delivery if you don't have some work for each of these.

[Pinja] (10:29 - 10:54)

And I guess it also needs the right timing. It needs to be the right consequence. It needs to be the right concept.

It needs to be the right timing for everything. So how do we work on this when the technology landscape is changing so much and is even increasing all the time, right? So much has happened during the past couple of years.

We do not even know what's happening in the next couple of years. How does that play into that?

[Heidi] (10:54 - 12:58)

So one of the interesting things that we have discovered as we've been writing this is the concept of jerk. So we know what movement is, like, you know, you're going at a steady rate. Okay, so you're on a train.

And we know what acceleration is. When you take off from a station, and you get that little push back into your seat, that's acceleration. The next order after that is acceleration faster is a jerk.

There's a physics term for it. One of our co-authors is a physicist, and he explains it better than I do. But that moment when the train lurches, when there's a disconcerting movement.

And that's what technology feels like to a lot of us, especially if we aren't in the flow. So when we're building software, when we're working on a platform, we're in the flow. Like it doesn't surprise us that we work on Kubernetes, and there's a new Kubernetes release.

Okay, fine, whatever. It is disconcerting when something happens to technology that you don't use all the time. When you get a new car, it's different to adjust all the windows, and the radio is not set right.

That's a jerk. That's a disconcerting moment. And what we need to realize as software makers is that users are experiencing jerk with our software in a way that we are not because we're in it all the time.

And they may only open it in the US, it's tax season. And I open my tax software once every three months, if I'm doing well, and once a year if I'm not. And it's changed.

And it wants me to log in again. And I've forgotten my login because it's been so long. It doesn't feel like that to the people making the software.

So when we're talking about how to deal with time alignment, we need to remember that abrupt changes are harder to accept than slow changes, but we don't know how often people see our stuff. So it may have been a gradual movement over a year that my tax software did all these changes, but I wouldn't know because I only see it every year. Does that answer the question?

[Darren] (12:59 - 13:31)

It does. It brings up this idea we're talking about, I mean, obviously, with the adoption of AI, we're talking about the rate of change a lot because it seems you blink, and there are seven new systems out, all of which are twice as advanced as the old ones. So it starts to look like the rate of change.

Is that something we can really consider as valid metrics? Or are we kind of aiming towards this ratio of stasis instead of the idea of trying to keep things as close to normal as we can while still innovating?

[Heidi] (13:31 - 14:54)

I think that depends on your user. I think that depends on the tolerance of your user. They made me take this word out of the book.

There are neophilic users. There are people who love to get a new smartphone once a year. And there are neophobic users, people who are like, I wish I still had a flip phone, and I only update it when my phone ceases to charge.

And both of those users need to be accommodated. So we need to say, do you want to be in the beta? Do you want to see the new features?

Because there are people who are like, I want to see all the new stuff. I want all of the features. I want to see it all.

And there are people who are like, show me the old way to do it. I just reinstalled my laptop and there's a program I use called OpenShell, which takes Windows 11 and gives it a menu kind of like Windows 7 because I find that more compatible with how I work. And so I need that backward compatibility because I don't want to search my programs.

I don't want to search my whole computer when I want a program. That's not how I work. And so we need to offer people the option to do things the way they used to and the option to sort of gradually get back up to speed with the current state of progress.

So when we think about this, I think we need to really rely on that information we're getting back from users about who they are and how often they want to change and how they feel about it.

[Darren] (14:54 - 15:09)

And that aligns with the ideas of, you know, canary releases, A-B testing, this kind of like this progressive release where you're not just maybe pulling a crowd strike and dropping your entire update on everyone in the world all at once.

[Heidi] (15:09 - 15:17)

Yes, exactly. And like that's an interesting problem because it is dangerous to do canary releases for security updates.

[Darren] (15:18 - 15:18)

Absolutely.

[Heidi] (15:18 - 16:36)

Because if you have a bad actor in your canary, then they get the information before everybody else and can roll out a counter. So I understand why they did that. What I don't understand is why they didn't test their foundational updates better.

Like, it wasn't that they rolled out the updates that was the problem. It was that they didn't understand their underlying update technology. Anyway, that's the whole thing.

But I do think that when we say progressive delivery, we are thinking about the things that Google, that Facebook, that Microsoft have been doing for years, which is to say we test it on the team internally that created it. We test it on a portion of the enterprise. We test it in our whole enterprise.

We test it for a set of beta users outside the enterprise. We test it for a broader set outside the enterprise before we roll out to 100%. And there's a bunch of metrics.

When I talked to Microsoft about this, they said they don't consider a feature done until it is done and in production. And I said, well, what do you mean by in production? Like done is right?

And they're like, no, we need to be receiving tests. We need to be receiving responses for it to be done from users from the outside world. And I'm like, oh, that's really interesting.

It's not done until it's operating.

[Pinja] (16:36 - 16:51)

So that's if we go back to the very basic concepts of agility, right? The definition of done, right? It shouldn't be a long list of a wish list of things.

But that is a huge thing that I don't think I've seen in many places, to be honest, in smaller companies.

[Heidi] (16:52 - 17:16)

Yeah. And we certainly have the technology to do that. I worked at LaunchDarkly for years.

They have the ability to do that. You can do it with Azure DevOps. You can do it.

I think there's a couple AWS tools that can do it. That progressive rollout is a key part of making sure that you're not making a massive mistake. And it gives you a lot of time to say, oh, wait, wait, this is not right.

And we can fix it before we embarrass ourselves.

[Darren] (17:16 - 18:14)

There's a curious idea along this line, too, that you're talking about large companies who are doing this and have been doing this for years. And it also leads to a kind of mindset idea of is it because the developers can engage with something they believe in over engaging with something for the sake of being paid. Like we have if we think back to, you know, 2015 before all of these social media companies had gone full evil, then we have like people being excited about platforms that they're building, people being excited about the tooling so that they can put this kind of effort, this extra into their work and want to be the user, want to be part of the stream.

Because, for example, I in the past worked with marine navigation systems. And it's like, well, I can't really be part of the user base there because I don't own an enormous ship, a cargo ship.

[Heidi] (18:14 - 18:14)

Yeah.

[Darren] (18:14 - 18:20)

So it's like it makes me wonder if there are people who are just able to put more in when they believe in the mission.

[Heidi] (18:21 - 19:10)

I think it certainly helps. But I also think that there's something to be said for professionalism, that whether or not you believe in the whole product, you can believe in doing a good and responsible job. You can believe in being an engineer in the US.

We refer to a lot of software creators as engineers. And I was surprised to find out that they don't in Canada because in Canada, engineering is a professional class like a lawyer is or like a doctor is. And you have professional obligations in a way that we don't usually enforce on software creators.

And I think that's a really interesting concept. Why isn't a software creator a professional class with obligations, with a community expectation of right behavior and right creation?

[Pinja] (19:10 - 19:59)

That's a very, very interesting point you're bringing up there, Heidi. And I really want to go back to what you said about the professionalism, being proud of what you do, regardless if you're a user of a huge marine, huge ship, for example, like in Darren's example here, but having pride in what you do, and believing in that you're doing a good job. I think sometimes, unfortunately, we still see with some companies, we see that the developers, the software engineers are not given the benefit of the doubt, for example, that they actually want to do a good job here.

But I think we're with Developer Experience, with developer joy, with developer advocates, we're getting more and more of that angle being played out and being taken into consideration.

[Heidi] (19:59 - 20:50)

Exactly. And I think that as we consider ourselves professionals and have, you know, build codes of ethics for ourselves, I'm not going to say it doesn't matter what we build, it matters what we build. But a lot of us work on projects that are just not exciting. We've been calling them flyover devs.

Like there are more developers working for Capital One than there are for almost any tech company out there. And we don't think of them as tech people the same way because, I don't know, they're not working in Silicon Valley. They totally are, they're totally doing the same work, they're confronting the same kind of problems, the same kind of scale, possibly at higher stakes than many people who are making, you know, bug tracking software.

And so we need to consider our whole community of creators, and not just like the cool techie people.

[Darren] (20:50 - 21:11)

I totally agree. It kind of sounds like, it's just this kind of feedback loop. You have Developer Experience on one side, a better Developer Experience allows for more professionalism to allow for better user experience to allow for faster feedback to allow for development rapidly, which increases Developer Experience.

It's like this positive feedback loop going between the two.

[Heidi] (21:11 - 21:26)

We are hoping, we think that there can be positive and generative feedback loops that are not like aversive training, not like, well, something happened and you all got fired, but rather, hey, this is the better way to do it. We will reward you for doing it the better way.

[Pinja] (21:27 - 22:22)

If we go back a little bit, we talked about developer autonomy, we talked about user adoption. And in the book, you and your co-authors, you're introducing these two axes for developer autonomy and this high versus low alignment with user adoption. And you have placed some familiar, previously familiar concepts here.

Agile being one, we are, everybody's favorite waterfall is in one of the quadrants and continuous delivery. And then with high developer autonomy and high alignment with the user adoption, there is progressive delivery. And previously mentioned in this conversation, you mentioned that everything is now with progressive delivery.

It builds up on the previously known practices and the previously adopted practices. How do you see the relationship now between, for example, Agility and continuous delivery and previously adopted and very well-known practices that we have in this industry?

[Heidi] (22:22 - 25:29)

Right. We didn't get where we are out of nowhere. We are not creating the software development lifecycle out of nothing.

This has been going on for decades, and we need to acknowledge where we come from in order to understand what we're trying to make better. So, the place that I chose to start this was specification-driven delivery, which we call waterfall. We figure out what we want to build, and then we build it, and then it slips.

But this is how we got to space. Specification delivery is how we put a man on the moon. So it works.

It works fine. It just doesn't meet all our needs. So when we got the Agile manifesto, it was this really interesting revolution in, hey, maybe we need to think more about the tasks rather than like the software as a whole and how it is that people experience the tasks.

And that was really interesting, but it missed a lot of things that needed to be considered. Like I've worked in pure Agile companies and keeping their software running as a platform is a nightmare because it's not architected to be easy to maintain. It meets the standards on a little card and the back end is a mess and it's always on the verge of falling down.

And so we added the consideration of operating it. Like let's add how we're going to do this, how we're going to deliver it and get DevOps. And so now people making the software and people keeping the software running actually communicated to each other.

We used to say, you know, you can't just throw it over the wall. OK, so this is good. This is good.

We're getting there. But it turns out that even if those two teams are talking to each other, even if they're the same person, which is, by the way, a ridiculous expectation, like there's no way a person can be an expert in the full stack. That's not a thing anymore.

But even then, we're still doing a lot of things sort of manually. We're doing a lot of things in a painful way. We're not really thinking about how it releases and runs after we get it out.

So that gave us CI/CD. We automated a lot of the painful things. We automated a lot of testing.

We automated a lot of integration. We're like, OK, look, we're coders. We can figure this out.

Let's do CI/CD so that when you commit a story, it goes through a process to be tested, to get integrated, to not have a fight about merge conflicts. Like this is all immensely useful to reduce the time to delivering value and reduce the toil. So that got us to CI/CD.

But what we haven't done is done delegation. We haven't done how the users feel about this. And so progressive delivery takes all of the things that came before sort of like a pearl and builds another layer on it and gives us a lens in sort of a literary criticism sense to look at, are we delivering valuable things and are we understanding what we're delivering?

And does that come back and affect how we build?

[Pinja] (25:30 - 26:05)

I think that's a very interesting take on this. And if we think of, for example, I take the Agile Manifesto as an example. It came from Lean, for example.

So even that was built on many other things, right? So I found it, first of all, as somebody who started in this industry as an Agilist, seeing the claim that, yes, Agile has low developer autonomy, but I think this explains it very well. What you just mentioned here, like, what did we add after that?

So I think that makes a lot of sense with having those axes, the autonomy for developers and the user adoption alignment. Yeah.

[Heidi] (26:05 - 26:31)

And I don't want to say that any of these methods was bad, that they got us here and we needed them. And you're right, going back like Lean was built on industrial automation, which was built on the work of Gilbreths and Frederick Winslow Taylor, which was built on the Ford model, which it goes back to like Eli Whitney and interchangeable rifle parts.

[Pinja] (26:31 - 26:31)

Exactly.

[Heidi] (26:31 - 26:54)

Our history of technology just keeps going. And so I think that it's really exciting for us to say, like, we're not done, we'll never be done. One of the titles for this book that I proposed was Never Finished.

Like software is never finished. It's always being used, and the state of being used changes it and hopefully changes how the software works.

[Pinja] (26:54 - 27:23)

And I'm thinking about the adoption again. It never stops changing, it's never finished. And then, well, keeping in mind who is actually the user here and how do we avoid their heads doing the jerk as the train starts moving so that nobody's necks get the whiplash effect from jerking too hard.

So I think that it is very hard to find something that I would disagree with, we are always in movement. And as we say, it's just accelerating right now.

[Heidi] (27:23 - 27:36)

I just think it's exciting. I think it's exciting that we can look at software and say, software is not a fixed point. Software is a shared experience.

It is a thing that can only be seen in motion.

[Darren] (27:36 - 27:51)

I think that's a great summary of basically the whole industry. So, let's take a moment to talk about the actual book. This sounds extremely interesting.

I'm sure a lot of our listeners are going to be interested in reading this. It's coming out in autumn, I believe.

[Heidi] (27:51 - 28:05)

Yep, we are working on our final edits now. So it will be out in autumn from IT Revolution, and you can pre-order it now. I believe it is available from IT Revolution and from, you know, booksellers near you for pre-order.

[Pinja] (28:06 - 28:12)

And you're working on this together with James Governor, Kim Harrison, and Adam Zeman, is that correct?

[Heidi] (28:13 - 28:44)

That is correct. And it's an interesting group because three of us work together at LaunchDarkly, but James and Adam had been working on the progressive delivery concept before that. And Kim and I have been working on getting people to understand how it affects the way that they make software.

It's just, it's been a delight to work with this group, honestly. We do need people to stop giving us examples. Like, I'll open the news, I'll be like, oh, that's progressive delivery.

Oh, that's progressive delivery. I see. Yeah.

[Pinja] (28:44 - 28:49)

That's nice. We're really looking forward to the book, actually, the full book coming out in Autumn 2025.

[Darren] (28:50 - 28:56)

Yep, definitely looking forward to that release date. But I think that's all we have time for. So, thank you, Heidi, for joining us.

[Pinja] (28:56 - 28:57)

Thank you so much. Thank you.

[Darren] (28:58 - 29:00)

And thank you, Pinja, for joining us as well.

[Pinja] (29:00 - 29:01)

Thank you, Darren, as well.

[Darren] (29:01 - 29:13)

And we'll talk to you next time. Hope you join us in the sauna. We'll now give our guest a chance to introduce herself and tell you a little bit about who we are.

[Heidi] (29:13 - 29:29)

I'm Heidi Waterhouse. I work telling stories and making marketing happen for things all around the DevOps, CI/CD, and progressive delivery world. And I'm super interested in how things work together so that we can work together better.

[Pinja] (29:30 - 29:35)

I'm Pinja Kujala. I specialize in Agile and portfolio management topics at Eficode.

[Darren] (29:35 - 29:38)

I'm Darren Richardson, Security Consultant at Eficode.

[Pinja] (29:38 - 29:40)

Thanks for tuning in. We'll catch you next time.

[Darren] (29:40 - 29:46)

And remember, if you like what you hear, please like, rate, and subscribe on your favorite podcast platform. It means the world to us.