The enterprise route to continuous delivery

This is part two of a three-part series to help you make the most of DevOps and Agile in your cloud transformation and application development programs. Click here to read part one.

CI automates the process of building and testing code every time a team member makes changes. CD is basically an extension of continuous integration – automatically making sure that you can release new changes to your customers quickly in a sustainable way. CD is one of the cornerstones of DevOps. It comes with a number of benefits, including reduced risks and the ability to integrate new features more quickly and make deployments more predictable with shorter feedback cycles from customers. It also does away with costly manual operations.

CD is a methodology that can increase the potential behind an Agile approach by combining CI with DevOps tools and best practices.

Continuous delivery impacts team culture

CD isn’t just about adopting new tools and processes – it also involves a cultural shift. With CD, for example, each developer has to work as a unit. This creates an active community where everyone can see the latest changes and how their work impacts the project and give direct feedback. This essentially empowers the team to take ownership of the project.

When the development team at Basefarm, a leading cloud provider in Europe and an Orange Business company, was asked to rewrite the previous version of Basefarm’s provisioning system, they wanted to do it using Agile methodology. This meant establishing a team culture based on trust and understanding, where reaching out for help was not seen as a weakness.

Having said this, Basefarm decided that non-team members could have their opinions listened to, but could not block advances in the project. “We think this is an important point to make, because humans are often skeptical about change, and granting non-team members the power to stop experimentation would lead to no progress being made,” explains Geir Hedermark, Development Manager, Basefarm.

Agile isn’t everyone’s choice

Agile methodology isn’t for everyone. Agile working is particularly attractive to those with T-Shaped skills – those that have expert knowledge in a certain area, but have a willingness to collaborate with experts in other disciplines and use this new-found intelligence.

Some people prefer to work in teams that work differently, protecting their expertise and accepting delegation of responsibilities. Guarding expertise, however, compromises collaboration and hobbles a culture of learning, which is the core of an Agile culture.

Agile demands consensus-building, and teams must be prepared to provide honest feedback. Teams must accept that there will inevitably be failures at certain points, but they must move on and improve.

Is the meeting essential?

An Agile methodology advocates evolving development, CD and ongoing improvements so that developers can rapidly respond to customer feedback. Time management is crucial to Agile to meet deadlines.

Time spent in endless meetings could be better spent making changes within projects to speed up rollout to customers. To deal with “meeting choke,” Basefarm’s developer teams insist on concrete agendas to meetings beforehand. And meetings cannot be called with generic names such as “stand-up.”

“A few people on the team have worked in other teams where there were two-hour meetings every week to keep the department manager updated. We wanted our team to avoid this style of communication because it steals days of working time every week,” says Hedermark.

At Basefarm, the provisioning system is designed in such a way that any changes to a project are constrained by scope. This ensures that if something fails, it only does so inside the limited scope and doesn’t impact the whole project.

This has proved a very powerful approach for Basefarm, as it has allowed development teams to get rid of strict routines that were there to make people think before making a change and often demand a meeting be set up to discuss. Instead, it has looked to further introduce automated testing to perform such tasks.

Automated testing reduces risk and costs

With the increasing complexity of solutions, manual testing can have a prohibitive cost impact on projects, which is why more enterprises are opting for automated systems. The goal of automated testing is to improve software quality while testing faster and reducing costs.

A quality assurance (QA) regime was the first technical investment Basefarm made to enable CD, and it hasn’t looked back. Automated testing exchanges the quadratic cost of manual testing with a one-off payment and a small maintenance cost. “If you want hands-off installation of new versions, anyone would prefer to know that they work as well or better than the last one,” explains Hedermark.

The importance of communication with users

Communication with users can be difficult, but it is also imperative to clearly communicate with them to support them and harvest vital feedback.

Basefarm has been making its development team available to all its employees for some time via a chat channel to address issues as they arise and escalate any complex problems. The chat channel has stopped random interruptions with developers by users, which broke workflow and reduced productivity.

As well as providing a platform to discuss best practices, it’s been instrumental in creating a “safety net” to reassure users that changes being made at the development end will not interfere with their ability to work, according to Hedermark.

Be prepared for change

In his book, Toyota Kata, Mike Rother outlines examples of where manufacturing has hit a wall focusing too much on technology and not enough on change. Hedermark has worked hard to avoid these obstacles.

Toyota Kata is centered on growing people, teaching people how to learn and using that valuable learning to improve processes. This system is based on Toyota’s organizational setup, dubbed kata, that drives success with continuous improvement, innovation and adaption.

Change has now become a key focus in Basefarm’s development teams and has allowed CD to deliver more value in a much better way. Hedermark points out that other companies’ paths to CD and overall change may not be the same as his own. Accepting change, however, is the first mutual step.

Read part three of this three-part series where we look at automatizing workflows in a DevOps program.