DevOps isn’t a new adventure for us at PTC. We first started our DevOps journey about four years ago with a team that was primarily focused on release management, software deployment, and automation of these two functions across the development team.
We started early, but I wouldn’t say we crossed the finish line with that first iteration. We incorporated some automation tools, software packaging, and release management, but it was more ad hoc and informal. We knew we needed to refocus our DevOps efforts, and have spent the last 18 months doing just that.
Lessons from the second leg of our DevOps journey
Our focus with DevOps 2.0 has centered around CI/CD and continuous testing across all the scrum teams in IT. The DevOps function has been really impactful in bringing a consistent approach across product lines and multiple technical platforms.
Today we’re a little more than halfway done with our DevOps 2.0 journey. We still have a lot of work to do, particularly around bringing all teams up to the same level of maturity to ensure a consistent level of performance, expectation, and velocity. We’ve made a lot of progress in our journey and have learned some valuable lessons along the way.
[ Get our free eBooks: DevOps Hiring: The Ultimate Guide and IT job searching in 2019: A practical guide. ]
Lesson 1: Prioritize change management
When we first dove into DevOps several years ago we underestimated the importance of change management across the various teams. Instead, our focus was misplaced on best practices, tools, and new processes.
If I could go back and do things differently, I’d place a stronger focus on change management to help each of the teams and individuals understand how their role has changed. This would also include finding teams that are true champions and enlisting them to show other teams the path to success. It would mean identifying some early successes, finding out why some teams were more successful in adopting best practices, and promoting those ideas more so we could demonstrate the benefits across all the teams, ensuring that they’re all at the same level.
This time around, we focused on exactly that – helping individuals and teams understand how their roles have changed, and what that means for them moving forward.
Lesson 2: Do agile and DevOps concurrently
You can’t do agile before DevOps, and you can’t do DevOps before agile; they need to be done at the same time. Here’s why: Agile practices around development, like having product owners and scrum teams, will come to a screeching halt if CI/CD is not deployed fully.
You need to take both of those practices and move them along concurrently. They’re so tightly integrated that you can’t really separate them. During our original foray into DevOps, we tried to focus on operations first, without the upstream development using agile. That’s why there was a mismatch in collaboration with these teams, and collaboration is very, very key in order for DevOps to be successful.
[ Read also: Agile vs. DevOps: What’s the difference? ]
Lesson 3: Consider geolocations
We discovered that teams that were farther away from the center of gravity — Boston, in our case — should have more focus on training and adoption. Otherwise, messaging gets diluted, which we found was a factor that impacted adoption. Team members who were farther away were less-immersed in the day-to-day processes than those who were geographically closer.
Lesson 4: Prioritize training
If you have multiple teams working on a single project and there’s a different level of maturity across this teams, the weakest team drags down the entire project. We learned this lesson the hard way.
It wasn’t easy for us to figure out why velocity was slow, but we ultimately discovered that it was due in part to the differing levels of maturity across those teams. This time around, it was essential for us to make sure all teams were up to speed first. That’s where training came into play.
We had three focuses for training: First, we rolled agile into our journey and got it adopted across all teams via a consistent practice to ensure everyone was up to speed. Second, we ensured everyone was on the same page with CI/CD from both a best-practices and a tools standpoint. Finally, we looked at how their work changed with the adoption of these new practices. This highlighted how they did things before, and how they’d do things differently.
[ What tools help support scrum, kanban, and other agile methods? Read also: Top 7 open source project management tools for agile teams. ]
What's next
When we relaunched our focus on DevOps, we did so deliberately, announcing the roles that were changing that would help us focus on this new way of doing things. There was a lot of communication across all teams, and we even went on a roadshow to talk about how we’d be deploying this and the benefits of relaunching it in a different way.
I was also very transparent with my direct reports about areas in which we needed to improve. This was part of the culture I’ve developed at PTC – never minimizing or maximizing our successes or failures. We don’t need to mince words or soften things up: Let’s just admit it, learn from it, and move on.
For others on this journey, it’s important to understand that every organization is different. You need to look at yours and your culture to determine how best to adopt DevOps to your organization. The same model might not work everywhere.
Every IT organization needs to undertake this journey, however. It’s just too impactful not to. At PTC, for example, our speed of deployment has increased considerably. We used to do quarterly releases for some of our major applications and now we have a major release every month.
Business demands are increasing and IT teams need to be more flexible while maintaining error-free control. The only way to do this is with a very deliberate process – the adoption of good DevOps practices and good agile practices.
[ What do great agile leaders do differently? Read How to be a stronger DevOps leader: 9 tips. ]
