Keep CALMS and DevOps Ons -- ADTmag

Keep CALMS and DevOps Ons

There has been a lot of misinformation about the nature of DevOps and its relationship to (Big A) Agile. Our Agile Architect explains why DevOps is an important component of (little a) agile, plus offers the top five DevOps misconceptions dev teams often have.

By
May 29, 2018

By Mark J. Balbes, Ph.D.

You are a software developer in an agile shop. You've got a collocated team consisting of developers, QA, UX, and an agile coach. You follow all the agile technical practices. Not only is your team agile, but so is your code. You are very proud of the fact that it has been written so it can be deployed in almost any environment anywhere.

You've gathered with your team around your Kanban board for a special ceremony. With a flourish, your teammate moves the last story card across the board to the "Done" column. "That's it. We are done!" he declares. "Huzzah" cries the team. "Well done!" says your manager.

"Um," says a meek voice from the corner. It's the new guy. "How can we be done when we aren't in production?"

"We don't need to be in production to be done," says one of your more experienced colleagues. "We can deploy this everywhere."

"Yes," continues the new guy, somewhat perplexed, "but we aren't deployed in production anywhere."

Enter DevOps
Agile teams have always had the desire to perform their work to completion, coining the phrase "done done" to indicate that all the i's have been dotted and t's crossed. "Done but" was the call of the non-agile. In order to be truly done, in order to provide value to users as per the agile manifesto, the software had to be deployed into production. So developers started to create software development techniques and build tools to automate tasks beyond software development. A desire for continuous integration and automated builds led to tools like Cruise Control, predecessor to modern tools like Jenkins, GitLab CI and Team Foundation Server.

But for many agile teams "done done" meant that the deployment artifacts were built and ready to hand off to an operations team to be deployed to production. It was up to the operations team to go the last mile. And that's when new problems would pop up that would send the software back into development or cause delays as new hardware had to be ordered or network rules had to be rewritten or security issues had to be addressed or, or, or…

Just as QA, UX and product ownership had been more tightly integrated into the development process, it was clear that operations also had to be integrated. And try as developers might to fill this role on their team, they do not have the same expertise or even interest in operations as those that have dedicated themselves to the role. Thus operations IT professionals working closely with software development teams became more and more exposed to the techniques of software developers and recognized that they could adapt them for their own purposes.

But as important as tooling and automation are, DevOps is more. DevOps is about embracing the agile culture of collaboration to deliver value to users. A common mnemonic for this is CALMS -- Culture, Automation, Lean, Measurement and Sharing. Atlassian has a nice article on CALMS here.

That's my short software developer perspective on the origins of DevOps. For an operations point of view, go here.

5 DevOps Misconceptions

1. DevOps Is The Shiny New Term for Automation
As we see from CALMS, DevOps is much more than automation. Automation via scripting has been a part of IT operations for almost as long as the barriers between software teams and operations teams have existed.

2. DevOps and Agile Are Competing Methodologies
I read a survey recently that was trying to measure whether IT departments were waterfall, agile or DevOps. This is a fundamentally flawed question since agile and DevOps are not in competition. You can embrace either without the other but the true power comes in embracing both.

3. DevOps Is a Role
I think one of my colleagues goes to sleep at night chanting "DevOps is not a role." It's not something assigned to a person. There is no "DevOps guy." At Asynchrony we do have the role of delivery engineer. They are similar to our agile coaches in that they are responsible for fostering our DevOps culture among all of our teams. Fortunately for us, they are also awesome at IT operations stuff. This can be confusing, fostering this notion that they really are our DevOps guys. They work hard to defuse this notion by embedding with and pairing within delivery teams.

4. Just Rename Your Operations Team to Your DevOps Team
DevOps belongs to the delivery team consisting of people with skills in software development, IT operations, QA, UX and product ownership. Skills can be distributed amongst the team. It is the team that builds the automation around their software and embracing both the agile and DevOps cultures.

5. We Don't Need DevOps
Really?

Final Thoughts
DevOps is the new shiny buzzword. And just like the term agile, it is sure to get misused, misunderstood, contorted, and commercialized.

If you are moving to a DevOps culture, then to be successful you also need to embrace an agile culture.

If you already have an agile culture, you are probably looking at the DevOps movement thinking "What's the big deal?" since you probably already embrace DevOps principles. We just didn't have a word for it until recently.

If you work in a highly regulated industry like healthcare and think DevOps doesn't apply to you, take another look. While you may never be able to fully exploit the value of DevOps, for example to get to a continuous delivery process, it can get you a lot farther than you are right now, saving you both time and money.