If you're managing an IT team, you're certainly aware of DevOps and its growing popularity as a community of practice and a set of principles – and a path to delivering better software, faster.

Here are a few ideas for working with your operations team, software development team and management that should help make your DevOps initiative successful.

The motivation for DevOps

Most teams looking to adopt DevOps are in organisations that want to release software faster and increase operational efficiency. Oftentimes, there's also a desire to abandon dysfunctional modes of working and adopt more sustainable working practices.

In most cases, you won't be given budget to hire more people to meet goals. So operations teams feel squeezed, and a rift grows between operators – who are incentivised to keep things stable – and developers and business teams that are incentivised to produce more, faster.

These misaligned incentives result in organisational silos, operations being viewed purely as gatekeepers, and the growth of shadow IT.

Aligning with the organisation's purpose

As an IT manager, a big part of your responsibility is making sure your team understands how its work ties to the strategy and goals of the entire organisation. You also need to communicate to other managers how your team’s work supports their teams and the overall mission. And you need to make sure that upper management understands how critical your team is to everyone’s success.

> See also: Bringing DevOps to the legacy side of the business

Your operations team needs to see how DevOps practices can help improve their working lives. Here are some important steps to take:

Focus on the team over individual specialists

In some ops teams, people have such specialised skills that the team itself is siloed. One person takes care of the database, another the network hardware, another your Windows estate, and so on.

The overhead of coordinating all these people and their activities can actually take more time than the work itself. One answer is to reorganise teams around products instead of functions, putting software developers, system operators, QA specialists and product managers on the same cross-functional team. In this structure, it's not individuals who own the work, but the team itself.

Because responsibility for outcomes is shared, people learn more about each other's work, and tend to work together better. They are also more aligned to organisational goals, as these have been emphasised over individual achievement and team-only goals.

Treat infrastructure as code

Describing and managing infrastructure as code means you replace static, seldom-updated documentation with living source code. You can use the same practices for managing infrastructure that are common to software development teams: code review, continuous integration and unit testing.

These practices can make your infrastructure far more reliable while opening it to others on the team, so they can understand and help manage systems.

For operators, the infrastructure-as-code approach means embracing new tools and new ways of working. Operators with some development background will find it familiar, but those with a traditional admin background may be intimidated.

Emphasise that this isn't about every admin becoming an experienced programmer – rather, it's about adopting coding practices piece by piece.

Adopt agile ways of working

Limiting work in progress encourages collaboration and allows individual tasks to be completed more quickly. Working in iterations lets you improve the work process, resulting in product improvements, as the team learns from one iteration to the next.

Regular retrospectives help teams learn from what went right and what went wrong, and let the team work on small improvements that can really add up.

Increase visibility into work

Putting displays into the workplace lets everyone see productivity and quality, and reinforces the sense of shared responsibility. Problems can be solved earlier, and bigger problems avoided.

Reach out to other teams and work with them

DevOps is about collaboration. You can promote learning and collaboration between teams by asking if each operator can shadow a developer for a few days, listening during daily standups or attending sprint retrospectives. You can invite developers to outage postmortems, and to your team's planning sessions.

Greater awareness of each other's work helps generate empathy and new ideas for process improvements.

Developers often have different incentives from operators. To get developers and operators working well together, you need to help them develop aligned goals. Here are a few suggestions for accomplishing that.

Pairing

Pairing is a great low-barrier-to-entry way of starting collaboration across teams. Just as developers can help operators learn to work with software development tools and processes, operators can help the development team measure and improve application performance.

Admins can also help developers with things like capacity planning, incident management and auditing requirements.

Use security as an olive branch

Many developers are interested in security, but have limited experience with it. Operators can reach out to developers with offers of training, and invitations to threat briefings. Share monitoring data around malware or DOS attacks.

Management incentives are different from yours, and from developer incentives. And managers want to see results now, or at least know when they can expect results. If you can explain DevOps well, management will be confident your initiative will serve organisational goals, and allow you the time the teams need to establish new practices, and show results.

Here are a few ways to conquer scepticism and get management buy-in, so you'll get the time your teams need.

Make the business case for DevOps

Present DevOps as a business change, not a technology change. While DevOps is often associated with new tools and practices, the real change is the new way of working that aligns technology with business strategy. Offer studies from industry analysts, articles and case studies from the technical press, and industry surveys.

Don't talk about DevOps

DevOps is a buzzword. It's better to talk about solutions to problems, and practical benefits. For example, talk about: improving instrumentation and monitoring, which improves mean time to recovery and lets teams identify problems before customers report them.

> See also: DevOps: the good, the bad and the inevitable

Talk about deploying smaller batches more frequently, reducing risk of failure and getting new features to customers faster.

And managing configuration in code, reducing manual work (which is expensive) and allowing changes to be rolled out faster, with fewer errors.

Get time, take time

People need time to implement and adjust to change. And with DevOps, it's not just your own team that needs to change, but all the other teams that interact with them. So don't try to change too many things at once.

Give people the chance to provide input at regular intervals; not only will they feel more included, and so more favorably inclined, they'll also be able to help evolve the design of new processes and services – and that should make them better.

Sourced from Gareth Rushgrove, senior software engineer, Puppet Labs