Progressive Delivery: Not Everything is an Experiment
Why are users different?
This is one of my favorite graphs. It is from a study by Blackrock Technologies on innovation. I find it useful in explaining the gap between digital natives and the digital cautious.
This graph shows an interesting trend for folks born before 1950. The key takeaway I see is that we measure adoption of technology in decades. The next inflection point is around 1990, from that point forward we measure adoption in months.
This adoption rate correlates to how comfortable folks are with new technologies, and the amount urgency to incorporate new things.
Trying to change this behavior is a losing proposition. Instead, we need to find ways to accommodate different rates of change.
I have a hypothesis that I’ve been working on since leaving VMware in 2014. I refer to this as the “Daughter : Mother-in-law challenge.”
I have a 12 year old daughter and a local mother-in-law. I love them both 💖 , and have the honor and privilege of serving as tech support for both of them.
Daughter
At one end of the spectrum is my daughter; a true digital native. You can hand her any technology and she will figure it out in 3.2 seconds. She’ll find all the advanced features and determine if it meets her needs. If it does not, she has no hesitation of tossing it aside and finding something new.
She is growing up in a world where the internet is always on. And whatever you need to do, “there’s an app for that.” She accepts constant change as a sign of a good application experience. She sees this as a sign of active development and is always excited for the newest features. You can change the UX out from under her, while she is in the middle of a workflow, and she’ll just continue on.
Bottom line: she values features over stability.
Mother-in-law
At the other end of the spectrum is my mother-in-law; for her technology is a tool. She is not a luddite — she has been a statistical programmer for almost 30 years, but she wants her software to be more like her hammer.
This hammer used to belong to her father. She keeps it in a drawer in her kitchen. Whenever she has a task that requires a hammer, she knows where to find it. It always looks the same, feels the same and works the same. It is static and unchanging.
If you so much as change the color of a button, you’ll destroy her productivity for a week. I’ll also get a support call.
Bottom line: she values consistency over new functionality.
Speed as a Habit
The digitally fluent want to be consuming the latest and greatest features as soon as they are ready. They tolerate change easily, and value new functionality over stability of experience.
The digitally cautious folks prefer their applications stay the same and never change. They fear change and value consistency and predictability over features.
There are also a bunch of folks between these two extremes.
In the next 5–7 years we are going to reach a tipping point. These two personas are going to be sitting in the same companies, on the same teams, asked to complete the same tasks. For application builders there will be the need to provide for both personas. Developers will need to deliver new features at different rates to different cohorts.
Continuous Delivery (CD) is an awesome model for my daughter’s persona. Constantly pushing innovation and gaining the benefits of added application or service stability. But, for my mother-in-law’s persona, this is a nightmare.
In the summer of 2018 I started talking with James Governor about this challenge. He suggested the term “Progressive Delivery” and I immediately agreed. The mental framing of progression fit better than the previous model of continuous.
Progressive Delivery
This is not saying that continuous delivery is bad or needs to be replaced with something entirely different and new. Instead, this is taking advantage of an industry best practice in software development… iteration. We are making some slight iterations to continuous delivery to make it a better model for more companies.
The two key concepts that we are highlighting in progressive delivery that really were not there in continuous delivery were:
- Release progression — progressively increasing the number of users that are able to see (and are impacted by) new features (e.g. Stage 1: visible to developers only; Stage 2: visible to developers and beta users; Stage 3: visible to more users; Stage n: visible to everyone)
- Delegation — progressively delegating the control of the feature to the owner that is most closely responsible for the outcome. (e.g. Stage 1: Release owner = dev. Stage 2: Release owner = PM; Stage 3: Release owner = Marketing; Stage n: Release owner = Customer Success)
Cadence of your users
Release progression was part of the continuous delivery lifecycle, it was discussed in the context of experimentation, smaller changes, A/B testing, etc. However, it was still with the focus on separating deployment and release. The Idea being that you would enable your developers to deploy whenever they wanted. Then you would be able to release to your users when the code or feature was ready. With progressive delivery there is a minor change; we still want developers to deploy whenever they want. But we want to think of release as more granular and controllable.
Just like my daughter and Nana have the desire for different change rates to their applications, companies need the flexibility to control the cadence and the cohorts that are exposed to new features and code. This requires progressively releasing to users that are ready for your changes. Another great byproduct of this is the elimination of risk associated with software delivery by testing changes in production (or TIP).
Who makes the change?
Delegation is something that’s really interesting when you start to think about the other changes that are occurring in our workplaces. More and more companies are dependent upon software for greater and greater aspects of their business. More and more roles within those companies require their users, or employees, to actually interact with software. With that, we need to start thinking about how do we start to have a delegation model that makes sense. How do we allow the individual that’s closest to the business outcome, to be able to impart the needed changes?
If you think about it from the context of developers, you want your developers to be able to focus on building things. If your developers are spending time responding to change requests for who can access new features, they are spending less time building them. This is also a disservice to your business owner (Sales, Support, Customer Success, etc.) who needs to wait for a developer, instead of imparting the change directly.
Not only Nana
As I’ve worked with teams to adopt progressive delivery in their organizations, I’ve realized this challenge goes beyond age or digital fluency. Driving this need at large companies are existing process, regulations, compliance standards, and training requirements.
Even if individuals want to move fast, they may need a more progressive approach.
Know your users
Some are ready to use the latest technology to solve every challenge they encounter. For example when my daughter got a Rubik’s cube she was more inclined to build a robot to solve the puzzle than to figure out how to solve it herself. Like I said, “there’s an app for that.”
Some prefer to have their technology only change when they are ready. For example, my mother-in-law would prefer to have her software update at the same pace as the seasons; at most four times a year.
As an industry we need to help manage this transition period. We have the tools to offer this flexibility to our users. We just need to start using them.
