DevOps Chat: Value Stream Management in the Enterprise with Plutora

Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today I’m joined by Bob Davis, chief marketing officer at Plutora. Our topic is an interesting one. We all talk about DevOps in organizations, but how do you achieve high performance DevOps. Bob, welcome to DevOps Chat.

Bob Davis: Hi, Mitch. It is great to be here. Thanks for including me in your agenda for the DevOps talks.

Ashley: The honor is mine. Appreciate you being here, Bob, definitely. Would you start–have you introduce yourself. Tell us a little bit about what you do as chief marketing officer and just a little bit about Plutora.

Davis: Absolutely. I’m a two and a half year veteran of Plutora, having come in shortly after Plutora got its first round of funding, which was very exciting for all of us and we really were launched on the path of providing a better outcome for folks transforming into DevOps and that’s what Plutora does. Plutora is a company that provides a SaaS platform, large enterprises, your typical brick and mortar of the past, banks, the insurance companies, et cetera.

These folks come to us and we work with them to provide the ability to visualize their entire pipeline to become better software developers ultimately and to corral the morass of tools that they’ve assembled in their transformation and really make sense out of them, make them efficient and make the organizations successful, and that’s what we do.

Ashley: I’m especially interested to talk with you on this topic because when you look at your customer list you have some very well-known names in Fortune 500, Fortune 1,000. It isn’t just a bunch of other startups. It’s people that other–

Davis: That’s correct.

Ashley: –companies and other people would recognize. So handling financial transaction, a lot of that, telecommunications, et cetera. So you come at this with a unique perspective and when we think about DevOps we’re thinking about that central core of team of bringing developers and operations together, but to really just scale it across an organization at an enterprise level, that’s a much different problem. What do you see as the challenge as you work with customers? Why do they come to you saying, “We can get it this far, but we need to get further and here’s what we need to solve”?

Davis: It is no question that that particular request from prospects and customers alike is the number one thing we hear, that is they’ve embarked on the transformation to DevOps. They’ve started maybe with automating testing. They’ve started by providing maybe a CI server and that automated deploying capability somewhere. That’s where they’ve begun their journey and they started with that automation and they’ve immediately found that while they’ve got gains there on that part of the developmental pipeline, the overall performance did not increase as was expected. They’re basically standing there going, “What am I doing wrong?”

The big problem people have really surround this word visibility. The lack of visibility results in tremendous issues all around the development process, not just for developers, not just for ops, but for every one from the program office to the security guys to the governance and audit people and so forth as we deal with people where those kinds of things are really important. Traceability, auditability, these are–software is running very sensitive businesses and those things are very important.

So without visibility, in order to build those things in messes up my DevOps process. I’m going along the path. I’m ready as a developer to move into a test cycle and all of a sudden the security guy says, “Hey, I need to check that for security issues,” and he’s coming to the party late and all of a sudden there’s a two week delay. People get frustrated and CIO’s are saying, “We’ve invested millions in tools and we’ve invested millions in organizational changes to adapt to agile and DevOps. We’re getting worse, not better, why?” And that’s the problem.

Ashley: When you say visibility, to me if I peal that word apart, I think what you’re really saying is it’s not necessarily visibility by the DevOps team itself always, but it’s the intersection with all those other parts of the organization, the policy parts of the company, the audit part of the company, the security part of the company. It’s all the other people that are involved in that business tool chain, if you will, of getting product out the door. You can’t just do it alone. Maybe yes, if you’re a three person in your basement start-up, sure you can. But when you’re talking about scaling this in an enterprise level, they have processes for stopping and checking things. Is it ready to go in production? Has it been checked for security? All those things. Is that what you mean by visibility?

Davis: It is and part of understanding the scope is to understand the scale of what these enterprises do. We talked to one group in a large insurance company in the Midwest that had 35 applications, that’s it. That doesn’t sound like a lot.

Ashley: Yeah. It doesn’t.

Davis: But that week, the week I was there they had 1,600 releases in process to be released that week. When you peal that down and what are 1600 releases in the context of 35 apps? Thirty-five apps, an application might have a whole portfolio of releases that need to be managed. So this visibility of the understanding of where my application is in the development cycle from the time that it starts to be an idea to the time it releases.

So that process to know what features are being released, where they’re being tested, what versions are they being tested with, when are they ready for a user test, when are they ready for preproduction final test, all those steps along the way have different tools, different teams often, required shared resources like environment, and they depend on other teams in the group and other people’s efforts within those teams to meet at the end point at the same time because, like I said, a particular release is going to have multiple different teams, different project teams.

So the visibility is across an entire pipeline first of all from the beginning of requirements to the time it gets released, but the visibility is also between pipelines to understand where dependencies are, to understand when other things that might affect my ability to release, like security, like audit, how those things come into play. I’ve got to have visibility across all that so that I can participate and predict when something is going to come out. That’s really important. If I’m building–for example, if I’m building a check cashing app and I’m a major financial institution, part of my development team is an iPhone app and I’ve got a team that’s building that and they’re following the rules of Apple and they’re following the rules of UI and they’re looking at how I can do forms and they’re doing all that.

On the backend there’s a data base that’s probably sitting on a main frame which has incredible security around it and it has to be upgraded to be able to provide the ability to process that automated mobile cash check. And that’s probably being done, like I said, on a main frame with a different development cadence. Maybe it’s got a release schedule that’s once every six months and this is app is supposed to be out in two weeks. How do I coordinate that and how do I bring the security people in to do that right?

So in order for that to be the case I’ve got to have a single system of record. I’ve got to have automated disability and dashboards to alert people as to when things are coming. I’ve got to be able to take information that’s being generated from multiple different places, multiple different applications, multiple different application methodologies, and correlate them in a way that gives me concise single page dashboard views of where things are so I can answer the question, “When will this release go out?” So those are all the kinds of things we do.

Ashley: Well, let’s take that word visibility and turn it another 90 degrees and look at it this way, which by the way, I think most enterprises would kill to have, what’d you say, 36 apps? That’s a side point. Anyway, if you took visibility–

Davis: Well, that was one–just to be clear, that was one group. That was one group.

Ashley: Oh, one group. Okay. I thought you meant the whole enterprise. I’m like wow. I know a lot of companies that ____ “How do you do that? Where’s the course for that? Sign me up.” So anyway, take that visibility word. I think a big part of what you’re talking about is it’s not just a tool chain for CICD going from development all the way through deployment. It’s also the planning, the scheduling, the coordination of releases. It’s coordination of getting information to people who maybe it’s not just the information, but the exceptions ’cause you’re doing that many releases that frequently that often.

You don’t wanna read 20 reports every day on the security compliance of every release that’s going out the door. You wanna see what’s the five things I need to be aware of that’s holding something up. So there’s a lot of coordination planning and scheduling that kind of activity that you guys focus on that’s I think more unique in what you do.

Davis: I’m really glad you brought that up, Mitch, because that’s something that’s coming on the horizon quickly, but has typically not been considered. When people talk about DevOps, even Agile and DevOps, when they talk about software delivery pipeline, very often what they’re actually talking about is check-in to production. The clock starts when I start to check my code into my source code repository. All development tools, whether it’s automated testing CI servers, CICD pipeline, management systems, et cetera, they’re all built around that second half and backend of the process.

To me the real issue goes back to the initial requirements planning. There’s some really nice tools about – on the enterprise agile planning side that have come up that are pretty mature. The PPM market itself has been around and good long while and there’s some really interesting and great products that allow me to establish the priority of my development work, establish the priority with my development teams, and to do that based on the strategy of the company, the budget allocations of the company, the expected value returned by the applications and projects in question whether it’s revenue or whether it’s cost savings.

And I set that up and I say, “Here’s my portfolio. This is the priority. I’ve got one ____ applications that I’m going to be driving. That’s my priority. Go.” And the teams all drive and they’re confident they’re building according to the priorities of the company. They enter into the pipeline and I lose visibility. Boom. It’s gone. While that product is being developed things happen. Scope has to change. I might have to pull features out that are particularly thorny, from a development point of view, in order to meet my schedule. Decisions have to be made.

Do I pull that out or do I keep it in ’cause it’s so critical and I accept a delay? How do I answer those questions if I can’t tie that back to the epic and the strategy, the theme, if you will, on the safe vernacular? How do I answer that question unless I can unequivocally understand how that connects back to the original idea of the application? The input is clear. I prioritized it right. Am I really ____? Am I getting better? Are people using the product? How are the NPS scores and how do those impact?

There’s all kinds of questions that you can ask that really define whether I’m doing better ’cause fast for fast sake is not that interesting. Fast to get to the value faster, big deal, and understanding that value. That’s why I year ago Forrester started to talk about value street management, the measure of success is ultimately is the business benefiting from the effort. Without the kind of visibility we’re talking about that whole effort is compromised.

Ashley: In different capacities I work with a group of CIO’s. I work with developer community. And a common theme across that is now that I think DevOps is taken the barriers of the organization, something that we all get rid of and start working together more closely in a true value chain or true pipeline chain is all the communities are struggling or want to know more – how do they more effectively communicate with the business side and with the C suite.

And not to make this about me, but I was on a podcast here recently and that question came up and I said, “Well, if you’re a developer you want your CEO’s attention, say ‘I have an idea that will increase revenue, bring us new revenue streams, cut cost, get us to market faster,’ any one of those business terms and they’ll immediately put you on the calendar.” I think that’s where you’re going and where the analysts are going with this value stream management.

Davis: Totally. That’s exactly where they’re going and that’s the key question that people wanna answer. It involves velocity. It involves quality. It involves all the things that people wanna talk about with respect to DevOps, but it has to be done in the context of an awareness of the impact on the business. It’s – in many respects when I first came to Plutora and I was talking to the founder and CEO about what Plutora did, my first reaction was, “This sounds an awful lot like Sales Force for IT.” The problem is very much similar to that problem.

System of record, like what Sales Force provides, inside this platform, our platform, for example, that connects all the dots and automatically serves up the kind of metrics that the C suite wants to find out about what’s going on with the developer not having to change the tool they’re working on. If they’re using Jira, if they’re using Jenkins, if they’re using Selenium, whatever tool they’re using they can continue to use that tool, but the platform, the management platform will take all that information and correlate it and provide visibility to management on exactly what the value is that’s being delivered. and the metrics of what’s the cycle time of getting released.

When I have a bug, how fast to fix it? If it’s a said one, what’s my meantime to repair? Am I getting better at quality, et cetera? These are all the kinds of things that guys wanna know and they wanna compare the scope of release that went to production with the scope of that release that went into planning and see how well they did on all kinds of levels. To be able to have the information to the C suite and everybody in between flow up to them naturally, without having the practitioners do anything out of ordinary to their normal day to day jobs, you have this perfect scenario.

You have this catwalk, if you will, across the software manufacturing process that gives the management the ability to see it without having to change the way the developers go and the information that can be served up, I can establish stakeholders. I can have a security stakeholder, the audit stakeholder, whatever my organization unique needs are. Let’s be clear, software is the competitive differentiator of organizations these days.

Ashley: It rules the world, right?

Davis:It rules the world and it’s–yeah. It’s for better or worse and as it becomes more of the thing, you can’t just be a bank that happens to use software. You have to be a software company that is choosing to be in the banking business.

Ashley: Yep. Technology company.

Davis: And if you–yeah. You’ll be out of business.

Ashley: Well, Bob, I appreciate you spending some time on the podcast. I know we could go a lot longer talking about this. Maybe sometime at Half Moon Bay at Barb’s, there we can grab something sometime.

Davis: That sounds like a great plan, man. Any time. Any time you can always hit me up there.

Ashley: Food and something healthy to drink, yummy. Yeah. Of course.

Davis: There you go.

Ashley: Well, I’d like to thank you, Bob Davis, CMO from Plutora, for joining us today. You’ve listened to another DevOps Chat podcast, I’d like to also thank you, our listeners, for joining us. This is Mitch Ashley with staging-devopsy.kinsta.cloud. Be careful out there.

— Mitchell Ashley