The following is a guest blog post from Lynn Coffin, senior technical program manager, and Peter Tiegs, principal engineer, at Intel Client Group.
While Intel Corporation is universally known for its market-leading semiconductors, the company also produces a vast amount of software to support its business mission. In the company’s Client Group – where we work – engineers build and deliver software used in gaming, education, business and mobile applications – and much more.
It’s a big job. Any given product may have up to 60 different software and firmware components, all designed and built by thousands of software engineers around the globe. It’s no surprise, then, that we wanted to make this process as efficient and scalable as possible. That’s why a couple years ago we launched a program to transform the way we build and deliver software, replacing a largely manual process that couldn’t keep up with the performance demands of modern continuous integration.
Three teams formed the human engine that drove our transformation. Our Systems Engineering team was tasked with defining the software and firmware that made up each product. A second Test and Release team focused on standardizing test reporting between the software and firmware teams and managing the flow of new components. The team’s goal: Continuously deploy software to customers in a way they wanted to receive it. Finally, our Source and Build team leveraged DevOps practices to equip the software and firmware teams with the tools and the training they needed to do their jobs.
One of our most successful moves was deciding to build our hybrid cloud solution on top of Kubernetes, the container-based environment embraced by a growing number of development organizations. Today, we have CloudBees CI solutions running around the world on top of our Kubernetes cluster. To remove adoption barriers, we created a set of reusable libraries – we call them our Abstract Build Interface – so that the common activities, such as security scans, could be implemented once and then reused.
Lessons learned from our transformation
Over the last two years, we’ve learned a lot from our transformation project. Perhaps the most important lesson was simply this: Don’t be afraid to get started. You don’t have to have all of the answers and know everything before you take the plunge.
You also don’t have to go big. Instead, you can go small and break the project into manageable bites. It also pays to start with a group of people who are excited to tackle the challenge and who buy into the value of what you’re trying to do.
Probably one of the hardest things to do is change human behavior, but that’s exactly what these projects entail. So it’s important to chart the road ahead and try to make it a “safe” journey with stops along the way for training and communication – and for reflection. Don’t forget the last part: Reflection is crucial to any successful transformation. Reserve some time to step back, take a look at what you and your team have accomplished and adjust to the change you just went through.
It’s also essential to be clear and deliberate in what you say and do. Teams rely on you to be their “north star” so you need to step up to that role and be clear, steady and consistent in your messages. Articulate where you’re going – the end state – and communicate it again and again.
Trust us: You can’t over-socialized it. Print it out, post it on your office wall and next to the coffee machine in the breakroom (that is, when we all return to our offices!). Make sure everybody understands what the end state looks like and why it’s important to get there.
Short measurable wins
Remember large-scale transformations are a journey, not a quick dash, so keeping people motivated along the way is key. We found that chalking up short, measurable wins can help the team stay engaged and keep spirits high. Using agile and scrum methods that emphasize iterative delivery is a big help here. We can look back at what we did previously and understand why we made certain decisions. Then we can build upon them or change our course pretty easily without significant impacts.
Finally, having solid executive support makes a huge difference. Our senior director and several vice presidents in our group supported our effort wholeheartedly. They understood the end state and bought into it. We also got support from the vast majority of developers, who saw how easy life would be once we started sharing source code and using common tools.
Here on the DevOps team, we often joke that we were the creamy center in the middle of that Oreo that really made the transformation project a sweet success.
Check out Lynn and Peter's presentation - "Enterprise DevOps Transformation: Scale or Fail" - from DevOps World.