Feature:

Creating an Agile, continuous integration friendly culture is the key to successful ALM

By Jason Tee

TheServerSide.com

As with most worthwhile objectives, achieving continuous integration (CI) and delivery requires more than wishful thinking and a an investment in some new software. In fact, incorporating an Agile, continuous approach into your organization requires a real and concerted cultural shift, a disruptive shift that is by no means simple to achieve . TheServerSide asked John Smart, the author of Jenkins: The Definitive Guide, and  Paul Swartout, the author of Continuous Delivery and DevOps: A Quickstart Guide , how organizations can achieve the cultural changes required to make Agile, continuous development and deployment a reality.

Continuous integration vs. continuous deployment vs. continuous development

There must be no blame-placing when things go wrong. It kills the good feeling and the trust. Allow for failure as long as you learn from it. 

Paul Swartout, author of Continuous Delivery and DevOps

To begin with, it's important to understand the actual processes your organization is trying to support before you go forward with trying to change the culture. If you're unclear on the distinctions between continuous integration, continuous development and continuous deployment, Smart provides a summary of the three processes that makes the distinctions between them clear.

"Continuous integration is basically building and testing your application every time you commit a change to version control. Continuous delivery is the principle that any commit, if it passes all the auto tests, should be a potentially valid release candidate. This really changes the way you think about releases. It's the reverse of traditional recommendations. For example, with a traditional Java project, it's done the other way around. You create a release candidate, do all the testing, see if it works, then throw away if it doesn't work. With continuous delivery you commit your changes, create the binary, and run tests. If they all pass, that binary is your release—you don't build a new, special version afterward. Continuous deployment takes things one step further. You are so confident in your tests that any version that passes the tests goes straight to production."

How much do tools matter?

While effective application lifecycle management (ALM) is founded on how an organization uses tools, processes and people together, most experts like to downplay the role of CI and Agile tools, and force adopters to focus more on the people and the process. Swartout says Jenkins, Hudson and many other solutions can provide similar functionality. The actual tool being used isn't important. What's important is that the team is allowed to figure out what works best for them "From a development management perspective, it's important not to prescribe which tools to use. If you force a tool onto engineers without their buy-in, it becomes a hindrance rather than a help."

Whatever fits best for the engineers is the best solution. From a managerial standpoint, the end goal isn't to be able to simply say the organization is doing continuous integration. The goal is to solve a business problem. Encourage the use of any tool that engineers feel will benefit them in solving a problem. Managers need to take a back seat and be facilitators instead of dictators. This is really a process for the engineers to run.

Changing the mindset of each team member

Continuous integration is basically building and testing your application every time you commit a change to version control. 

John Smart, author of Jenkins: The Definitive Guide

Continuous integration and deployment is a team effort, which means the cultural shift towards this type of software development process needs to encompass, at the very least, development, operations, and management in order to achieve success . Swartout says each group can take some convincing, but they will eventually all come on board when the benefits are presented to them in a way that makes sense from their perspective.

Developers are the craftsmen. They want to create something beautiful and functional. Point out that if they have live access, they can see things happening with the software they just created. Developers can get excited about the opportunity to see what their code is doing. It increases their pride of ownership.

SysOps engineers are the mechanics. They are really interested in networks and low level operating systems and like to understand how to keep things running. Let them know that using a continuous process means they have input into how the software is built and behaves. That way, when it goes on their platform, they already know how it runs.

Managers can be the toughest stakeholders to bring onboard the Agile and continuous delivery movement. They may be set in their ways, ticking boxes and hiding behind corporate rules and standards. Convincing them to change is all about building a relationship and playing to their strengths. Those corporate standards have a purpose, so make it easy for managers to tick the boxes. Work with your development and operations teams to make testing for compliance with the various rules and standards part of the non-functional requirements. When management sees that the process works, their trust and faith gets instilled in the system.

Above all, Swartout, says, "There must be no blame-placing when things go wrong. It kills the good feeling and the trust. Allow for failure as long as you learn from it." That's the takeaway message if organizations plan to create a cultural shift that embraces continuous integration and development. Teams will inevitably mess up along the way, but with lessons learned, the process will end up stronger as a result.

 

What challenges have you faced when trying to change the corporate culture? Let us know.

05 Feb 2014

Related Content

Related Resources