How continuous deployment impacts the entire organization

In a continuous deployment (CD) software release strategy, any code commit that passes the automated testing phase is released automatically into the production environment. Automation replaces many manual steps and prompts dramatic changes in software delivery and operations.

While dev and ops get the most attention when talking about the impact of CD, its effects extend outside your IT organization in a variety of ways.

CD and organizational performance

Reducing time to market is an essential goal for companies and even federal agencies (with government mandates such as Cloud Smart) to improve employee, customer, and constituent experiences.

There's been some notable analysis and commentary around the organizational impacts of CD. Perhaps the best-known is "The Role of Continuous Delivery in IT and Organizational Performance" by Nicole Forsgren and Jez Humble. Analyst firms such as Forrester, cloud service providers (CSPs), and DevOps tool vendors are other sources of research and analysis on how CD impacts organizations. As you read these reports (which may vary in quality), look for parallels with how CD affects your organization and opportunities to open new communications channels about easing the impact of CD on your business units.

Ramping up your organization for CD requires creating a culture where everybody—not just your IT shop—welcomes new ideas. You must train your people to bring their managers' bad news and be proactive about resolving the issues CD brings to the delivery cycle. All levels of your organization must learn to treat failures as learning opportunities rather than a one-way ticket to the human resources office.

You can't understand the impact of CD on your organization unless you measure performance before and after you implement CD.

Before implementing CD:

• Gather status reports that document your wins and losses with application and services delivery
• Document known challenges to application and services delivery, such as known workarounds or immature processes that complicate development and operations
• Collect insights from your developer and operations teams about what worked and didn't work in the pre-CD era
• Gather insights about business collaboration between your developers, IT ops, and other departments
• Review customer and sales feedback about your product and service delivery effectiveness
• Interview your sales and customer success teams about delivery challenges

After implementing CD:

• Equip your CD pipeline with meaningful analytics and reporting for business and technology stakeholders
• Train your developers, IT operations staff, and stakeholders on the analytics and reporting tools in your CD pipeline
• Conduct regular review sessions with management and lead developers about the impact of CD gathered from reporting and feedback
• Monitor your traditional customer feedback channels and increase your sales feedback channels

There are a variety of ways to communicate this data to your stakeholders. Whether you choose a specific technology, a presentation, or another way to deliver content, don't forget about the human connection. Deliver the measurements in person. Have a dialogue. Be prepared to get feedback and answer questions. Listen intently. Be proactive with any follow-up actions.

CD and culture change

Continuous deployment brings needed cultural change to organizations. Some employees will embrace it. Others might see it as a tectonic shift in their job duties. Some schools of thought see it carrying an emotional cycle, including dread and blind rage, depending on your corporate culture.

Cultural challenges crop up around how CD may change people's jobs—not just developers and operations staff. Because of CD's expedited release cycle, a trainer may have to learn new features more quickly, or a sales manager may have challenges setting up a team for success. Or an executive may press harder for one-off changes that aren't part of the new release cycle.

Line managers and senior team members across departments need to acknowledge these reactions. There's a lot of information available about change management across the industry. I always put my money on frontline workers to manage employee reactions to change best. Set the channels, tools, and frameworks to allow this to happen without over-engineering things.

Promoting the cultural change that CD brings to your organization is important. It's more than just having a change-management team. It means taking a people-first approach to evangelizing CD, including:

• Winning over well-respected mid-level managers and senior staff by showing them how CD can help cure some of their pain points.
• Creating an open channel of communication between all departments that will be impacted by the move to CD
• Communicating customer and project wins where CD was a deciding factor (e.g., a new customer comes on board because of CD helping to deliver features more frequently)

CD across departments

There are many articles and books about how CD affects the development and operations teams. It's the impact on other departments that's often forgotten in the rush to change. Organizations must put support frameworks in place to help other departments embrace what CD offers the business.

Here are some ways CD can impact departments outside of IT.

C-suite

CD's impact can even find its way into the executive ranks. It's up to your development managers, product managers, and product owners to do more to manage their release cycles while communicating about them with the executive team. The big thing you don't want is an executive hijacking your new CD cycle for one-off features and pet projects that divert from your product roadmap.

Build a relationship with your C-suite and have early and frequent communications about your product roadmap with your executive stakeholders. You also need to manage their expectations about your new CD cycle through reporting and gathering their input.

A product roadmap is the best way to help executives adjust to the new world of CD. Work with them to stave off any feature-creep whims and stick to business priorities.

Program and project management

Introducing CD means it might be time to dismantle your aging project management office (PMO) war room with Gantt charts taped on all the walls. CD requires a different type of program and project management. Your days of large-scale "plan and execute" delivery and management models are over when you move to CD.

Your PMO may need help learning new agile project-management techniques such as minimum viable proof points and how to validate them with internal or customer teams. This often means:

• Sending key project managers to agile or DevOps training
• Breaking down any silos between your PMO, development, and operations organizations, up to and including disbanding your centralized PMO and embedding project managers within teams
• Moving project management data to SaaS applications to give everybody on projects a view into project data and progress.

Marketing and sales

Continuous deployment can even impact the work of marketing and sales. Whatever your market, you want them hungry to serve your customers. One way to help them is to give them more things to sell, and continuous deployment can deliver that for your sales team.

Part of moving to CD is about equipping your marketing and sales staff with information. For example, you can:

• Invite marketing staff to test out new features and releases before launch
• Enlist marketing communications support on a continuous delivery basis to communicate about new features and releases
• Make the right technical staff available as subject matter experts (SMEs) for creating marketing materials

Marketing can become a new ally in your move to CD if you can help them tell your CD story to your employees and customers.

Technical writing

Technical writers are often left out of the corporate DevOps discussion. As a technical writer, I concede it's partially our fault, but much of it is organizational.

Continuous delivery means certain things for your technical writers. First of all, they must put the tools and strategies in place to deliver documentation in a CD model. Some ways to help them include:

• Dismantling your centralized documentation group and embedding technical writers in your development and operations teams
• Managing documentation development as part of your overall delivery cycle—dependencies and all—instead of on a separate schedule as an afterthought
• Grooming your writers to be more feature-oriented by involving them earlier in the release cycle

Final thoughts

CD brings fundamental changes to organizations because old scheduling and development cycles disappear. As you move to CD, you need to bring your entire organization—not just your development and operations teams—along in order to reap every advantage.