A blueprint for DevOps success: How Rosetta Stone implemented continuous delivery

Rosetta Stone translated a move to continuous delivery. Here's what the company learned.

Plenty of companies are considering a move to continuous delivery. In planning such a process change, it helps to listen to someone who already understands the language. At the recent Jenkins World conference, Kevin Burnett, DevOps lead at Rosetta Stone, shared tips and lessons learned, with particular resonance for those who manage DevOps and other technical teams.

At Rosetta Stone, best known for its software that teaches foreign languages, Burnett learned to sell other IT staff on the benefits of DevOps, set expectations accurately, and empower the staff—all with only two people working on automation full time.

The move to continuous delivery wasn’t all a smooth ride. It required a careful transition to win over the holdouts. Rosetta Stone implemented a series of small, continuous delivery pilots that were very successful; those were followed by measured rollouts across teams.

Everything works, so why move to continuous delivery?

Before continuous delivery, Rosetta Stone’s developers would work on a project for two weeks, typically followed by another two weeks of testing. “This turned deployment into a big event,” says Burnett. As a result, more people got involved, even if they weren’t that close to the code. That, in turn, increased the likelihood of something going wrong.

Plus, fixing any problems was difficult. Simply rolling back the code usually was not an option. “We were rolling everything as an atomic unit,” Burnett says. “In order to go back, everything had to go back, including features and bug fixes from different teams. We learned that the larger the change, the more impractical rollback became.”

Nevertheless, when you already have a decent process in place, colleagues can be resistant to change. “We had a very strong release cadence of every two weeks like clockwork,” Burnett says.

With any big change, some folks are bound to ask, “How is this going to screw up the good thing we had going?”

But at Rosetta Stone, the in-house developers understood the benefits of continuous delivery: Making small changes and testing frequently is better than trying to debug a big, established project with many people involved.

Burnett is one of only two people focused on DevOps full time. The small team—just two people!—means it’s more important to be responsive. “We try to always be available within minutes, because getting people unblocked is very important to us,” he says.

Playing it SAFE

However, Burnett assumed everyone understood the benefits and did several things to win people over to continuous delivery.

First, Burnett was careful not to oversell it. “We tried to impress on people that we weren’t going to eliminate production failures—they would always be there—and that if we wait to change until conditions are perfect, we’d be waiting a long time,” he says.

He and his DevOps colleague also regularly met face-to-face with members of the product team. They used a process called Scaled Agile Framework (SAFE), which encourages quarterly planning meetings.

“The meetings are always face-to-face and a bit unconventional,” says Burnett. “There’s a lot of unstructured time—which is actually perfect if you are looking to foment a revolution,” he adds with a grin.

Unsure how to get started with containers? Yes, we have a guide for that.

During these meetings, Burnett likes to toss out “audacious goals” and ask for help achieving them. “Then we would just talk to as many people as we could to get excited about our future plans,” he says. He worked to find early adopters and advocates, then adapted the DevOps plans based on the feedback received.

Small team? No problem

DevOps often is managed by much larger teams. Since taking the job two years ago, Burnett realized he could make the DevOps team bigger than it is on paper by finding able, sympathetic, and supportive people within the company.

At Rosetta Stone, early adopters became huge advocates of the company’s switch to continuous delivery; the users see its benefits and contributed to the team’s efforts. “So we are always trying to grow the DevOps group without actually growing the DevOps group,” Burnett says.

“You must find allies,” he adds. “Change efforts like DevOps transformation can fail for myriad reasons—lack of assistance, lack of energy, and so on. But all of these obstacles are best overcome with lots of support.”

One excellent source of “recruits” has come from the Rosetta Stone quality assurance group. The QA and testing team did a huge amount of organizational change work, from scaling teams and organizational delivery to codifying test data, Burnett says. “Really, nothing of any consequence would have happened without their support and participation.”

And as any personal networking expert will tell you, if you want help, be the first to offer assistance. Burnett’s group greased the wheels by volunteering to help operations people and QA with their projects. When it came time to push DevOps initiatives, QA was much more receptive.

Autonomy, mastery, and purpose

In his book "Drive: The Surprising Truth About What Motivates Us," author Daniel Pink wrote that autonomy, mastery, and purpose are key to motivation.

Burnett is a believer, particularly when it comes to autonomy. “Autonomy is wonderful. I don’t know how common it is for people doing DevOps work to both be defining and executing on a vision, but it’s had a super-positive impact on our work lives.” If you are directly or indirectly managing a DevOps team (or possibly any team), this is a chance to make a difference by letting your people generate their own requirements, he says.

Burnett understands the reluctance to (in some eyes) let the inmates run the asylum, However, his experience is that giving staff a say—letting them choose how to approach projects rather than dictate the requirements—is a great way to tap underutilized creativity and skills. “Technologists care about how they do their work and how well the software pipeline functions,” he says. “I strongly suspect you can think of people in your organization who could do greater things if they had the opportunity to spend their time in a different way.”

The end result? “Most of the company is now doing continuous delivery. We’re releasing multiple times a day; and each change is small and low risk,” says Burnett. “Continuous delivery is seen as a success almost universally by our stakeholders.”

Lessons for leaders

  • Take time to communicate the benefits of DevOps, and get stakeholders on board.
  • Find allies who share in DevOps goals and values. Empower them.
  • Manage expectations so that nobody is disappointed or surprised.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.