We had the pleasure, for IBM InterConnect 2015, to speak with Dibbe Edwards, vice president, Rational Software Development about the success IBM has had in implementing DevOps processes within their organization. In her current role, Edwards is responsible for leading Rational’s development business that includes application lifecycle management and reporting, quality and requirements management, systems development and architecture management, and integration and open software development across both the IT and Systems domains.
Here is our conversation with Edwards about IBM’s internal DevOps transformation and the importance of, and challenges associated with, standardizing on tools, process, and technology to build DevOps success.
devopsy.kinsta.cloud: Can you tell us a little about what your presentation will be about on Tuesday? It’s about how IBM has led its own internal DevOps transformation, and I think that is something that would be of great interest to devopsy.kinsta.cloud readers.
Edwards: From an IBM perspective, we’re moving aggressively towards adopting DevOps practices. We have a larger software group, DevOps Center of Competency. The group is really taking these practices and the transformation efforts and rolling them throughout IBM. The session and the talk will kick off about that, and transformation at scale across the entire IBM company.
devopsy.kinsta.cloud: In a presentation you gave at DevOps Enterprise Summit, you highlighted the challenge of standardization as one of the top three challenges in an enterprise move to DevOps. Could you share a little about what you meant by that for our readers, and maybe some of the lessons learned at IBM as you worked to standardize your people, processes, and toolsets.
Edwards: We talk about how there are three elements to any transformation. That’s the process or the ways of working. There’s the culture of getting people to think differently and work differently. And then there are the tools. It has to be a combination of those three things that will drive any sort of successful transformation, you can’t really do one very well without the other.
So standardization, or coming to a common way of achieving DevOps practices, is an important aspect because it gets people speaking the same languages. You’re able to have, then, a single version of the truth in terms of the viability of the project and where you’re going and you know that you’re communicating effectively. That’s been an important part of us being able to not only get this off the ground, but be able to scale it up at a company the size of IBM.
devopsy.kinsta.cloud: What were some of the challenges that IBM encountered working to standardize? Did you identify those processes that worked and saw that they could be applied horizontally and then slowly put them in place across the different groups? How did you get buy-in to do that?
Edwards: I would say the culture and the ways of working, or process, go hand in hand. I think if you don’t view that that’s the case, than you are in for a real challenge. If you try to just write down a bunch of processes and apply them in an organization without acknowledging and understanding the culture of that organization you are going to run into a lot of challenges. And getting buy-in from the organization is also a very essential part of it.
What I’ve done in many of the organizations to drive towards a more standard way of working and modifying the process is to get the teams personally involved. What we did as a part of our transformation in both the web organization as well as the Rational team is start with a look at our current process and look at what was working and what was not working.
We had set our business objectives. We wanted to deliver more quickly. We were delivering once per year. We wanted to deliver on a quarterly basis to speed up our time to market and get more valuable capability in the hands of our clients. We wanted to eliminate waste. That meant spending more money on innovation and less money on maintenance.
What we did is we looked at our process from beginning to end. That meant everything from how we worked with our product management team, who help us make our business decisions and set our investment priorities, to a complete analysis of our development process, our testing process and our deployment process. We looked at those and we said, “What are the biggest inhibitors to us moving fast?”
We built very specific plans. We actually established work group leaders to go and bring in other members of the team to determine how to go about addressing any inhibitors. We just started picking the biggest inhibitors, the ones that were our biggest pain points and put plans in place to address those.
I think one of the important things about this is that you have to recognize that in order to improve the situation, you have to prioritize those investments along with your product investments. From our perspective, it certainly wasn’t something that could happen overnight. You also can’t stop the delivery train while you’re doing all this stuff. So, it has to be prioritized alongside the other work that you’re doing.
Then the key thing is once you establish what your key focus areas are and you have the buy-in from the teams and recommendations from the different work groups, you begin to implement those things. At the end of each one of your sprints, you reflect on how you did and reflect on the improvements that you’ve been able to make and you identify your next set of inhibitors.
It really then becomes a focus on continuous improvement, gaining momentum and reporting on whether you are really removing the inhibitors that you set out to remove.
devopsy.kinsta.cloud: Are there a specific set of challenges around a large organization standardizing on toolsets?
Edwards: One of the things that we’re big believers of in IBM and even within my organization and other parts of IBM is that there are certain things that you need to standardize on. If you’re managing a large program, you need to have the ability to, like I said, have a single version of the truth on the status of the project. So, things like how you do the tracking of your work, your dashboards and how you report on things, how you track your defects. The definition of a sev-1 defect should be consistent across teams that work together.
But then underneath that, there’s flexibility that we give our teams in terms of tools that they might want to use. As an example, we support Git with our products. Sometimes we acquire companies and they want to use Git as their source code management repository. We’re okay with that. We just need to have this single sort of way to govern and manage the projects so we know that we’re meeting our business commitments and quality commitments that we make to the business.
Another example is, from a testing point of view, I use in my organization Selenium for some of our automated testing because it was a solution that worked best for the type of Web-based situation that I have. We use some page object frameworks, which is a principle that is supported in Selenium. It helped us to be more efficient.
The message I wanted to come across is that standardization is important with tools, but it doesn’t mean that every single thing has to be from the same vendor and it doesn’t mean that you can’t bring in things that work really well for your particular team. That’s another thing, I think, that helps from a cultural point of view is that there are some things that people can be pretty passionate about or have been effective for them in the past and bringing them into this overall governance structure is something that has helped us also sort of break down some barriers around people wanting to move forward with new approaches.
devopsy.kinsta.cloud: What helps drive the cultural shift? I would imagine success begets success. When teams start to see success with other teams it probably makes it easier to get buy-in horizontally through the organization.
Edwards: That’s true. There are multiple aspects of that as well. One of the key things that I have always believed in with the team is that you need to have some quick wins because, like you said, success breeds success. If you can get some good momentum under your belt with something that really has a positive impact, then it will get other people to buy-in.
As an example, one of the things I talk about is our build time. It was a very frustrating thing that touched every developer and every tester in our organization because it took them a really long time to get a build. That was viewed as one of our key inhibitors. We spent quite a bit of concerted effort focusing on eliminating the amount of time that it takes to get a build. In many organizations, that can be an inhibitor.
We had to invest in multiple different ways, but our initial leap was from 36 hours to 12 hours, which is huge, and along the way we had incremental improvements. Every time it got faster, it built more momentum and more excitement on the team and they could see immediate productivity impacts in a positive way for themselves.
Another key area for us was implementing the use of patterns in our test organization. We found we were spending a tremendous amount of time setting up the test environments where we needed to actually validate our product and customer-like scenarios. One example is it took us 30 hours to setup an environment because we were doing it manually.
We were able to implement patterns, which took us some time to build, but once we had those in place, we were able to deploy those environments in an automated way in three hours. We could then spend that 27 hours doing useful, constructive testing and being able to be more creative with our testing and finding more problems and being able to test so much earlier.
Those are examples of things that were real momentum gainers for us.
devopsy.kinsta.cloud: That’s fantastic. I think you’ve shared a lot of useful information for people who are thinking about going down this path. I would like to ask you about one objection, or belief, that repeatedly comes up in my conversations with enterprises. They’ll say that they can’t embrace DevOps in their organization because they don’t have the resources. They’ll say “Well, that’s Netflix or that’s Amazon doing those things or that’s IBM, a software development company doing that. We can’t do that because our core competency isn’t software development.” What’s your response to those types of positions?
Edwards: Definitely. I think as I look at this, I’ve spoken had, myself, almost 50 briefings last year just talking to clients about this topic. People in every single type of business, everything from manufacturing to banking to insurance to retail, everyone is under a similar pressure: “How do I respond more quickly to the market? How do I make my company more competitive?”
The reality is that IT is a very critical part of that today. There was a point where maybe IT wasn’t a differentiator. But today, IT is absolutely core. So, what is this all about? It’s about being able to be more agile and interact more rapidly with their clients and provide value-added capabilities to them and get their feedback. I think that certainly the business need is there.
Now, as you start to think about some of the companies that aren’t running their business off of this, we talk a lot about some of the challenges: like how do you get the stakeholders brought in to want to participate in doing this type of development? What I’ve seen with many clients that are not “IT companies” is that they usually start with a pilot of some project that’s a reasonable size. And they have agreement from their business stakeholders and from the IT organization and they bring all their testers and developers and their operations and their business stakeholders together and they run some pilot projects.
When they do that, the types of results I have heard insurance companies and banks have from such pilot teams have been outstanding. They’ve been able to get wonderful feedback from their stakeholders around how much more the application that was being built addressed their business needs. How they got into production so much faster.
The types of results were excellent. That has helped, I’ve found, to drive the momentum to other parts of those of businesses. Because at the end of the day, just like the rest of us, it’s about return on investment. It’s about having confidence that what you’re doing is the right thing. This process is really about helping to shine the light on that. And using these types of DevOps approaches is about doing that.
