A big side effect of the world’s new focus on work from home? Collaboration delivers leverage. Those of us who do software for a living are quite fortunate. Many of the habits we’ve learned in collaboration and wrangling a distributed workforce make a difference, particularly in the new work-from-home reality of Spring 2020.
Lockdown and the pandemic, to paraphrase Mike Tyson, have punched us in the face with Everything-as-a-Service. In the face of this sudden acceleration of SaaS-ification, DevOps need to do more to accelerate the transition.
It’s customers who pay the price. Our job as software professionals is to make it worth it to them. Done right, get more better benefits & features faster. Done wrong, users and customers drop your platform for one of ever more alternative options.
Let’s look at how we know how well we are doing that.
Is collaborative software development enough?
It’s increasingly impossible to imagine a SaaS business without a firm commitment to DevOps thinking. DevOps changed software development – whether cloud-native, cloud-hosted or “Oops! I forgot to move to the Cloud” – in two healthy ways.
- First is the understanding that the division of labor between infrastructure and coding new features needs to be around the same table. Twenty years into the Agile Revolution, the virtuous cycle (time boxing, scrum, kanban, iterative discovery-and-development) pays dividends all around.
- Second is the accelerated acceptance of software-defined infrastructure as a norm. Generally referred to as “infrastructure as code,” it extends healthy coding practices and well-organized repositories to any and all of your software. It matters just as much if you are writing code to update the network config or the website.
Yet I believe there’s a new, more significant challenge ahead. It goes beyond just engineering culture and draining the backlog using harmonious collaboration. There’s a feature arms race underway, and SaaS is fueling the fire. The quality of collaboration in software development is measured by a direct line of sight into the customer experience, but there’s more to it than feature agility.
Feature agility is sexy. Those awesome new tricks that seem to show up out of nowhere within cloud-first applications like Google Workplace, Slack, Facebook, Twitter, Stripe, the iPhone, and Amazon (both eCommerce and AWS)? It’s made to look effortless by any heavyweight you might name, but don’t be fooled. The best SaaS companies succeed because they owing to a relentless focus on eliminating feature friction.
If your DevOps initiatives are not focused on draining the backlog of feature friction, you’re putting the cart before the horse.
<b-orange-blog>I’d like to learn more about this →<b-orange-blog>
SaaS is the Software Factory of the Future
The ascendancy of SaaS as a business strategy is nothing new. One industry leader defines it as “a licensing and delivery model where software is centrally managed and hosted by a provider and may be made accessible to customers on a subscription or pay-per-view basis.” That’s necessary, but not sufficient. A profitable and competitive business SaaS model is one where the technology platform streamlines the production and delivery of software.
What SaaS demands of software is feature agility. Keeping the customers who access your software and ensuring they renew their subscriptions? Your software always needs to do a better job for those nice people with the money by staying more relevant and more valuable than anyone else. Otherwise, your customer relationship and the money it represents evaporates as fast as an app you no longer want cluttering your smartphone.
The Agile development revolution put solving customer problems front and center. SaaS applications we use and love (from B2B to B2C and everything in between) seem to come from a heady blend of design thinking, cross-platform UX, and iterative feature prototyping. Indeed, product development and product management, where roadmaps originate and competitive juices flow, is a hotbed of creativity. Product managers are chasing more ways to add value to the applications they deliver to customers, to gauge which features users love based on feature utilization. Product development teams work hard on figuring out what the best user experience is, and on coding it up.
In this view, a reasonable division of labor might be that once the product design and development team finishes, it hands off to a second organization responsible for build, test, and deployment. The operations team is just the last step between brilliant innovations and the nice people with the money. The fact that dev team tasks precede operational tasks creates the perception of a one-directional supply chain.
That’s a mistake.
When DevOps becomes the customer experience
Software feature development is an input, not an output. All these choices discussed in product design and coding sprints? They are heavily centered on the means of software production.
Putting “Dev” before “Ops” creates a false dichotomy of sequence. You might think this is trivial. It’s not. The portmanteau of the two words can set false expectations. And improving the collaboration across different functions takes longer than it does to apply a label. I often talk to customers who are looking for “someone to do DevOps,” assuming that giving a software professional a title solves the problem. The mistake is solving for feature agility without enough focus on feature friction. The table below from Gene Kim (of Phoenix Project fame) is a good comparison of the gap in mindset:
It’s vital to gauge product software development at the point of consumption in production; that’s where customers can get their (virtual) hands on it. This is especially important when you are delivering a SaaS product. Again, there is no question that Agile-driven design thinking and user experience observations are vital inputs to user experience. The more fundamental question to ask is this: how stable and reliable is the service from the perspective of the user.
The ultimate measure of customer experience is time invested by users and customers in your product, and the money that time represents. In my next post, I’ll talk about how that can be measured.
