Introduction

Why adopt DevOps?

IT change can be painful and subject to long lead times in many organisations. The pain generally stems from treating change as exceptional rather than business-as-usual - often in the form of running a project to effect the change.

Running multiple concurrent IT-related change projects can put a strain on the organisation and managing conflicts in the form of people, time, cost and overlaps can become extremely complex.

The reality of change however is that it never stops. Often the amount of change within an organisation is ever increasing in order to fulfil new and ongoing business objectives, deliver business value, incorporate legislative change etc.

A rethink is needed. Change should take front-seat in the IT organisation. It is best achieved by establishing and empowering cross-functional teams that each have responsibility and accountability for a particular function, service or product. This can indeed also include IT support, security, governance etc.

Change is at the core of DevOps. DevOps is about building lean workflows and adopting an engineering culture that embraces change.

Although there is no single DevOps definition it concerns three areas:

• Development practices
• Tooling
• Continuous improvement, also known as operational excellence

Note that in this context DevOps and Agile are complementary. Simply put, Agile deals with workflow planning and DevOps with workflow execution.

For DevOps transformations to succeed radical rethinking of workflows and practices across the IT organisation is needed. This will require senior sponsorship.

1. Sponsorship

Adopting DevOps can impact the wider organisation. For this reason senior sponsorship is of paramount importance in order to facilitate organisational change, to cut red tape and make exceptions to existing processes where needed.

In return a sponsor will demand regular updates on progress and reporting on impact. This will include what has been learnt from the initiative.

At senior level there is probably already an awareness of - and frustration with - the pain and pace of IT change. It may therefore not be that hard to find a sponsor. That frustration may even lead to a call to arms to seek ways to improve the situation.

At this point change agents - with an early adopter mindset - are typically found within the organisation to help bootstrap and drive the organisational changes required to adopt Agile & DevOps practices as well as to assemble a first team.

2. Inception

DevOps adoption should be done in phases.

The first phase will typically be to get one or a few DevOps teams in place and to get a few successful transformation projects under the belt to learn and to adopt the DevOps tools and culture in a way that works for the organisation.

At this point also consider use of an external partner in an advisory capacity to help formulate a DevOps adoption strategy that works for the business. The right partner can help mitigate risk of failure considerably by offering a realistic path to DevOps adoption.

The initial transformation project choice typically entails considering service or product attributes like:

• Size
• Complexity
• Strategic relevance
• Risks

There is no right answer to choosing an area of transformation but generally the function is strategically important (to focus on things that matter), small enough to be deliverable in a reasonable time frame and big enough in scope to learn DevOps practices.

A note on using partners. Partners can bring in a vast amount of experience and guidance on DevOps adoption. However, attempting to use the partners as change agents within the organisation is unlikely to yield the anticipated results. Partners do not possess the influence within the organisation to effect change. Instead, use partners for help with strategy, advice and to fill knowledge and skills gaps.

3. Team

In DevOps, culture is vitally important. Building the first teams means finding individuals within the organisation with an open, early adopter and gritty mindset.

Building the first team involves identifying the roles that need to be filled in order to create a self-sustainable team. It means finding the right people for the roles from within the organisation to make it happen.

The team is cross-functional to support the product fully. The team therefore often includes developers, DBAs, architects and often also roles like a Product Manager and a Scrum Master or equivalent.

Team building exercises and celebratory events are recommended to build a cohesive team that shares common goals.

Many roles in the team can generally be filled from within the organisation in order to facilitate organisational learning.

Some roles are likely to require outside assistance in order to bring in the right expertise to fill knowledge and skill gaps to bootstrap the transformation faster. The DevOps toolset is most often the area to hire outside assistance for.

Also consider the Forming, Storming, Norming & Performing aspects of building a team. It will take time for the team to act as a performing unit with common goals.

4. Tools

Tools underpin DevOps practices in order to automate common and time consuming tasks. Often, some of the tools are already used - unit tests, continuous integration with automated builds etc. are now quite common.

The tools in the DevOps toolbox include:

• Common source code management and version control practices; e.g. Git(Hub) and feature/master branching
• Build automation; compilation of code and generation of artifacts
• Test automation; unit, integration and functional testing
• Build artifact staging in a repository, e.g. Docker images, jar files etc.
• Release management - release approval and deployment automation
• Configuration management - infrastructure configuration, infrastructure as code & parameterisation
• Monitoring - performance, issue monitoring and alerting

However, teams need to be realistic about rate of tool adoption. For many existing IT products and services it is not a simple or indeed overnight process to fully automate all aspects.

It is therefore imperative to first map the underlying processes of existing development, testing and deployment practices from code commit to production deployment. This includes identifying stakeholders, gatekeepers and hand-off points.

Once the processes and stakeholders are understood it is possible to plan and factor in automation gains over a number of iterations - aside from supporting business-as-usual.

Finally, the vendor market for DevOps tools is overwhelming. But it’s important to adopt the right tool for each job and to consider both development and operational aspects of tool choices that will help minimise overheads. Some of the unmanaged tools require considerable ongoing maintenance and perhaps even their own dedicated teams.

The guiding principle should generally be to keep it simple and to adopt managed tools where possible in order to minimise overheads.

5. Continuous Improvement

At the core of DevOps is an aspiration to continuously improve - also known as Operational Excellence. It is important to set aside time to regularly discuss what went well, what didn’t and what can be done to improve workflows, cooperation, communication etc. Those bits that can be improved within the team are added to the backlog for the next iterations.

In this context gathering metrics are important. Adopt actionable metrics that measure process improvement and DevOps maturity over time. Example metrics include:

• Production uptime and failure count
• Fix-on-fail and rollback events
• Pipeline time, i.e. time spent in the pipeline from commit, through build, deployment, test and until successful production rollout
• Change lead time, i.e. time from work starts on a feature until successful production rollout

It’s equally important to establish post-mortems for when things go wrong in order to identify often systemic problems, determine root cause and ultimately resolve the issue - not merely working around it. Add the learnings to the body of knowledge for future reference and training.

6. Scale

As the organisation evolves its DevOps practices it is imperative that the learnings are disseminated throughout the organisation. That’s phase 2 of DevOps adoption, which looks to scale the effort wider than the initial team.

This can be achieved by building a shared body of knowledge of what works for the organisation and teams and to rotate some members out of the already existing DevOps teams to help build and coach other teams.

Once the DevOps transformation endeavour hits critical mass, identifying and deploying new change agents in other parts of the organisation also helps spread the adoption of DevOps.

Conclusion

“It’s all about the journey, not the destination” has had some considerable mileage over the years. But in the context of DevOps it still rings true. DevOps is about continuously evolving and adapting to change and therefore does not have an ultimate end-state.

People come and go. Markets and strategy change. Applications change or may get replaced. Restructuring may occur to rationalise business processes or proposition.

A given DevOps team is therefore best thought of as delivering on a particular business objective. The details of that objective will invariably change over time just like everything else.

Please reach out if you have any questions or comments on DevOps adoption to team@virtuability.com.