Yes. The interesting thing that we sort of always get is first of all, we’re not a Cloud company. We chose the name 13 years ago before “cloud” sort of even existed. That’s the first thing I’d like to say. What we really do is we help our customers deliver software faster and better. That’s really what we do. So we’ve, over the years, worked a lot with customers who want to become more agile.
So we’re sort of the tooling side of the Agile equation; there’s culture, there’s process. You know, culture is probably the hardest thing to do, I would say. I’d love to sell you Agile in a box but you’ll fail if you try to do it that way, right? So really, just kind of one leg of that stool and helping work with our customers, and generally, larger enterprise customers, legacy customers, those kinds of things.
I mean I think we’re in a really good place. I think we’re in a state now where Agile is absolutely credible and absolutely something that just about everybody strives to do, whether it’s Scrum or Kanban or what have you, little A agile is I like to say, as opposed to big A agile. And I think 10, 15 years ago we were just getting started on that journey. I think a lot of the larger companies in the world sort of assume, “Well, that’s not really for us. We’re a unicorn. We’re different. You don’t understand.”
I’ve heard that a million times. And I think what’s really changed, I would say especially in the last five years, is now you’ve got the giants, the General Motors, the General Electrics, the interesting companies like SpaceX and Tesla and all of these companies saying, “Look. This is clearly something that’s working for everybody out there in the industry. We need to be looking at that and doing that as well.” Agile has become an incredibly credible way to develop software. I mean I think that’s really exciting. It’s been fun to sort of be along for that ride.
3. Where the bottle-necks in Agile now?
I think what’s happening now is, and I don’t want to say that Agile is a solved problem, but what’s really happening now was we’re producing lots and lots of software and the bottle neck has started to become the delivery of that software to the end customer. Sort of the last mile if you will, whether it’s putting it into production on your website or getting it into the firmware of your device that goes into a box, that goes to Amazon or something that gets delivered over the air into your car or into your mobile device or your internet of things thing.
That’s really where a lot of the complexity comes now, and especially when you start dealing with embedded in IoT, you’re now dealing with not just software but hardware. So you have multiple pipelines that you have to manage. These things all kind of have to come together at one point sooner or later. I see that’s where a lot of the effort is now isn’t streamlining those processes, getting all of the manual interventions out of there, getting all of the hand-offs out of there, getting to the point where you really can do a commit of your code and automatically be in production, or whatever the end goal is. It may not be production. It may be deployed to your test environment or deployed to UAT environment or whatever the end goal is for that particular pipeline.
I think people are starting to spend a lot of time managing that as a pipeline from end to end and really wanted to have visibility from the product ownership up, down, into, where are we in our pipeline, why are we not in regression testing it, why are we not in preproduction yet, where are we, why are we stuck, and providing visibility into those kinds of things. And visibility, that’s sort of broadcast as opposed to, “Let’s have a meeting and decide where we are” kind of stuff. The automation of all of these things is really, I think, where a lot of the work is happening right now.
Shane:
The Agile principle of shortening the feedback loops.
Yes, absolutely. And I think what’s really exciting and what’s starting to happen now is we’re really starting to close the loop to on getting into production and then getting feedback from production data back in. You put something in the production. You’re doing metrics on some sort of KPIs on what you’re doing in production, whether it’s transaction rates or what have you. And then feeding that back into the development process in terms of, “Okay. We have a 10% increase in latency here. When did that happen? What push caused that? What line of code almost down to that level caused that?”
So you can really kind of close that loop and have great visibility. What that helps to do then is helps your meantime to recovery. So if you decide that 10% lag or latency is not acceptable, you have very quickly identified what the problem is and so you can very quickly remedy that situation. I think that’s very interesting to see our customers do.
4. What changes do organizations need to make to allow this to happen?
I think first and foremost, and I say this as a tools vendor, culture. Culture is the most important thing you need to worry about. You can buy all the tools in the world. You can have all the workflows and all the processes that you want, but you need to have a high trust low blame culture in order to do this because you’re going to screw up a lot as you’re on that journey. The whole point of doing this is we do one quarterly deployment. We want to get that to - we’re doing it daily. Well, guess what, you’re going to screw up a lot on that journey, and you have to do that in a culture that’s safe to do it in.
I think that’s really the most important thing that everybody needs to focus on, and that’s difficult to do because organizations report up through different structures, they have different ways that they’re measured. And I think what the Agile, and especially the DevOps community is focusing on a lot these days is what are the right kind of cultural aspects that you want to drive and that you want to pay attention to?
And then on the tooling side, I think there’s just one thing you want to focus on, and that’s automation. Get the human out of the loop. We absolutely, as humans, suck at typing the right command into the right window at the right time and not rebooting the wrong machine or pushing the wrong bits or all of that stuff. All of that should be just push button automated absolutely.
You know, it’s a journey, and in some sense, it depends on where you start. If you’re starting with highly siloed organizations and you’ve got to do some re-orgs and those kinds of things, then you’re looking at an 18-month, 2-year journey at least until you get from quarterly to daily, I would think. Anybody who tells you anything less is probably just trying to get the work. I think it really is kind of a difficult thing to do. If you’re a smaller team and if you’re already a little bit more agile, if you’re already not such a siloed organization and you have good relationships with all of the different components of the organization, then I think you can do these things in 6 months, 12 months, and those kinds of things.
But it is absolutely something that you need to -- you need to be agile about that transformation as well, right? You need to sit down and decide what your desired end state is, basically create a burn down list of all the organizational, cultural, process, tool, changes that we need to make, and then start working on that burn down chart just as you would, writing functionality for the software. So I think you need to --
Shane: You mean it’s not just buy a box and drop it in.
No. I mean I wish it would be. That would make my life a whole lot easier, let me tell you that, but it isn’t. And I think customers that come to us with the idea of, “We want to buy your software and then we want to leave doing waterfall on Friday and be Agile and DevOps on Monday.” I mean we kind of have to deliver the hard message of, “It’s not going to work. You’re going to fail, and you’re going to fail spectacularly.”
I think the other mistake that people make is they try to boil the ocean. They try to change everything all at once. And what you really want to do is kind of have the Agile mindset of, “Let’s fix one thing at a time”, sort of minimum viable product approach to this transformational journey that we’re on because it is a transformation. We, for generations, programmers have been taught to work a certain way. Program managers have been taught to work… You know, we’ve all been taught to work in a certain way, and it’s really difficult to pull yourself out of that mindset, and that’s how you’ve been measured, that’s how you’re used to working and you don’t want your cheese moved, and all of those kinds of things.
It’s challenging but the metrics say, especially if you look at say the state of DevOps report that Puppet Labs and Gene Kim in IT Revolution just put out, the companies that manage to do this, and not just the unicorns, not just the Googles and the Facebooks and all that, but real large enterprises that adopt these techniques and processes, they actually do better as a business as a result of this. It’s measurable. It is statistically significant. Their stock price does better, their revenues grow, they deliver more functionality, and they do better against their competitors.
And in a sense now that every company is a software company, nowadays, it’s really important to get that right because that’s where a lot of the innovation and a lot of the differentiation against your competitors is going to be delivered. Every car has a nice engine these days. It’s what the entertainment system and the Bluetooth integration. It’s what all of that stuff does and the lane changing. That’s where they’re differentiating these days. That’s all software, 300 million lines of code in a car, you know, 50 processors in a car. It’s a pretty stunning amount of software that goes into these products.
I’ll come back to culture again. I think that’s one of them. I’ve definitely seen organizations where they send all of their engineers to Agile training and they do their stand-ups every day, and now they’re doing Agile. I call it sort of the Cargo Cult Agile, because we put the coconut earmuffs on our heads, good things will happen, and that obviously just isn’t the case. You really have to drive that change through the organization and through the organizations.
And if possible, reorganize the way that you’re structured as an organization. If you’ve got Ops people on one side of the building or one side of the world and Dev people on the other side of the building or the world, that’s difficult. Somehow, those two things have to come together, whether physically or by video conferencing or just a closer relationship with each other is really important. I think that’s the part that takes time. And I think that’s the part that people really underestimate how long that takes. Rolling out a new tool is you do that in a week or a month or maybe a little bit longer if you’re dealing with a very large enterprise.
But the cultural changes are the ones that you really have to pay attention to. You’ve got to find your champions. You’ve got to find the anti-champions and figure out how to deal with them, hopefully, make them your friend or move them aside if you have to do that. That is the most challenging aspect I find. And it’s also a hard one because you can look at cycle times, you can look at how agile are we and what size are our teams and how many Scrum masters do we have and all of those kinds of things. Those are easy things to look at.
Culture is this amorphous thing that unless you’re in the midst of it, you have no way to observe it. I think one message that I heard yesterday, which I thought was really good, was where people have really succeeded is where they don’t just send everybody to training but they bring coaches in, and have the coaches work with the teams for an extended period of time. One period of time I heard was 12 weeks so that you just don’t go to class for a week and then come back and try to do it on your own. You’ve got somebody who’s kind of top of you the whole time saying, “No, no, no. Here’s really the way we should be doing this and remember we talked about this and that.”
That starts to kind of wear in that groove of really doing it correctly. I think companies that do that tend to succeed very much more than the ones that sort of just go to class, come back, now you’re different.
Shane: Great! Coming back to Electric Cloud, the company and the tool, tell us a little bit about any new and innovative or exciting things that are happening with the product.
Yes. We’re doing lots of things. We’ve just brought out a new release where you get a pipeline view of your entire process. So you can visually lay out what your software pipeline looks like, what your stages are, all of those things, and that drops down all the way down to the execution of all of those stages. So your build, your test, your deploy, anything that you do in between including all of the execution of all of those things. You literally can drill down from, “We should be in UAT by now but we’re not, we’re here. Well, why is that? Well, we had a test failure last night. Engineers are looking at it.”
So you really get a top-down view of where you are, as well as the execution and the monitoring of all of those things. And working a lot also on our build acceleration tool, ElectricAccelerator which were always -- that’s actually one of the most fun products to work with in some sense because we can do really transformative things with the organizations because we go in and you’ve got a six-hour build. When we’re done, we’ve parallelized and distributed that build and it takes 20 minutes. That’s a game changer. That really allows you now to start looking at other processes and being more agile and those kinds of things.
So between the ElectricFlow product and ElectricAccelerator, it’s just a lot of fun to work with customers because when you have those successes and they come back to you and say, “Well, here’s ROI that we calculated and it exceeds even what we thought it would be.” That’s a lot of fun, I have to say.
Shane: Great! Anders, thanks for taking the time to talk to us today.
My pleasure.
Shane: Enjoy the rest of the conference.
Thank you very much.