The real goal isn’t to “do Scrum”, “do Agile”, “do Lean”, or what-have-you. The goal is to be in a position to deliver working software that gives the users some new capability at a moment’s notice.
For many teams and organizations, continuous delivery feels like a lofty, unattainable goal, especially if you’re saddled with a process that restricts delivery to months, or even weeks.
But as with any goal, the key is to keep aiming in the right direction.
Why is this true? Why do enterprises and commercial software companies put themselves through the anxiety and pain of the "big bang" release?
Probably the biggest reason is inertia. But as a result, they live in fear of change because change might wreck all of work that went into their carefully constructed environments.
What if you turned all of that planning on its head? What if instead of two or four large, disruptive releases, you had much more frequent and smaller releases?
The principal benefits of continuous delivery are:
The benefits are huge: your team can be more productive, less stressed, and more focused on feature delivery rather than dealing with big, unknown potential changes. In fact, you can go so far as to say that when you do releases often enough, they become predictable and even boring.
However, to take advantage of these benefits, you have to embrace a few concepts of Continuous Delivery.
Principles of continuous delivery:
We come from a long history of building software the "release early, release often" way. If release often is an ideal, continuous application delivery may be enlightenment.
But how to know if you have achieved it?
The key test is that a client could request that the current development version of the software can be deployed into production at a moment's notice - and nobody would worry a bit, let alone panic.
Focusing on what matters the most is the key to success in any profession. Focusing on what matters may sound like common sense. But common sense is not as common as we think.
Not all features are of the same significance. Customers value some features more than others. 20% of the features bring 80% of the value for customers. Determine the top 20% of the features in your website/app that 80% of customers use.
The 80-20 rule, also known as the Pareto Principle, is an aphorism which asserts that 80% of outcomes (or outputs) result from 20% of all causes (or inputs) for any given event.
Pareto’s rule of thumb directs you to spend more time working on those things that give you greater rewards. You can also cut back on a lot of things that do not give you significant returns on your efforts. Pareto’s 80/20 rule is a potent little principle that can increase your productivity as a tester and make your life easier.
Whenever you’re making something, you want to put it in the hands of those who are actually going to use it as fast as possible. You want to do this with something that delivers at least a tiny bit of value.
How effective does it have to be? Well, it should actually work, though to a person who has been working on it, it may seem kind of embarrassing. You need to get that product out to the public as early as is feasible!
This will get you the feedback you need to power your decision loop and prioritization.
This allows you to make features they value, first, and release your product when you’ve only done about 20 percent of the work. You know it’s not perfect, but it’s pretty close.
What’s great about this process is that it’s iterative: just “put on repeat”. Once people have you product or service or change in their lives, they’ll tell you what the next most valuable things are. Then develop 20 percent of that, and deliver again. And again.
If you want to delight your client, forge a relationship with them where you can actively help solve their problem. Even though your title might be some variation of “Software Developer” or “Software Engineer”, in truth it should be “Problem Solver”. That’s why we’re here. We solve problems.
“When you enchant people, you goal is not to make money from them or to get them to do what you want, but to fill them with great delight.”
Guy Kawasaki
Delivering working software in a timely manner isn’t enough. That alone won’t delight them.
Your users are not particularly motivated by code. Instead, they have a business problem that needs solving within the context of their objectives and budget. Their belief is that by working with your team they’ll be able to do this. It’s actually these expectations of business value that really count – not just the software project itself. The software is only a means to these ends.
So don't just deliver code, delight your users.
Before you start your work every day, ask yourself – “Is this task on the top 20% of my to-do list or in the bottom 80%?”
Dashboards, metrics and automation for development teams to focus on their most important work. Made by developers for developers.
PRODUCT