You can move to continuous delivery incrementally, in two simple steps.
You do not need extensive training and the dreaded "culture change." You can motivate your team to do the right thing with some simple incentives.
If you release frequently, your developers will stop ripping apart the software and breaking it. They will start using feature switches and other tactics to make incremental changes. You will not need to train them. They will figure it out.
If you require code review, you can get automated tests and compliance with coding standards. You can find people who believe the standards are important, and let them be the reviewers. You will not need an extensive set of policies, and training, and browbeating. You will not need to hire new people with a culture of test driven development. Only code that meets your standards will pass reviews. You can ask for tests, and you will get tests.
If you make developers decide when to release their changes, they will start to test more thoroughly and to automate tests and deployments. Remove the security blanket provided by your test phase and QA people. Make developers push the deploy button. You will get results.
If you make product managers and product owners responsible for unveil and measurement, they will start to work more intensively as "story owners" to make better features.
You can phase in continuous delivery with one team or service, and keep your existing batch release process for others. This will give you an opportunity to test some theories:
You can build your continuous delivery capabilities in any order. The list below is a comfortable progression for a Scrum team that start by planning an iteration, testing a release candidate, and releasing in batches.
1) Maximize monitoring and reporting
The DevOps guys say "measure everything." You should maximize the amount of monitoring and reporting that you can get from the running software. You should get a good view of errors, usage volume, and feature usage patterns. This will give you confidence to release, because you will find and fix problems quickly. It will reduce your reliance on building automated tests. And, it will provide essential information for product management and improvement.
If you can measure some things about the development process, it will be easier to find and show improvements. Even very simple or crude measures will be useful. You can try to get a basic measure of velocity - counting points, or features, or tasks that get finished. How long does it actually take to go from an idea to a release? How frequently do people commit code? How long does it take to test the changes? How many bug reports are pending? How many times does a "finished" task get sent back for more work? Which changes actually result in an increase in usage?
Measurement is an easy first step because it doesn't disrupt anybody's existing way of working.
2) Scrumban, with no iteration plan
Throw out the iteration plan. Ask your developers to "pull" tasks when they are ready to work on them. At this stage, employ triage and test when you are ready to make a batch release. However, your developers will be working in a lean and continuous way. Remember, the goal of a lean system is to finish changes as quickly as possible. You do this by limiting the Work In Progress so that every task on the board is being worked on actively.
3) Automate build and deploy tasks
You will need automated build and deploy scripts as a foundation for repeatable testing and deployment. Aim for continuous improvement in your DevOps. If you have installed software or an installed client distribution, you should look for ways to automatically update the client software.
4) Use an Automated Test framework
You will need to add scripted tests to your code. This will be easy if you use one of the popular frameworks that include automated testing (for example, Ruby on Rails). Otherwise, look at our Test Typeslist and find some easy ways to layer in testing. For example, you will need to have good production monitoring, and in some cases this can substitute for other types of testing.
5) Code review and tests
Now you need to build automated tests. You need a social framework that motivates your team to build and maintain automated tests. You will get good results if you add code review, and have the reviewers who are enthusiastic about testing to ask for tests. You can use one of the review or branching code contribution patterns.
6) Continuous Integration and on-demand test systems
You need a fast and convenient way to run tests. You should put in a continuous integration system that will automate testing. You should also be able to build on-demand test systems for contributors who are working in a cascading or continuous process.
7) Changing role of QA
You need to unblock the approval of feature releases and get QA out of the way. Your QA people should be ready to serve as consultants for developers who ask for their help in making sure that changes do not create problems, and that features are actually useful.
If you have a good QA team, your developers may have become lazy and accustomed to throwing code over to QA without taking full responsibility for quality. At first, they will not believe that they can release directly. They will say it is too risky. At some point you will need to take off the training wheels and force them to ride the bike. If they must approve and do their own releases, they will figure out how to make them work reliably.
You will need to persuade developers to take responsibility for pushing out releases.
8) Kanban
Now your developers have test systems and QA support. They are ready to take responsibility for moving every change through to completion. You can move them to Kanban task management. They will "pull" a task, work on it, and finish it with a code release.
9) Move the CD Dial
Now you are ready to move the ContinuousDelivery Dial and get closer and closer to releasing every change in real time. As you go faster, you might want to move your product owner role closer to a story owner role, so people in that role can be more closely involved in shaping features during development and unveil. You will want to improve your usage measurements so that you can monitor changes and respond. You may find that you can resolve more questions about product management through experiments. As you gain confidence in testing and assembling releases by pulling changes that are ready, you can expand your team.
If you are feeling lucky, you can take some shortcuts that will save a lot of work.
My first suggestion is to skip the automated tests, and add them later. Use test layering. You might be able to rely on production monitoring instead. If you are running an online system, you should be monitoring the system for errors, and monitoring your users for their usage patterns. You can release to production, watch your errors and usage carefully, and roll back if there is a problem.
My second suggestion is to partition your user base so that you can release with less risk. Do you have users that get a free product? Are annoying? Are contributors? Give them the less-tested, frequent releases.
We will add more suggestions here as they come in from the field.