Moving from batch releases to fast, continuous delivery processes drives changes in roles. When developers release more frequently, development starts overrunning the other roles, and you have to adjust.

Developers and programmers

Developers gain a lot of power and a lot of responsibility from continuous delivery.

Developers (programmers) will decide what is ready to release. This is a strong finding. We see it in all successful continuous delivery organizations. The developer of a feature decides when it is ready, and runs the scripts to put it into the production version.

This happens for two reasons:

1. It is faster. You unblock your team so that developers can work at full speed. They don't have to wait for a product manager, product owner, or marketing person to tell them that users, marketing and documentation are ready for a release. Instead, they release everything that is ready, and hide it from the general public. The PM or marketing person can come along later, see that the new feature works, and start the "unveil" process.
2. It provides the correct incentives. The developer is responsible for the releaseb, because he or she is the one who can fix it. A developer can be called back from Friday night beers to fix a problem. Therefore, developers have a compelling reason to make a good decision about what to release. They should not throw buggy code over the all to a QA person. They need to be forced to focus on quality by removing the QA training wheels. They will be motivated to build good tests, and good scripts for testing and deployment.

Developers will have more responsibility for testing. They will write and run automated tests. They will get whatever help they need to make sure a change is released without bugs.

DevOps

DevOps is the hot new role required in a continuous delivery process. A DevOps professional is a system operator and administrator who also knows how to write scripts to automate testing, deployment, and measurement. You will need this. You can get it from operations, from developers, or both.

Ideally, DevOps should not be responsible for builds and releases. Developers should make builds and releases, using tools that they develop with the ops team. The DevOps movement is about providing automated tools. Essentially, they package the things that your operations guys used to do manually into convenient SaaS services.

In a big shop there will be DevOps people who specialize in building test systems, running tests, and reporting on test results, code quality, and developer contributions. This is the Test Engineering team.

QA and testers

QA acts as a consultant to the developers. Developers will call in a QA professional to make sure that a change does not cause problems, and is a good change. They need the QA professional to protect against mistakes, clarify requirements, and cover their butts.

QA gets more respect! Developers appreciate QA expertise more when they have to ask for it.

In a distributed continuous delivery process, the QA team members might find that there are multiple test systems, and they need to look in multiple places for the version that they are going to test.

A good QA team will learn to build and run automated tests. QA team members will spend more time doing usability testing and exploratory testing. The developers are busy making sure they don't release bugs. This frees up QA to figure out if the debugged features are actually useful. Also, more features will be released in some sort of improvement process before they are unveiled.

QA should also be freed up to monitor and measure the quality and productivity of the development process. So, they give up power over specific releases, but they get influence over the whole development process.

With developers and DevOps taking more responsibility, it is normal to have a fairly high ratio of engineers to testers - more than 5 to 1. This reverses the pathology that a lot of companies get into. They find that releases are taking longer and longer to test, so they add more and more test professionals, until finally they have as many testers as programmers. This tactic can marginally increase quality. However, it cannot accelerate delivery, because the testers only find problems. The problems still need to be fixed. By moving to continuous delivery with more layers of review and testing BEFORE software goes to QA, companies fix the problem at its source and eliminate release delays while freeing up QA capacity.

Product managers and product owners

Product managers and product owners are supposed to decide what features will go in the product, and what those features will look like. A full-speed continuous delivery development team will run past them and run over them. If the development team gets going too fast they will start to implement stories that product owners have never refined, or even approved, and they will produce features with no value. Product owners need a way to make sure that every feature implemented is a great feature.

Our solution is to ask product owners to work more closely with the developers during design and implementation of a story. When they take this role, we call them "story owners." This matches the speed of development with the speed of design. It helps get stories into development faster, because they require less up-front design. Story owners, designers and developers can start working on incremental design and implementation of a story when they have a clear use case to guide their design and implementation. This tactic also slows down development to enforce quality. Developers, designers and product owners can take as much time as they require before unveiling new features.

We see some other big changes in the role of product managers and product owners.

Usability is more important than requirements. A product that nobody uses doesn't meet anyone's requirements. Modern product owners should become experts in usability. Usability can be shaped from day to day based on feedback from frequent releases.

Measurements are supplementing or replacing strategy and market research. Product owners should be driven by metrics. Modern systems produce a lot of performance and usage numbers. These numbers can be a more effective guide than other types of feedback and market research.

Senior managers

Experiment. Limit the size of new projects. Make them earn bigger budgets and bigger rollouts. Don't expect new projects to meet the same quality and process requirements as mature projects. Let new projects be small and experimental with phases for prototyping, and beta testing. I call this "learn before launch."

Fund. Senior managers should not budget for specific features or releases. That slows everything down to negotiating and fulfilling a fixed plan. Unblock! by funding the team or product or program. Later, you can allocate capacity. Out of the stories that are on the Kanban board, a certain percentage can come from each epic, product owner or initiative that the company is supporting.

Measure. Managers should measure velocity, and look for bottlenecks in overall delivery of value. They should ask for frequent measurements of the development process, and of product usage.

Prioritize and Limit WIP. Make big plans and keep a big backlog, but work on a small number of things at the same time. If your team is working on a lot of different things, they will not be able to take any new requests. They will be unresponsive. IT organizations often become unresponsive because they have too many active projects. Working on a small number of tasks, and having some free capacity, will increase the speed and responsiveness of any organization, large or small. Senior managers will get responsiveness if they do their jobs and prioritize.

Indulge. Managers can indulge in making a few high priority requests. The continuous delivery capability can give them rapid delivery of features and fixes. It is a powerful tool. But it will only work for a small number of requests at one time. And, it will only work if the team has room for the rush requests, because they have a limited number of other requests.

Accelerate. They should be looking for opportunities to use continuous techniques in other areas of the company. Once development gets rolling, they can accelerate launch, marketing, budgeting and hiring.