In 2014, IBM opened its first IBM Garage (then known as the Bluemix Garage) at the San Francisco branch of Galvanize. Embedded within popular startup incubators, IBM’s Garages serve as consultancies for clients who want to experiment with new technologies and ultimately change the way their companies build applications. Today, IBM has Garages located in 15 major cities around the world. As part of our series on how engineering teams work and collaborate, Stack Overflow Engineering Manager, Sara Chipps, spoke with Chris Lazzaro to discuss IBM’s approach to cloud-based operations. Chris shared why he’s enthusiastic about the future of DevOps across all sectors and industries.
Sara Chipps: Tell me a little bit about yourself and what you do? Chris Lazzaro: I’m the Lead Architect for IBM’s Garage Methodology platform. The method provides clients prescriptive guidance on how to transform their business by combining industry best practices, architecture implementations, and cloud adoption expertise. Our Methodology describes the best practices from Design Thinking, Lean, Agile, and DevOps that clients experience firsthand when they visit one of the IBM Garages. Our Garages provide an immersive experience in an environment that operates like a startup. This was the inspiration for the name “Garage.” We love the type of clients that come to a Garage. Our clients want to learn how to truly transform their teams, rather than simply paying a consultant to do everything for them. After they build their minimum viable product or MVP (a small application that demonstrates this key value), they become a resource to the rest of their organization. Their hands-on experience in the Garage shows them how things can be done differently with a focus on innovation and new technology. The Garage Methodology formalizes and helps to train them in that process while providing guidance to help them scale their initial success.
What do you find is the biggest hurdle for these companies? Is there a common challenge you find that people normally face or is it different depending on the company It’s often an eye-opening experience to see the success of a well-functioning team, and that is why we often recommend that the first step is to establish a reference point, even if it’s a small group. The next hurdle is to answer the question, "How do you scale that success across the rest of the organization?" You might have a pocket of people that are really leading innovation, doing things in new ways and adopting new technologies. It is important to recognize the reference team and to provide executive support to ensure they don’t fall back into old ways of doing things. In the Method, we say to a DevOps team, "We want you to be autonomous and empowered to make the right decisions for your service, but we also want you to follow this set of practices." There is a danger that people feel like we’re actually adding additional governance. So it is important that we strike a balance between helping teams realize that the process that enables agility also needs consistency. Otherwise, different teams start doing things in different ways or fall back into old habits, or adopt practices that might actually make it harder to reach their transformation goals. How long is the IBM Garage usually with them through the process? An engagement often starts by working with a team to identify their biggest business problems. From there, you might have what we call a Design Thinking Workshop. We’ll work through a set of design-focused brainstorming to figure out how to deliver the most value in the least amount of time. Then, we’ll work with the client to actually build the MVP, which can be anywhere from four to ten weeks. This is often just a starting point that leads to a larger engagement to tackle other business challenges that exercises and hardens the agile skills and practices of the team. You listed a few things that you introduced to teams, including different technologies and styles of working. What makes the biggest difference on teams that have more antiquated processes? You really need to identify and knock down each potential obstacle. One of the biggest challenges used to be getting the right infrastructure in place and scaling up that infrastructure when it proved it worked. Even with virtualization, you have limits on how many VMs you can spin up in a given data center. IBM Cloud allows you to start out very small, pay for what you're actually using, and then quickly scale as much as you need. Then you should start looking at your development processes and how automation can help, especially things like test-driven development and automated pipelines. From there, it’s important to make sure that you're not just building things faster, but that you're actually incorporating Design Thinking to build the right application that solves your customer's needs. Are those barriers sometimes people? Is this sometimes not a technology problem, but a people problem? Yeah, absolutely. Culture change is at the heart of a transformation. An executive might be used to looking at a one-year road map that has deliverables each month and using that as a way of gauging the success of the team. It’s really important for that executive to understand that their teams have a business value that they need to deliver against, but they're working much more independently and responding to changing needs much faster. The one-year roadmap becomes useless pretty quickly as teams learn and adapt as they develop. At the team level, developers need to be able to work in an environment that’s constantly changing. They might be working on a feature that was expected to resonate with customers, but because the metrics show it’s not having the effect expected – now it needs to change. It requires a certain kind of person to thrive in that environment. That makes sense. Is there anything you would say to an organization that is considering making changes like this to prepare for working with a team like yours? I’d start by asking a lot of questions. Often times, organizations will simply look to reduce costs, get rid of data centers, and move everything into the cloud. That's an easy first step and that's where a lot of enterprises are today. But what’s the broader vision of how the cloud enables your developers to build applications? And what do you envision for your existing applications? Do you just want to run them in the cloud or do you want to look at how the cloud can enable a large-scale modernization? More and more, we’re finding a hybrid cloud approach makes sense for many phases along a client’s cloud journey.
What are some new things happening in the world of DevOps, in Cloud development, or Architecture that you're excited about? I’m really excited about the flexibility of cloud infrastructure. As organizations become more cloud-native, they might realize they need to stay behind the firewall in their enterprise for some things. Or they get nervous because they don’t want their entire business dependent on just one third-party, so now they're adopting a second cloud provider for different things. How does a company manage workloads and manage environments across all of these? It's complex, but then you can harness the power of a hybrid and multi-cloud infrastructure. Clients can be independent and avoid being locked into a single cloud vendor and they can keep the services and data in a private cloud that can remain private to their enterprise. Is there anything you're reading or any podcasts you're listening to right now that you're excited about? I just picked up a book that O'Reilly published on cloud-native DevOps with Kubernetes. It's not too deep, but it looks at a variety of ways that DevOps changes depending on how your application is built and the infrastructure you’re using. Do you often read O'Reilly books? Different people learn things in different ways. Do you find that you are a book learner? I tend to be more of a hands-on learner and wanting to try things as I go. Books help with that, but a lot of cloud-based interactive environments can actually create new learning experiences where you're learning a technology and using it at the same time. Last question, what's something keeping you up at night right now? Balancing consistency versus flexibility. What’s the right amount of process to enable a team to feel like they don't have too much overhead, but also have the framework they need to build great applications? How can we equip them to push back on that executive that's saying, "Hey I need your one-year plan?" We want them to be able to say, "We’re not following that waterfall process. We all agreed as part of this transformation effort, we're now following the Garage Methodology, which incorporates these new practices." This interview has been edited for clarity.